The benchmark consists in parallel request to the HTTP Server executing the ISAPI DLL from massive requests processes running on different computers. This NT server is a Dual PII 400MHz running IIS4.0 and InterBase 5.5. This benchmark is measuring the performance of the server (concurrent transaction processing), not the performance of the network (100 MBits backbone). Without database transaction the server can handle:

• 6,000 requests per minute
• equivalent to 40,000 transactions per minute in CPU time at the level of the ISAPI DLL
• It took 9 seconds of internal CPU time to process the 6,000 requests
• The average display time for a page is 20ms = 0.02s

With database transaction the server can handle (selection of a dozen of records, building the XML, merging it with the XSL to produce the resulting HTML and returning the whole stream to the web browser)

• 3,500 requests per minute
• equivalent to 4,200 transactions per minute in CPU time at the level of the ISAPI DLL
• It took 50 seconds of internal CPU time to process the 3,500 requests
• The average display time for a page is 35ms = 0.035s

This benchmark can be interpreted as :

• If a user changes 10 times of page per minute (this means every 6 seconds the user posts a new request and a new HTML page is generated), the application can handle up to 350 simultaneous users
• If the normal work of a user on your applications is to process an average of 1 transaction per minute, the application can handle 3,500 simultaneous users
• A user waits 35ms for each of its request
• In a company with 50 employees, every employee can click 33,000 times in the browser during the day, before the server makes the user wait

With all the applications of your information system in your intranet, an employee makes, in average, 250 requests during a day of work (8 hours). 250 requests a day means that the user retrieves 250 generated pages, and he is reading each of these pages. This average employee is a tremendous fast reader, but nowadays, navigating the information through these applications makes the user very efficient in its work. Based on this real case study, here are the key points of what this benchmark really means :

• The server is working 8 seconds in CPU time per user during a day
• Your application server can handle up to 6,000 employees working simultaneously. Beyond this limit, the users will have some waiting time superior to the second
• Peaks can handle up to 28 concurrent requests to maintain a human affordable (acceptable) delay (=1s : which is considered as a human real time processing). Beyond this limit, the users will have some waiting time superior to the second

Remarks : We recommend up to 10 concurrent XMLModule per processor.

 Back to Top