4

I'm writing an online game that has to run in a web browser and I'm worried about whether my server-side architecture will be able to handle the load.

I'm designing for 1000-2000 simultaneous clients. Each client will need to query the server once every 2 seconds - so 500-1000 transactions per second is my design goal.

My game server communicates with Apache via FastCGI. I'm actually running Apache on Windows for the moment. All this will run on a dedicated "dual-core" server. The game server application itself is written in C++ and the transactions are pretty simple and fairly low bandwidth (maybe 2k data per) so I'm not too worried about the game server piece.

My client is written in Javascript and uses XMLHTTP to communicate with the server.

So am I smoking something to think I can get 500 to 1000 transactions per second? If so, what number might I expect?

Improve this question
3
  • 2
    500-1000 transactions per second might be reasonable, but it really depends on what your "dual-core" server actually is. Unlikely on an Atom 330. More likely on an i7. What is a fairly simple transaction? You and I might have very different definitions. Your best bet is to build out a minimal server and a test client and start benchmarking your code.
    – ObscureRobot
    Commented Oct 21, 2011 at 17:23
  • @ObscureRoot - Thanks. I'm not looking for an exact answer so just knowing that it "might" be reasonable is helpful. Really just wondering if I'm off by an order of magnitude. For the record, it's a Dual-Core AMD Opteron 1216HE running at 2.4 gHz. And I'm sort of defining "fairly simple transaction" as "don't worry about the code I'm writing". My question was really more about whether the overhead of HTTP and Apache, etc were going to kill me.
    – Joe Rice
    Commented Oct 21, 2011 at 21:24
  • Are you asking about database transactions or just opening and closing server requests? Are you considering sockets? Are you budget constrained?
    – jcolebrand
    Commented Oct 25, 2011 at 21:59

1 Answer 1

Reset to default
2

I've seen benchmarks using ab for PHP run at around 500 requests per second and upwards of 1200 per second for Python. Note, however, that these are basic requests that don't really do anything spectacular.

So really, your bottleneck will be your server code: It's definitely possible to reach 1k requests per second using Apache/FastCGI/C++, it all depends on your server hardware and complexity of your server code though (and server-side I/O, etc).

On a side note, is there a reason that you're using this particular tech stack? C++ usually isn't a very nice language to write server code in (as opposed to Java, etc). I might also look at a language like Erlang for server-side code to get around the FastCGI requirement to give your server even more of a boost.

In response to the OP's comments (a little too long winded for a comment):

@Joe Rice: TBH, I'd find it perfectly acceptable that gaming users would be forced to use the most up to date browsers - you can't use old PC-based gaming clients in most environments and you definitely can't in the console world, so why should browser-based gaming be any different? You might be signing yourself up for a world of hurt otherwise, especially given your budget constraints.

If your concerns are around budgeting, why not take a look at node.js as your server tech with socket.io libs both client and server side? There are a few bonuses here:

  • No context switching (well, limited). Same language used both client and server side, so you don't have to be continuously switching mindsets.
  • Graceful degredation handled for you: socket.io has a bunch of built-in fallback mechanisms to handle support on most browsers.
  • node.js supports TCP and (AFAIK) UDP, so you don't have to worry about the overhead of HTTP (although you'd obviously have to deal with UDP synchronizing issues yourself if you chose to go that route)
  • As you're familiar with C++, if you find a bottleneck server-side, you can dive into the library code and update as required.

Of course, there are potential downsides as well. I'm not familiar with any high-usage gaming servers being written entirely using node.js. You can also check out hacknews for node.js flame wars for further potential gotchas with using node as well.

Improve this answer
7
  • He's trying to push as many requests as possible, the bottleneck is server side, and you offer Java? That sounds wrong.
    – Coder
    Commented Oct 25, 2011 at 22:47
  • I'm not a Java expert by any means.. However, from what I've been told by those "in the know", there are all kinds of things that Java accounts for by default that is difficult (at best) in C++. I don't know what the details are (should have mentioned that in my post), but I'd personally be looking into it before I pursued a C++ solution based on the people I'd talked to about it. Having said that, I'd most likely look strongly at Erlang before all else though.
    – Demian Brecht
    Commented Oct 25, 2011 at 23:26
  • 1
    I picked C++ largely because I'm familiar with and know that it's fast. I'm hoping my code IS the bottleneck, so writing it in as efficient a language as possible seemed important. Also the code to interface to FASTCGI is pretty simple:
    – Joe Rice
    Commented Oct 26, 2011 at 1:39
  • Here's a link to the C++ code to interface to FASTCGI: (bitwordy.com/misc/codesample1.txt)
    – Joe Rice
    Commented Oct 26, 2011 at 1:59
  • @jcolebrand I'm mostly concerned with opening and closing HTTP requests. As I've educated myself more on this over the last few weeks I've learned a lot about COMET, long polling and WebSockets. Eventually I'll probably switch over to WebSockets. I'm serverely budget constrained but I can probably force my users to use up-to-date browsers.
    – Joe Rice
    Commented Oct 26, 2011 at 2:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.