That is the change that was made in response to our exceeding concurrent connections.

That's what I suspected. Oh well.

The previous functionality was the default -- keep one connection per page (since the mysql_connect function only opens a connection if there isn't already one), closed implicitly when the page processing completed.

Would it improve performance at all to make the end-of-page close explicit, but not open more than one connection per page?

(It feels terribly inefficient to me, to use 5 connections where one would suffice, but, I'm not a server.)

Would it improve performance at all to make the end-of-page close explicit, but not open more than one connection per page?

It shouldn't make any difference. I hate to say "doesn't", but ... PHP doesn't maintain the connection once the page is loaded, so closing it at the end a) should be unneccessary, and b) would require testing for the presence of an open connection to know if one can close it, or to keep trapping and ignoring that "can't close! not open!" error message.

So, ita, what do you think about changing the mySQL variable "wait_timeout" to 30 seconds as an experiment? The default is eight hours, which means that if we are getting some connections left open due to bugs in PHP/mySQL/our code they could easily end up being 200 simultaneous idle connections at once.

I'll have Kristen suggest that to Steve, Rob, since we don't have direct control over it.

Back on WX, we had Bitches, NAFDA, and a few other categories on separate pages. Would there be any gain in going back to a similar structure? It might mean that Bitches could be housed on a separate server from Natter and the show threads on another - cutting the load on each individual server a lot.

I love the set-up we currently have, but this might be a middle ground between cavorting on the way we have been and clearcutting the board. It would mean (I imagine) two or three separate accounts, but that would still come out more economically feasible (I think) than a dedicated server and would avoid the problems Kristen mentioned with that server being not at the level we're used to.

Kristen, I imagine you can tell us if this idea is completely wrongheaded before we go any further thinking about it.

But maybe that can be our worst-case scenario, before we go solo or start talking about cutting huge parts of the community out?

It might mean that Bitches could be housed on a separate server from Natter and the show threads on another - cutting the load on each individual server a lot.

If they use different databases, then the shared info (like users) is a problem.

If they use the same database, then nothing's been gained.

If they use different databases, then the shared info (like users) is a problem.

How much of a problem? More hassle than it's worth? (I have a feeling the answer is "yes," but I thought it was worth asking)

Like you'd have to have two user IDs and log in twice, and there'd be no direct connection between the two sites, at first blush.

It's possible the site hosts will allow two domains to connect to the same table, but I don't know how sound a solution that would be.

ita, I'll pass that question along to Steven with some others I have for him.

It's possible the site hosts will allow two domains to connect to the same table, but I don't know how sound a solution that would be.

Generally speaking, this is not allowed by webhosts.

I had other things that I was going to say but I think they've been blocked by this headache I have behind my eyes.

I think in the article they ended up with a wait_timeout of 60 seconds, not 30. (30 being the minimum they could get away with).