0

I've always used apache benchmark to try to get a rough idea of how many requests/second my server can handle. I read that it was good, and it seemed to work well.

Enter node.js, which is fully event-based, so it never blocks. If I run apache benchmark on a simple hello world server it can handle 2500 requests per second or so.

However, if I put a timeout in the hello world function, so that it responds after 2 seconds, apache benchmark reports a dramatically reduced throughput: about 50/s. I'm running 100 concurrent connections with ab. If I increase the concurrency, it goes up. This makes sense, because apache benchmark is basically sending out requests in batches of 100, which come back every 2 seconds. 100 requests / 2 seconds = 50 requests / second

If I increase the concurrency to about 400 or 500, it starts to crash. I don't think I've hit node.js's limit, I think I'm hitting a wall in my operating system on the number of open file descriptors or sockets or something.

Any way I can get a good guess about how many requests my server can handle? I want to make sure the test computer isn't the one causing the problem.

Sean Clark Hess
  • 263
  • 3
  • 13

3 Answers3

2

A few things, that may not be entirely relevant.

First, since you have to keep 500 connections open for several seconds, you are probably hitting the maximum number of file descriptors open, which is probably set to 1024. Check the log files, and if you may see errors like too many open files. Try edit /etc/security/limits.conf and increase the number of file descriptors for the apache user.

Second, it seems to me that your test is not representative of the usage you expect. You are testing a system where it takes a long time to prepare the page (e.g. a complex database query is required) and the client waits patiently for it, and not an an event driven page. I do not know node.js, but I assume it will request data from the server as needed, in several small requests, with each request, for the server, being independent. Are there large queries as well? How are they handled? The client waits for them or polls the server to check the status?

For testing, ab seems fairly limited in what it can do. You may want to try other utilities. A quick apt-cache search brought up several (I have not used them), like httperf, hammerhead

Maybe other with more experience in web testing will chime in.

Dan Andreatta
  • 5,384
  • 2
  • 23
  • 14
  • Great, I'll look into the limits and those other utilities. I'm sorry I wasn't more clear. node.js runs on the server, not the client. It is my application layer (like php, ruby, java, etc). – Sean Clark Hess Apr 08 '10 at 19:39
1

What is "it" in "it starts to crash"? The benchmarking tool or something on the server? And do you get any exception reports at all, directly from the failing component or output to log files?

If the problem is ab (the benchmark program) not liking that many active connections, try running more than one instance concurrently.

If it is the OS (or some interaction between ab and the OS) imposing a limitation, try multiple copies of ab but spread over different machines. Virtual machines on the same host may work if you don't have any spare physical machines to try.

In either case (server or client side), your hunch about limits to the number of open sockets and such may well be correct.

David Spillett
  • 22,534
  • 42
  • 66
  • "it" is apache benchmark, most of the time. It fails with the error: `apr_socket_connect(): Connection reset by peer (54)` -- Although infrequently my node.js server also stops running. – Sean Clark Hess Apr 08 '10 at 19:41
0

Use IBM RATIONAL PERFORMANCE TESTER to test the server through put, it will provide you results in form of graphs and tables that shows you bytes received and the bytes sent

Engr.Ariba
  • 1