5

I can't find anything that specifically elucidates the number of concurrent connections that are reasonable - nor can I find any treatises or research on this topic.

The boss says "The server needs to handle 50,000 concurrent users - so measure with 50,000 concurrent connections."

Then I see in at least one popular blog that measuring 50 concurrent connections is equivalent to being Slashdotted or Farked.

What are the numbers? What is reasonable? What isn't? How do the concurrent connections translate to number of users online at any given time?

Mei
  • 4,590
  • 8
  • 45
  • 53

2 Answers2

6

What is reasonable depends on what kind of traffic your server is getting. A typical web server that handles about 1 million page requests per day (and that's quite a busy little server) will rarely ever need more than 50 concurrent connections, unless your page processing is really heavy.

If your average page processing time (i.e. the time it takes from receiving the HTTP request to the time when the initial request is completely dealt with) is around 300ms (and that's quite a lot and will probably get you complaints from your users), then with 50 concurrent connections this server can handle approx. 3 x 3600 x 50 = 540k requests in one hour. However, you need to consider that each picture is a separate request, and so are JavaScript files and CSS files. On the other hand, a lot of these are cached by browsers, so they only get hit once.

Still, that should be good enough for well over 100k pages per hour. Is that enough for you? If not, up the figure.

Mei
  • 4,590
  • 8
  • 45
  • 53
wolfgangsz
  • 8,847
  • 3
  • 30
  • 34
  • Is there any scholarly (and in-depth) research that shows how concurrent connections translate into users on a web site? On top of this, we're testing the back-end of a web site; this means that we'll have to translate from front-end requests to back-end processing. – Mei May 27 '11 at 00:10
  • I am not aware of any (which doesn't mean there isn't). It would be rather tricky in any case, since the ratio between page hits and individual HTTP requests depends wholly on the site that is being served. Plus: you would have to specify what exactly "back-end processing" means. – wolfgangsz May 27 '11 at 08:36
  • In this case, there are two points that provide "back end processing": one generates map image blocks; one provides data from a database. In the first case, it's the web site user that generates the request (indirectly); in the latter, the web server (machine) generates requests on behalf of the user. – Mei Jun 01 '11 at 15:40
  • It sounds as if the proper measure is not "users" but "pageviews" or "page hits". The problem is that the number of (potential) "users" is exactly known (at least at the beginning). The users will be focused on only a few pages - or even just one - that provides data. This page will generate multiple requests for map grid elements. – Mei Jun 01 '11 at 15:45
3

You should try siege.

Siege doesn't simulate connections, but users. More appropriate for your purpose.

erickzetta
  • 599
  • 2
  • 4
  • This is a worthy answer, and siege is in the Ubuntu repositories as well. However, I'm testing the back end of a set of systems - so a direct "user" connection won't help here. – Mei Jun 01 '11 at 15:41