Server Performance

WASD Hypertext Services - Technical Overview

[next] [previous][contents]

10 - Server Performance

The server has a single-process, multi-threaded, asynchronous I/O design. On a single-processor system this is the most efficient approach. On a multi-processor system it is limited by the single process context (ignoring scripts which execute within their own context). An obvious improvement would be to have multi-processor threading or a pool of server processes, one per CPU, servicing requests. The latter may be the approach of future refinements. No content-caching is performed by the server. All file transfer requires file-system access.

The server has been tested with up to 30 simultaneous requests originating from 6 different systems and continues to provide an even distribution of data flow to each client (albeit more slowly :^).

Simple File Request Turn-Around

These results are indicative only! A series of tests using batches of 200 accesses were made and the results averaged. The first test returned an empty file measuring response and file access time (this server does not cache), without transfer time. The second test requested a file of 16,000 characters, testing performance with a more realistic scenario. Both were done using one and then ten simultaneous requests. No Keep-Alive: functionality was employed so each request required a complete TCP/IP connection and disposal, although the WWWRKOUT utility (see 12.3 - Server Workout (stress-test)) was used on the same system as the HTTPd server, eliminating actual network transport. DNS (name resolution) was disabled. The test system was a lightly-loaded AlphaServer 2100, VMS v6.2 and DEC TCP/IP 4.0. The command-lines are show below:

  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/ht_root/exercise/0k.txt"
  $ WWWRKOUT /SIM=10 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/ht_root/exercise/0k.txt"
  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/ht_root/exercise/16k.txt"
  $ WWWRKOUT /SIM=10 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/ht_root/exercise/16k.txt"

simultaneousduration (seconds)requests/second
0K12.290
0K102.290
16K13.655
16K103.557

Significantly, request turn-around was little changed between one and ten simultaneous requests.

Simple File Request Transfer Rate

The simple text file request under similar conditions indicates a potential transfer rate in excess of 1 Mbyte per second. (Remember, both client and server are on the same system, so the data, although being transported by TCP/IP networking, is not actually ending up out on a physical network.) This serves to demonstrate that server architecture should not be the limiting factor in file throughput.

  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=10 "/ht_root/log/access.log"
  $ WWWRKOUT /SIM=10 /NOBREAK /NOVARY /NOOUT /COUNT=10 "/ht_root/log/access.log"
  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=10 "/ht_root/log/total.log"
  $ WWWRKOUT /SIM=10 /NOBREAK /NOVARY /NOOUT /COUNT=10 "/ht_root/log/total.log"

simultaneousduration (seconds)Kbytes/second
2M (4123 blocks)182,570
2M (4123 blocks)10161,336
7M (14852 blocks)1591,278
7M (14852 blocks)10621,224

Significantly, there were no dramatic drops in transfer rate between one and ten simultaneous requests!

10.1 - File Record Format

The server can handle STREAM, STREAM_LF, STREAM_CR, FIXED and UNDEFINED record formats very much more efficiently than VARIABLE or VFC files.

With STREAM, FIXED and UNDEFINED files the assumption is that HTTP carriage-control is within the file itself (i.e. at least the newline (LF), all that is required required by browsers), and does not require additional processing. With VARIABLE record files the carriage-control is implied and therefore each record requires additional processing by the server to supply it. Even with variable record files having multiple records buffered by the HTTPd before writing them collectively to the network improving efficiency, stream and binary file reads are by Virtual Block and are written to the network immediately making the transfer of these very efficient indeed!

So significant is this efficiency improvement a module exists to automatically convert VARIABLE record files to STREAM-LF when detected by the file transfer module. This is disabled by default but the user is strongly encouraged to enable it and to ensure that stream format files are provided to the server by other hypertext generating and processing utilitites.

10.2 - Scripting

Persistant-subprocesses are probably the most efficient solution for child-process scripting under VMS. See 9.2 - Scripting Environment. The I/O still needs to be on-served to the client by the server.

A simple performance evaluation shows the relative merits of the three scripting environments available. Two results are provided here. Both were obtained using the WWWRKOUT utility (see 12.3 - Server Workout (stress-test)) accessing the same CGI test utility script, HT_ROOT:[SRC.CGIPLUS]CGIPLUSTEST.C, which executes in both standard CGI and CGIplus environments. A series of 200 access were made and the results averaged. The first test returned only the HTTP header, evaluating raw request turn-around time. The second test requested a body of 16,000 characters, again testing performance with a more realistic scenario. No Keep-Alive: functionality was employed so each request required a complete TCP/IP connection and disposal, although the WWWRKOUT utility was used on the same system as the HTTPd server, eliminating actual network transport. DNSLookup (host name resolution) was disabled. The test system was a lightly-loaded AlphaServer 2100, VMS v6.2 and DEC TCP/IP 4.0. The command-lines are show below:

  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/cgi-bin/cgiplustest?0"
  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/cgi-bin/cgiplustest?200"
  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/cgiplus-bin/cgiplustest?0"
  $ WWWRKOUT /SIM=1 /NOBREAK /NOVARY /NOOUT /COUNT=200 "/cgiplus-bin/cgiplustest?200"

CGI (non-persistant)CGI (persistant)CGIplus
0K duration (seconds)28.515.04.4
0K requests/second7.013.345.5
16K duration (seconds)31.418.07.6
16K requests/second6.411.126.3

Although these results are indicative only, they do show CGIplus to have a potential for improvement over standard CGI in the order of 250-300% (when using persistant-subprocesses, or zombies, 400-600% over non-persistant subprocesses), a not inconsiderable increase. Of course this test generates the output stream very simply and efficiently and so excludes any actual processing time that may be required by a ``real'' application. If the script/application has a large activation time the reduction in response latency could be even more significant (e.g. Perl scripts and RDBS access languages).

10.3 - Suggestions

Here are some suggestions for improving the performance of the server, listed in approximate order of significance. Note that these will have proportionally less impact on an otherwise heavily loaded system.

  1. Ensure served files are not VARIABLE record format (see above). Enable STREAM-LF conversion using a value such as 250 (configuration parameter [StreamLF]).

  2. Use persistant-subprocess DCL/scripting (configuration parameter [ZombieLifeTime])

  3. Use CGIplus-capable scripts whenever possible.

  4. Disable host name resolution (configuration parameter [DNSLookup]). This can slow processing significantly. Most log analysis tools can convert numeric addresses so DNS resolution is often an unnecessary burden.

    This can actually make a remarkable difference. Testing using a series of 200 requests for a file zero kilobytes in size produced the following results.


    duration (seconds)requests/second
    DNSLookup ON7.726
    DNSLookup OFF2.677

  5. Disable logging (configuration parameter [Logging]).

  6. Set the HTTPd server process priority higher, say to 6 (use startup qualifier /PRIORITY=).

  7. Reduce to as few as possible the number of mapping rules.

  8. Place more-commonly resolved content-types towards the top of the configuration list (configuration parameter [AddType]).

  9. Disable request history (configuration parameter [RequestHistory]).


[next] [previous][contents]