I've passed the information on to Steven. Since we have confirmation from the actual people at MySQL, I'm going to the mattresses on this one, if necessary.

There was a reason persistent connections wasn't recommended. I'll have to look back at my notes to remember why. Either way, I know we can't do it in our current location but it's certainly worth a shot in our new home, wherever that may be.

Can I blame someone here for eating all my Pringles?

No. But I can apparently blame you for eating all of mine, since I don't seem to have any. Hmmph.

The more often we open and close mysql connections, the more likely we are to exercise the race condition that Rob discovered. After mysqld is restarted, the fewer connections we make, the longer it will take for the condition we are in now to reoccur.

I hope there's a timely patch (a girl can dream, can't she) that's implemented quickly. Who knows, though, if the bug would still be triggered with persistent connections anyway?

Tom, I'm finding that text a bit opaque. With persistent connections, then, the entire site is using just the one? Five? Fifty? When are they closed? From their description of them, it makes it sound like a line-for-line substitution should work for the code, and the labour is in the server tuning.

But I don't fully grasp it.

Let's say that using non-persistent mysql connections, the site never had more than ten connections happening concurrently.

That means that properly tuned, the site would have ten persistent connections open all the time, and no more. The difference being that we wouldn't be opening and closing connections constantly, thus reducing the amount of work mysqld has to do.

Let's say that using non-persistent mysql connections, the site never had more than ten connections happening concurrently.

It's the "let's say" I'm asking about -- how do we control that -- code side, or in the server configuration? How do we get ten open? How do we make sure we never open more than ten?

It's the "let's say" I'm asking about -- how do we control that -- code side, or in the server configuration?

There are two main variables at work, how many people are accessing the board, and the server configuration.

How do we get ten open?

There would have to be an instance of ten people trying to view pages simultaneously. It's not very likely in practice, since the board now flakes out when two people try to view pages simultaneously, and it's still somewhat usable.

How do we make sure we never open more than ten?

You would have to tell apache to never fork more than ten httpd processes, or tell mysqld that max_user_connections is 10.

So there's no explicit code control of how many open, and there's no need to close them in code either.

What happens, then, if eleven people try and connect simultaneously, with either of your capping mechanisms?

Also I'm kinda worried about having code that's so particular it's not mobile, but on the other hand, we currently have code that's tickling buggy innards. So that's not good either.

According to the PHP documentation, you can use mysql_pconnect anywhere that you use mysql_connect, and the code should behave the same. PHP will handle the persistency behind the scenes.

According to the PHP documentation, you can use mysql_pconnect anywhere that you use mysql_connect, and the code should behave the same.

Yes, but the servers will have to be individually tweaked to let the code run efficiently. It just looks like so much is up in the air. And we'd have to debug as we ran, but it's not like our current situation isn't annoying.

If we move to our own (expensive) server so that we can only use 10 concurrent connections, it's a little odd. I can see why Steven might want to wash his hands of us on a shared server, but we're not legitimately using more connections than we've been allocated. We're being provided buggy software to work with.

I've been confused about that for a long time, ita.