Do you remember when you turned on the feature which tells posters what threads they’ve posted to, but putting a bullet on the thread icon? It loaded down the server like Orson Wells riding a chiuhaha, which is why it was turned off very shortly thereafter. Well, it you want to give the new server a thorough load test, that’s one thing I’d try.
I don’t think we’re going to use this function but thanks for the suggestion.
(Still giggling over your assessment; it’s very accurate as well as humorous.)
Well, it would just be for test purposes, to maximize the server load during the evaluation period. I wouldn’t expect (or even want) this feature to be used once the new server goes online permanently.
But not really a useful test; we want to see more real-life presentations.
Everything new that we’ve enabled so far is stuff that we hope to continue using. To add something in just because it eats up resources would not really be useful, it would just be frustrating to the community. That’s happened enough in real life, I don’t want to add another nanosecond of that to anyone’s message board experience.
Would it be possible to let us know every new feature that’s been enabled (the only difference I can see is the 5-minute edit window), so we can abuse them all to bejaysus?
What you see is what’s available.
As detailed, we have enabled the timed edit function, private messaging, and RSS/XML feeds.
Nothing else has changed.
I think you’re missing the point. You want to see how well the new server handles a load. What functions you enable to cause the load don’t matter; the idea is to push it and see how well it handles it, compared to the current server. The more load you put on server resources, the better you can gauge its performance. As it stands now, there’s nowhere near the load being placed on the new server compared to what we’re using here. Otherwise, what’s the point of testing it at all?
vBulletin sits on a MySql database (or used to) so there are plenty stress testing tools that the techs can use. You can’t really get much value out of randomly switching features on and off.
I know how vB works–yes, it’s still a MySQL db. They should have already stress-tested the server before they put it on line; since they asked us to help them test it by posting and using various features, I would assume they want to gauge the performance under real-world loading conditions. That being the case, it makes sense to turn on features known to place a heavy load on the server. If that’s not what they’re testing, however, that would be pointless. I’d then like to know what it is they are trying to test.
End-user testing, dude. Let’s see what the Teeming Millions make of it, let them play around with the bits of user interface they haven’t used before and see if they can break it. Real world scenarios even the most carefully considered testplan doesn’t catch. You know jjimm has even found a punctuation error on the RSS FAQ page!
And a bit of positive PR for the board, too.
Specifically, can we keep the boards straight? If we’re trying to go back and forth between them, posting silly stuff on the fake one and serious (or at least non-violative-of-the-rules) stuff on the real one, how long will it be before somebody gets their wires crossed and inadvertently posts something banworthy on the real one?
About five minutes after the new server went online. Link. 
Ok, not exactly banworthy, but it sure didn’t take long for someone to get their wires crossed.
I think the issue is that, while the bullet-hole feature used a lot of resources, it didn’t necessarily use the same resources as, say, searching, or a whole lotta posting. So while it would provide a test of how the board responds to stress, it wouldn’t necessarily be the sort of stress we’re interested in testing.
It would have to be the same resources. Ultimately, every single board function uses the same four basic resources: system memory (including RAM and virtual memory), processor overhead, database access and communications bandwidth. All the board functions are driven by combinations of one or more of these. Posting, searching, editing, reading threads and moderator functions are all fundamentally driven by MySQL queries, which in turn are driven by scripting (in this case, using PHP). Although the degree of loading certainly varies by function (searching is far more server intensive than, say, opening a thread to read), the effects of similar amounts of server load are more or less the same for similar resource consumption regardless of the function being used. Clear as mud?