It is a MySQL problem - in part. The default MySQL storage engine is great and very fast - for read-only access. But when there are a lot of updates (such as here), it sucks. The InnoDB transactional engine is better for updates, but it's also much, much slower. If you wnat to have a fast database engine that also handles concurrent updates/additions well, you'll have to go for an industrial strength product like Oracle or SQL Server. The other part is lousy DB access programming. It seems like connection pooling is not used, or used wrongly. Which results in the "too many sessions" error that we're being spammed with. This second part is the major culprit. A well-programmed site using MySQL can easily handle ten times the current volume on the same hardware. By the way, images are not stored as BLOBs AFAIK, they're stored as files (view the HTML source of any gallery post, and you'll find the IMG tag referring to "GalleryImage12345.jpg" - a file). I've tried working with BLOBs and Web pages, but each request then means extracting the BLOB from the database, storing it as a temporary file, and having the HTML refer to that temporary file. Not worth the trouble. Speed also depends on the use of stored procedures. I don't know what version of MySQL is being used here, older versions do not support stored procedures. A rule of thumb: a database driven (Web) application using stored procedures can handle about twice the load of the same app on the same hardware without stored procedures. The age of 'rosity leads me to suspect that stored procedures are not being used. I hope Bondware 3.0 has been put together by programmers who know how databases work. We'll see.

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery   My freestuff