And I suspect we are closing connections once the page is loaded. But if we use a bunch of connections to load a page, and a bunch of people post or read at the same time, I can see how we could get up there.
We really ought to (and can easily ) limit it to one connection per page load.
I was wondering the same thing as Tom, but he actually knows the stuff and explained it better.
Isn't there a know bug in certain version of PHP and MySQl where resources are not released? I wonder if there is something similar for MySql connections. Let me go the the PHP boards and check it out quickly.
I suspect Tom is right. I can't find any well know bug where connections don't close. So we need to look at the actual code.
The simplest thing to do (and oh! look! it's a weekend!) is to run through the code and put explicit closes after every recordset is done with.
That's phase 1 of the process.
The second phase, is to actually run through the code and squeeze down the queries. This has been, she says sheepishly, on my plate for a while. Anyone want it?
ita, I'd be the first to volunteer had I any idea what's going on. I'm even working all nights all weekend and will be bored.
ita, I'd be more than happy to help out in any way I can -- I haven't a clue if my PHP/MySQL skills are up to where I'd understand the Phoenix code if I saw it, but I can certainly try.
Perhaps fangeek can turn on mysqld logging (for a short period of time) so that we can get a handle on what's happening?
IH informs me that, while they did not anticipate any problems with the site, they simply weren't expecting "over 200 concurrent mysql connections at the same time". They had no way of predicting that. They informed us that we are the reason the server has been so slow of late. They also suggested that we modify our code, as they believe the script we're using is the problem.
IH mentions that they think if we "optimize the database queries" that will help a lot. It isn't our bandwidth usage that is the issue, it's our resource usage.
I gotta say that IH actually giving us a clue as to what's happening is much better than the way HR just kept telling us "You should have fixed your code."