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.

The more often we open and close mysql connections, the more likely we are to exercise the race condition

That means that properly tuned, the site would have ten persistent connections open all the time

There would have to be an instance of ten people trying to view pages simultaneously

This stuff is just filthy

t mixes margaritia

Who wants salt? Astarte? Perkins?

MMMMMMMMMMargaritas...

No salt on mine, thanks.

t tastes margarita

Nummy, Trudy. Just what I needed. You're a stah...

Here's my take on the situation.

We're on a shared server. On a shared server, no one client should consume more than their fare share of resources, such as disk space, memory, CPU time and bandwidth. If one client uses too much of any of these resources, it hurts the others.

MySQL connections use a lot of resources. If a client were allowed to use as many connections as they liked they would consume too many resources. Putting in a limit to the number of connections has the side effect of limiting resource use.

The problem we'd have going forward is that Phoenix might end up using more than $20/month of server resources while staying under our MySQL limit. If that's so, Steve (as rep of IH) will have an incentive to figure out another way to limit our usage to more closely match the amount we're paying.

A dedicated server solves this problem, since we're limited by the speed of the CPU and the amount of memory in the box. If we exceed those limits a little, the board just slows down. If we exceed them a lot, maybe the server crashes. Either way, only Buffistas is harmed. Our hosting service isn't going to kick us off, they don't care how often a dedicated server crashes.