Skip to main content
added 1373 characters in body
Source Link
Demian Brecht
  • 17.6k
  • 1
  • 48
  • 81

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.

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.

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.

Source Link
Demian Brecht
  • 17.6k
  • 1
  • 48
  • 81

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.