[WEB400] pbA/Classic Load Testing...

["Brad Stone" <brad@xxxxxxxxxxxx>]

I got the PTFs installed that fix the speed of CGI on the
pbA server.

The results look promising.  There is still an over
abundance of jobs being started with the pbA server which is
slowing it down.

I did a request to each server of 50 requests to a CGI
program.  Starting with one CGI job running on each.  I
specified a max of 40 jobs to be started.

Classic won this first one by a longshot.  Only started 8
more jobs.  pbA started 39 more, which slowed it down.

I did the test again with the extra jobs still running
(total of 9 for Classic, 40 for pbA).  This time proved to
be better.  classic inched out ahead by only 6.5 seconds.

I did yet another test, 100 hits per machine with the extra
jobs still running (again, 9 for classic, 40 for pbA).
Classic inched out again by about 11 seconds.  And classic
didn't start any more jobs, even for the 100 hits.

It does look promising.  pbA is there, but for some reason
likes to start more jobs, which slows it down.

So, I ran another test.  This time instead of using RPG
sockets program, I used a Java sockets program utilizing
threads instead of jobs.

Test 1, winner was pbA by about 8 seconds.  Both servers
started the max of 40 jobs.
Test 2, winner was pbA by about 13 seconds.
Test 3, winner was pbA by about 108 seconds.

If I just had a bigger box to test on.  I'd like to see if
there is a big difference in the percentages.  But the
results look promising!

Now I'm just reasearching why java threads and jobs act so
differently!  It would appear to me that the threads are
"quicker" to make the request than the jobs, which explains
why more CGI jobs were started with the classic server than
with just using multiple jobs submitted.

Oh well, spoiler for my next article.... things look good
for the pbA server!

Brad