If I knew what they were running and how it was set up I might be able to help them get a bit more oomph out of what they have. Barring that, I could help them make careful decisions about what they should buy to get the most bang for their buck.

Out of everything, the only part of forumwarz that actually suffers when lag steps in is pwning threads. bumuming that they’re running a single-server solution, I would suggest sticking the pwnage system on it’s own server and storing all forum data on a RAMDisk.

I get ‘Refreshing the page will not cost you a forum visit’ messages just about every time I go and pwn a forum. It doesn’t matter what computer I use, what network I’m on, or what ISP I’m connected through.

I’d say that’s pretty bad.

SimplyTHEBEST Posted:

I get ‘Refreshing the page will not cost you a forum visit’ messages just about every time I go and pwn a forum. It doesn’t matter what computer I use, what network I’m on, or what ISP I’m connected through.

I’d say that’s pretty bad.

Same here. I have to refresh each forum after almost every attack.

lag are

about?

FalconFour Posted:

Image attacks, any attacks, they’re all the same. The problem is in the time it takes to process the AJAX request and receive a result from the server-side processing of damage, pwnage level, stats, etc… all that **** is processed on the server on each action. Unlike a traditional website, only small portions of the page are sent and received, but the server still does the processing on nearly every action during a “battle”.

Maybe, for some freakish and unusual reason, you’ve never seen the “greyed out lockup” after performing an action with the “pinwheel” spinning and waiting for a response. And I also imagine you’ve never seen the “An error occurred while communicating with the Forumwarz server – try refreshing the page” (paraphrased from memory) message that happens when a request times out.

And yes, the lag is pretty damn bad at times. It makes speedrunning damn near impossible. It’s not a problem with my computer either – it was on my original 866MHz P3 laptop that I originally played Forumwarz on, but not so much on the Core Duo laptop I use now.

I imagine there is much room for improvement. MySQL (which Trout says that Forumwarz uses) has a rather useful “Memory” table type that can be used for temporary tables that are rapidly written, and could help relieve some of the load, if it’s not already being used here in some way. Apache (especially under Linux) makes administration pretty “blind”, but you can probably find some pretty slick tools to show you where the bottleneck is. And as one user had already mentioned, there are people that can help pick better hardware or make better use of it… I’m all for one-server solutions (they’re far more efficient at processing data), and I imagine one server can continue to do everything, just with a little tweaking. Log in to see images!

OK – you are one huge code dweeb – respect….

SimplyTHEBEST Posted:

Out of everything, the only part of forumwarz that actually suffers when lag steps in is pwning threads. bumuming that they’re running a single-server solution, I would suggest sticking the pwnage system on it’s own server and storing all forum data on a RAMDisk.

I know nobody cares about it but… Incit suffers too.

Time to get technical!

The Forumwarz battle engine is pretty complex at this point.

As it’s been pointed out, every attack you make is actually an AJAX request to the server. If it wasn’t done this way, it would be way too easy to exploit as all the battle data would be in your browser’s memory.

Generally, making an attack is very quick; Our average invocation time over the last 24 hours is 120ms. It is quick because almost everything is held in memory, in memcached.

Once you enter a battle, the server takes a snapshot of your stats, and creates all the threads you can battle and throws them into the cache.

Every action you can perform in Forumwarz is actually represented by regular ruby code. For example, here is the “Post Bra” attack from the camwhore:

clbum EventHandlers::Abilities::Camwhore::Bra < EventHandlers::ActionBase

  decrease :enemy, :pwnage, :value => 10..15
  decrease :player, :sexiness, :value => 1
  inactivate_action :turns => 1
  minimum :sexiness, :value => 1
    
end

The clbum looks pretty simple, but the first time Ruby parses it, it actually uses meta-programming to flesh out dozens of methods. The most important one is execute, which takes a reference to the battle object we stored in memory and performs all the battle logic against it.

When rails is running in production mode, it caches all the clbumes it uses. So when you say “Post Bra”, it knows exactly what it has to do, and it does it very quickly.

Once it runs the ability code, it gets back a list of what was effected (for the bouncing numbers, or if you died, etc.) and sends that back as javascript to the client.

There are times when an attack has to access the database. Usually they occur on the last thread in the forum when you beat it (to mark the forum as pwned, award scoops, continue missions, etc.) but there are a few exceptions that do very quick database work when an attack occurs.

Okay, so if it’s so fast, why do we experience lag at times?

When battle lags is it almost certainly not the traditional culprit (the database), unless you are on the last thread. It is a sign that the server is overloaded doing something else.

Another request (really, anywhere on the site) might have a bug or an unoptimized use case where it takes a huge amount of memory or CPU. If the server is being sucked dry processing something else, your request has to wait.

Often it’s an issue of concurrency. We can handle about 50 requests per second consistently with our current configuration, but if we spike to 75 or so, requests have to be queued up. If requests are coming in faster than the server can handle them, we’re in trouble.

Basically what I’m getting at is lag can occur for many different reasons. It changes based on the time of day and the current load on the server. Right now we’re profiling every action to the server and optimizing out the slowest ones. It’s an ongoing process.

At some point we might have to move to a multiple server configuration. We’ve been lucky enough so far that we’ve managed to scale without it, because it’s much more expensive than what we’re paying now.

Also, it’s hard to justify getting new hardware when the server is not lagged most of the time. Actually every time I see one of these threads I try entering a battle and always seem to find that things are going really quickly. The battle action is the second most requested

url on our site, with about half a million attacks being done in the last 24 hours, and it averaged 120ms. Of course there could be periods of minutes where it’s horribly lagged and requests don’t respond, but on average it’s very quick.

If you consistently experience lag, please submit a detailed bug report including the following information:

– What web browser are you using

– What time did you most recently experience lag?

– What time of day do you typically play? Is it always the same or does it vary?

– Is it always on the same forum, or different forums?

– Is it the same attack, or different attacks?

Honestly I beg people to submit detailed bug reports because a report that just says “Lag” is completely useless to us. We need lots of information to solve the problem.