It is not cool, you are right.
Last night we were desperately working to stop the mysql errors. When we were working you saw the maintenance page. This problem is hopefully solved - I will be monitoring the site during the busy periods - but if anyone does see another mysql error after, well, now, then please post here.
We have just made a huge investment in new kit, and we were convinced that would be enough for sometime to come, but it never seems to take long before whatever kit we use is pushed to capacity all over again. (Unfortunately, the subs that fund this site often don’t match this load.)
Now, none of this is your problem, of course. You have paid a subscription for a service, and you should expect it to be available 24/7. This we try to achieve, but it is not always possible. We can only tackle problems as they appear, and we do try to keep all downtime to a minimum.
-Russ
Russ,
nice job on the site. Really like it.
Just some suggestions on problem reporting, etc.:
1. Invest in a copy of vmware, etc., so you can play with various development/qa environments rather than making the code change live.
2. Better error pages. This adds to user experience and can catch and report a whole lot of error automatically. I think there are a couple of php thingies lying around for this that will catch 500 and 404's.
3. A bug report link. You have this forum, but this is like the close button on the elevator. It doesn't do anything but it makes people feel better.
4. Adapt one of the throttling modules (I assume you are using apache) to key off of whether a user is a subscriber. That way paying customers get the bandwidth and performance.
Having run a few very high availability I feel your pain. Support is a thankless task. People only notice you when something goes wrong. They come to associate you with failure. 😳 Anyhow, best of luck.
Originally posted by dscpI have a local dev system, and a mirror site, through which all code changes pass. Most of the time we promote all code modifications, after thorough testing, during a quiet time on the site (weekends), when we can take the site down...but sometimes (like today) I just want to copy up a small script change (Hot fix). There was no bug that caused the reported problem - just an i/o 'limbo' state while the file was being written and the php parser barfed for that 1/3 of a seond.. I got caught. 😳
Russ,
nice job on the site. Really like it.
Just some suggestions on problem reporting, etc.:
1. Invest in a copy of vmware, etc., so you can play with various development/qa environments rather than making the code change live.
2. Better error pages. This adds to user experience and can catch and report a whole lot of error automatically. I think t ...[text shortened]... u when something goes wrong. They come to associate you with failure. 😳 Anyhow, best of luck.
>>Better error pages.
100% agreed. No one should see any (ugly) error on this site apart from me. Normally my code is 100% bug free though, so this isn't a problem. 😉
-Russ