The Cgisock Performance Page

In an attempt to quantify exactly how fast CGI servers using the Apache Cgisock module

can go , this page has been prepared to provide some details as to the results of the various

benchmarking procedures imposed on  this module and how it performs under various loading conditions .
The methods used for the moment consist of hits produced from the Velocigen VeloMeter package as
provided by the Binary Evolution Company .The sript used in this demonstration is the test_harness script
supplied  with cgisock 0.1.0 and written in Perl . Although the task that the script used in this benchmark is
simple in its method , the comparitves  are the equivalent output  produced by direct file serving with the same
conetent . It is aknowledged that many CGI scripts will produce more relevant output consistent with the
content served by a web site , it must be understood that the CGI programmer has many alternatives to
CGI implementation that are not covered here by this benchmark .

The script used in this test is a single a single threaded script and as such is limited by its capacity
to service requests on the provision that it has completed the previous request in its entirity and will not service
further request until the previos request has been closed . So without further ado , the figures .

   The first illustration shows the results of the cgisock script interacting with a single client producing
1000 requests in sequence pending reults from the server . This graph gives a somewhat basic overview of
the consistent server response of a script that is ready and waiting for the next hit . The colour scheme is
as follows .... The yellow dots represent  the responses given by the cgi server and the blue dots represent the
same content delivered by the Apache server as a static html page . An important point must be made here
that the platform used is Linux and as such , once several calls have been made on the same page , the Linux
Kernel will cache that page so that  repeated disk accesses are not required .

    Figure 1.  1000 accesses with CGISOCK vs Static page serving.

The second illustration depicts a simulation of 10 clients accessing the server simultaneously with each
client accessing the same page content 200 times to give an overall 2000 serves for the entire simulation.
Note that for this test ( as with all the test in this bracket ) 20 server processes were used .

Figure 2.  2000 accesses with 10 simultaneous clients

In this simulation it must be noted that although there are ten times more clients to the single thread
process producing the web pages the responses from the the CGI server manages to retain a near
linear reponse time to the client requests . The third illustration simulates 100 clients trying to access
the same page simultaneously . Although there are 100 clients accessing the same server , it still
manages to attain a near linear reponse time to the increased load . The completetion time for all the
tests illustrated in this page was approximately 56 seconds , demonstrating the maximum serving
capacity of this script which served all 2000 requests without failure .

Figure 3.  2000 accesses with 100 simultaneous clients

Further Results: Faster than static file serving

After some more krufting of code , I present for your enjoyment further results from the
torture chambers . Deep in the dungeons of the Castle and after some krufting kludging together
of C source code , two more scipts were added to the cgisock test harness series . The first was
a single thread program that does exactly the same thing as test_harness , only faster , the
second is a multi - process monster using simmilat techniques to Apache itself . Using this
its was possible to out serve apache static file serving under heavy loads . The following
illustration depicts one of the runs where Apache kept its act together for the duration
of the test . Please note that pushing Apache this hard on such limited hardware can uncover
bugs that do not usually show up . Average hit rates of about 65 hits per minute were
typical .

Figure 4.  1000 accesses with 100 simultaneous clients

Please note that not long after this test , Apache stopped serving pages and started acting
erratically . The reason was that I had hit the server with sufficient hits to swamp syslogd
and as such apache welded shut while the syslogd was restarting ( serval times withing the
space of about several seconds . Me Apache log had grown to over 4Mbytes in length .)
The second illustration is with a reduced server count ( 20 server children were begining to get in
each others way so I dropped the count . The CGI server children count was 6 ).

Figure 5.  2000 accesses with 100 simultaneous clients

The above benchmarks were carried out using Apache 1.3.4 with mod_cgisock 0.1.0 on a 486 dx 133 .
The 486 was equiped with 40Mb of RAM with a 4.2 Gbyte Seagate IDE Hard drive over a PCI bus
connection . The client machine was a equipped with a Cyrix 300 Mhz Process running blackdowns
JDK V1.17 Linux port , Window Maker Version 0.4 a Seagate 4.2 Gbyte Hard drive 32Mbytes of
RAM and a 75Mhz PCI bus . The network interfaces were accomplished with two ( extremely budget )
ne 200 compatible 10 base 2 10Mbit/s ethernet cards on ISA interfaces . The operating system used on
both machines was Linux 2.0.36 which ( as usual ) performed flawlessly . The output from
Velocigens(TM) VeloMeter(TM)was resized using the GIMP in conjunction with xpaint for
gif converstion . All trademarks are  copyright of their respective owners and Linux is a
copyright  of Linus Torvalds .

This document has been prepared in the interests of the general public .