You’re entirely right, ET. Usually there’s very little lag going on, but I’m sure you’ve noticed that usage is quite cyclic; the server is perfectly fine most of the day, then the peak hours start, the server gets overloaded, and the response time rockets from, say, 20msec to several seconds and quite a few drops. Normal high usage points are update times, lunch, and when people get home from school or work.

While I hate to resolve issues by throwing hardware at them, there’s a limit to how much you can do with what you have and FW is growing fairly rapidly.

You’ve already said that you store the battle databases in memory, and that battles aren’t CPU intensive. That fits well with my hypothesis that it’s related to the number of server connections and TCP/IP packet handling.

If you have time, you could try to find or code a new TCP/IP stack designed specifically to sacrifice throughput for number of connections and rapid turnaround time, and attach that to a network interface that’s separate from the other server functions. Since consumer grade TCP/IP handling (Both NICs and stacks, for related reasons) tends to die once you hit around 60 concurrent connections, this might be worth considering.