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.

Dedicated server such as the $99 monthly deal on Istrata, am I correct?

Rob, since istrata seems to have taken down its site, and I can't find dedicated servers on the Netgate page, do you know if you can add additional RAM?

ETA: Nevermind on the first question.

It looks like it starts out with 512MB, and you can go to 1GB for a setup fee of $129.