Feels strangely like Monday again, except that I'm extraordinarily busy today. Even my train-time isn't free from work's reach today, so I don't have much time to write.

So Dreamhost, my hosting provider, dropped a velvet brick on my head yesterday. They sent out the cheeriest email ever, talking about how they're changing all their plans to have more storage, more transfer, more domains, and such, and as an existing customer, I'm grandfathered in, getting all the new capacities for my original monthly price. Great! Whoopee! They have a link so you can see what all the new levels are. I follow it.

The one thing they didn't mention was that they now meter mySQL access using a unit they invented called a 'conuery' (I pronounce it 'con-weary' and with good reason). Where before they had unlimited mySQL access, now each database connection costs 25 'conueries' and each query costs a single 'conuery,' the logic being that establishing a database connection requires 25 times as much CPU effort as executing a query (hence conuery, 'connection-query').

On my $40/month plan I get 15 million conueries per month, which sounds like a lot but isn't really. It's enough for about 500,000 page views per month the way Fury is set up currently, and closer to 3-4 million views per month once I switch to persistent connections instead of one-off connections. That's fine, Fury typically gets about 70,000 hits a month, so that's no biggie.

The problem is Metacookie, which I host in the same account.

Though right now Metacookie's in alpha testing until I can wall off some time to bring it to beta and final release. The gist is though that for Metacookie to work, each metacookie-enabled site has a little badge graphic that is served from Metacookie's. That badge is a 'beacon,' so that when the reader requests it, my database marks them as being up-to-date on that weblog. Naturally, this requires a database query to update the user. The graphic served is only 241 bytes, but the query is now a lot more 'expensive.'

How expensive? Well, assuming that I completely solved the connection problem and only had to pay one 'point' per user-blog-view instead of the current 26 points (25 for the connection and 1 for the query), then Metacookie would only be able to handle 15 million 'beacon' hits per month (less the conueries that Fury, qwer, aoliza, randompixel and underblog will be using). Considering that there's a beacon hit every time anyone looks at the home page of any metacookie-enabled site, 15 million hits is an incredibly low number. Metafilter alone gets about 1 million hits a month, and that's just one site that might be Metacookie-enabled. After release, Metacookie will be serving to hundreds if not thousands of sites. The first impact this will have on the design is that people will have to be signed in to use Metacookie. That will reduce database activity by around 90%.

But what happens if I go over the limit? My $40/month gives me 15 million conueries, along with all the rest, 900 megs storage, 20 gigs transfer, etc. If I go over my 15 mil, it automatically charges me $5 for every million I go over. In essence, if I exceed my quota by 50%, I'm paying double my regular monthly charge. This for a database service that goes down for several hours at a time at least once a month, though this is likely the reason they're instituting limits like this.

Not to get overly technical, but the way persistent connections work is, when one of my scripts requests a database connection, the server checks if a connection with the same username, password, and host already exists, and if it does, it uses that connection instead of (ch-ching) starting a new connection (for 25 points). That's cool and great. In theory I can start one p-connection and use it for all my database stuff. This is what Dreamhost is pushing everyone to do.

Warning, database geekspeak ahead:

Here's the rub: Each mySQL server can only handle N many simultaneous connections, persistent or otherwise. The default is 16, though I don't know what Dreamhost's servers have been configured to support. Basically this means only 16 (err, n) sites or less can have a persistent query open at any given time. Try to open another and the oldest one closes to make room. Considering that each database server supports hundreds of sites, there are a lot more sites hitting the database than connection slots. The upshot is that if I'm the only one, or one of only a handful of sites using persistent connections, I'm in good shape, since the others using one-shot connections don't hold on to their slot. They take it and let it go, freeing it up for the next request. The problem is that if everyone does as Dreamhost recommends (indeed, is pushing on their wallets to do), suddenly hundreds of sites will be requesting one of 16 (err, N) connection slots, and each persistent connection will last for only a few seconds (if that), not minutes, before being automatically closed to make room for another persistent query, thus completely nullifying the theoretical benefit of using a p-connection.

Is this kind of connection-flooding likely to happen? Insufficient data. So far, though I'm waiting to hear back from them, it doesn't seem that Dreamhost provides any tools for measuring your current conuery usage, or usage-to-date this month. I suppose you just get a bill and that's how you know.

Anyhow, time to get to work. Let the barrage of 'you should host with provider X or Y' begin! :-)