Link to home
Start Free TrialLog in
Avatar of AGBrown
AGBrownFlag for United Kingdom of Great Britain and Northern Ireland

asked on

Approximate benchmarks for concurrent connections on IIS 6.0

Does anyone have any rough order-of-magnitude guidelines for the number of connections that IIS 6.0 can sustain, based on available memory, cores, cpus, etc. for both short and long-lived connections?
Avatar of Andrej Pirman
Andrej Pirman
Flag of Slovenia image

Theoretical limits vary from article to article. I remember reading somewhere in the past that IIS on 32-bit machine can handle no more than 8000 concurent connections, while this limit can be patched using some registry settings and pushed up to 40.000 concurent connections.

But all those are theory.
In praxis things work differently. Most of all it depends on application, which serves web page. It might be HTTP.SYS, might be ASP engine, .NET framework, and also PHP, PERL, JSP and others. Which might run as CGI or ISAPI module. Also, lots of resources are eat by database, which might be Access via ODBC, MSSQL, MySQL or others.
So I think there is no document, which would take into account all those parameters and be able to set some theorethical limits under all different circimstances.

So, by my oppinion, the best is to go from back - list your expectations, what you will host, databases etc, and those with expertise will be able to say if it will run or not.

For example:
on my Intel Core2Duo 2,13 with 2 GB RAM and 143 GB RAID 1 disks,
I run IIS with 200+ web pages, PHP, MSSQL, MySQL, .NET and ASP. Average concurent connections are between 15 and 50, monthly traffic around 1,5 GB, and it runs smoothly, without any problems.
I tested it with IIS Stress Tool and it handled over 176.000 visitors per hour, being from 8 to 32 simultaneously on, wizhout noticeable problems.

While on the other hand, I had some lousy PHP/MySQL programmers pages hosting, which were writing really bad PHP/MySQL code, so hosting their home-made portal slowed down my whole server.
Sorry, misstyped:
...I run IIS with 200+ DOMAINS (not web pages)
...monthly traffic around 1,5 TB (not GB)
Avatar of AGBrown

ASKER

That helps a bit I think - do you have any links to the articles?

Pretty much the situation exactly: long running requests to a web service written in .NET which just sits and waits for an event to fire before returning (rather than polling at intervals - there is a reason, and both techniques are used in this application). The service will be written using async techniques so that the IIS thread is only used during the setup and after the event fires and the background thread returns.

No database connections open during the long part of the request - only during the initial few milliseconds while things are setup for the wait.

Hardware - single HP DL360 G5 server with 4 x 72 GB 10k rpm disks in RAID 5, but with IIS running on a VMWare virtual machine using 2 cores from the dual 2-core CPUs on the host. RAM configurable - up to 2 GB available for the VM. Will later migrated to it's own server but this is what it uses at the moment - so if possible I'm looking for rough benchmarks for connections (concurrent, for long running requests, and per second for instant requests) for a similar setup.

Andy
Avatar of AGBrown

ASKER

If this provokes any more discussion; I'm hoping to be able to handle about of the order of 1000 concurrent connections - approx 50 % of which will be taken up with these long-running requests to the web service.
ASKER CERTIFIED SOLUTION
Avatar of Andrej Pirman
Andrej Pirman
Flag of Slovenia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of AGBrown

ASKER

I have to write the app in order to get to the testing stage; at the moment I'm trying to get some rough orders of magnitude (do I need one server or 100 to get this to work).

I have only just picked myself up off the floor from laughing so hard - I thought I was the only person who did things like that.

Andy