Nice call, Rob.
If we can get the daemon restarted, and the problem goes away, do we still need to move?
If the daemon is restarted the error messages will go away, probably for a couple of months. If the current version of mysql is replaced with one that has these new patches applied, the error messages will go away permanently.
Whether or not we are using mysql too heavily is a separate issue.
It looks like we've been sharing
one
connection for forever. I'm sure the traffic has lightened and we may have lost posters due to lack of patience, but I can't see, under non-race conditions, how we'd honestly use more than 100, seeing as we're getting clumsily by.
I hate writing code that hits a bug in another system -- where the hell do you start to work around that?
At some point, the code should be rewritten so that mysql connections are preallocated, and kept open between page views.
This will signifigantly improve performance, since opening and closing msyql connections is a relatively expensive operation, especially on the server side.
If they are open between page views, how then can we have 101 simultaneous users?
Or do mean sharing connections between sessions? Is that possible?
I understand that the opening and closing is expensive (although were were told to explicitly close after every open as part of trying to minimise this error).
My gut reaction is that they should be open for a page, and no longer.
Or do mean sharing connections between sessions? Is that possible?
Yes, and yes, using the mysql_pconnect function.
Persistent database connections.
It comes with this warning, though:
Using persistent connections can require a bit of tuning of your Apache and MySQL configurations to ensure that you do not exceed the number of connections allowed by MySQL.
Tom, am I misinterpreting this:
they do not give you an ability to open 'user sessions' on the same SQL link
Wouldn't that limit us to 100 sessions at any one time?
they do not give you an ability to open 'user sessions' on the same SQL link
The users they are talking about above would be Phoenix users, not mysql users.
PHP has the ability to keep mysql sessions alive between page views, but it doesn't have the ability to make sure that a user would get the same mysql connection every time he views a page.
So how are they defining child processes on that page? What creates one?
So how are they defining child processes on that page? What creates one?
They are talking about Apache httpd processes. Normally, on a web server there are multiple instances of Apache running, and that number can grow or shrink depending on server load, but never fall below some predefined threshold.
These persistent msyql connections can't be shared between httpd processes.
This is one of the reasons why we would have to be extremely careful if we decide to implement this. If there are twenty httpds running, and each has 2-3 mysql connections, we can easily exceed our allotment.
Getting this working right would involve fine-tuning Apache, PHP and Mysql server parameters, and would be difficult to do if we didn't have a dedicated connection.