
Sythe.org has 500 users in the last five minutes all accessing the same table of the same database, trying to read and write to it.
If you don't understand the difference between database concurrency issues, hardware IO issues and reverse proxy/caching issues then how can you possibly help?
To clarify: We only have the first two problems, one because of the way vbulletin is structured, the other because our host has been rubbish over the past few months. We do not have the third problem -- which is the only problem for which you have proposed a solution.
If you want to do some research into how hard it is to run large sites smoothly on mysql go look at facebook: http://www.facebook.com/MySQLatFacebook
They have a dedicated research staff to keep their mysql instances up.
Anyway long story short, saying our set-up is shit doesn't help fix any of the problems. I've already addressed the memory errors and I'm keeping a closer eye on them, with a script to inform me when the site is giving out 500 errors. The host has fixed its disk and IO problems.
I'm still looking into migrating us to a cloud hosted mysql solution, but that can't be rushed.
Well again, the main issues are database contention.
Regarding upgrades... This is a common mistake among web masters (including professionals.)
Upgrading server software to the latest -- for no better reason than because it is the latest -- is usually a bad idea. Indeed, the latest versions of things are the least tested and tend to be the most vulnerable security-wise. It is generally much preferable to run servers on backdated versions of things that have already been through years of production exposure and have been patched and repatched repeatedly to get out all the flaws. Upgrading should be a last resort and should only be between major versions (i.e. vb3 -> vb4) and never at the first release of a major version.
That said, I will do a review when the time comes.
Sounds like you're stooging for them.

And here are the Pros and Cons as I see them:
- vBulletin 4 has much better SEO, increasing the potential for the community to grow
- vBulletin 3 is unsupported, and we are stuck on the 2006 version
- Our version has 6 known vulnerabilities, which was taken down to 1 if we upgrade to 3.6.8
- If anything, we should at least upgrade to the end of the line in the 3 series, which was the most stable/secure version when Jelsoft abandoned it
- Since vB4 is supported, any security issues created by updates are patched quickly, or you can just stick with an older versions with no flaws
- Going by general logic, we can assume that the company you trusted enough by using their software knows how to handle their software, and improves it rather than degrading it and making it less secure
- Some other improvements that were made:
- Improved search performance (no more disabling search)
- Generally much better PM system
- Better user security
Firstly we are already upgrading to vb4. That is not in debate. The only issue for vb4 is the look and feel and migrating custom code and plugins correctly.
However keep in mind that vb4 is even more database intensive than vb3 and will only exacerbate any contention issues -- which should be addressed first.
Secondly we do not run 3.6.4.

It certainly does say that.
Isn't it a heavily modified version of 3.6.4 that we run? (I think I read that somewhere once.)

I am in the process of trying to migrate us to amazon web services at the moment. Unfortunately upgrading will lead to still more downtime. Bear with us.



Small rollback. We tried amazon web services (which took many hours to transfer the database to) for about 30 minutes. It is far slower than our existing setup, so I've reverted.

Very interesting. I've never tested Amazon but I'm somehow disappointed in them already.
Could the same test be performed in Rackspace?
http://www.rackspace.com/cloud/public/sites/


I've had bad experience with rackspace previously. Not wanting to repeat.
Just found the source of the 500 errors. I asked the tech to recompile apache with mod_deflate a couple of days ago. WHM appears to have taken it upon itself to update php at the same time and override config files with defaults. Long story short some modules were being loaded incorrectly.
Unfortunately the 500 errors were happening already before this due to memory capping, and I didn't think to check the error logs to see if they were different until I realised the number of 500 errors had increased dramatically. Tech has apologized for not checking logs after build (which he definitely should have.)
I've negotiated a ram and IO speed increase. We already have additional ram, and they are looking into the latter now. I also spent half my weekend working on grafting our vb3 skin to vb4 (which turns out to be quite difficult.)
So there you have it for updates, progress and endless stress. Did I mention I have the flu, two assignments and a lab due tomorrow? And it is currently 3:50 am. And people say I don't do anything for this site...

