05-27-2013, 11:13 AM
Guest access has been restored. Thanks for your patience and sorry it was such a chore, due to various rather lengthy, boring, and potentially passable as Klingon reason*.
Feel free to be as much of an aggro surfer as you want to the server. In fact I encourage it. I've setup some special stuff on the server that lets me see hyper detailed information about every single request the server is handling. So you do something mean and the server gets a bit punch drunk ... I'll see it and fix it.
If you encounter any errors... report them here: http://csnbbs.com/forumdisplay.php?fid=545
You may still get some occasional weirdness like a 502 Gateway Error as Tikitiki and myself put in some final fixes. Just wait a few seconds and refresh ... then report the error at the link above.
Looks like the new server will allow for roughly double the capacity and that's before I bring in the old one from Dallas.
Oh yea ... and
![[Image: img292.gif]](http://gifs8.com/wp-content/uploads/2012/09/img292.gif)
* Reasons if you want to ubergeekxor:
1) An error in xcache's mutex logic leading to segfault (which I actually got patched in svn trunk)
2) An additional error in xcache leading to SIGABRT without a proper coredump
3) An inefficiency in a plugin used to make the new theme and template system far more developer friendly leading to waves of database wait spikes. This issue was more than SIX DIFFERENT PAGES AND FUNCTION CALLS DEEP in obfuscation before it revealed it was the real culprit
4) PHP in debug mode being HIDEOUSLY slower and thus actually completely changing all the debug output when I tried to solve all the above
One for the road: If you think a VPS is proper hosting, the only rodeos you've been on are amateur league Scythe. Aside from not being able to handle this kind of load on a VPS without paying more than 5 times more per month in hosting, you're eating 10-15% straight off the top in lost performance for the hypervisor, and you'd still hit the same problems I hit in xcache in apc (but particular xcache) when you hit 2,000 ... 3,000 ... 4,000+ cache requests per second. So yea ... GFY. [Only the JMU folks will get this one]
Feel free to be as much of an aggro surfer as you want to the server. In fact I encourage it. I've setup some special stuff on the server that lets me see hyper detailed information about every single request the server is handling. So you do something mean and the server gets a bit punch drunk ... I'll see it and fix it.
If you encounter any errors... report them here: http://csnbbs.com/forumdisplay.php?fid=545
You may still get some occasional weirdness like a 502 Gateway Error as Tikitiki and myself put in some final fixes. Just wait a few seconds and refresh ... then report the error at the link above.
Looks like the new server will allow for roughly double the capacity and that's before I bring in the old one from Dallas.
Oh yea ... and
* Reasons if you want to ubergeekxor:
1) An error in xcache's mutex logic leading to segfault (which I actually got patched in svn trunk)
2) An additional error in xcache leading to SIGABRT without a proper coredump
3) An inefficiency in a plugin used to make the new theme and template system far more developer friendly leading to waves of database wait spikes. This issue was more than SIX DIFFERENT PAGES AND FUNCTION CALLS DEEP in obfuscation before it revealed it was the real culprit
4) PHP in debug mode being HIDEOUSLY slower and thus actually completely changing all the debug output when I tried to solve all the above
One for the road: If you think a VPS is proper hosting, the only rodeos you've been on are amateur league Scythe. Aside from not being able to handle this kind of load on a VPS without paying more than 5 times more per month in hosting, you're eating 10-15% straight off the top in lost performance for the hypervisor, and you'd still hit the same problems I hit in xcache in apc (but particular xcache) when you hit 2,000 ... 3,000 ... 4,000+ cache requests per second. So yea ... GFY. [Only the JMU folks will get this one]