[Xitami] Load/Stress Testing Xitami

Thomas J. Hruska shinelight at shininglightpro.com
Wed Aug 1 13:13:26 CEST 2007


Russel Olinger wrote:
> Thomas,
> 
> Comments inserted below
> 
>> Russel,
>>
>> You didn't mention if you are using PHP or some other scripting
> 
> I am using Win32 Perl
> 
>> language, but I'm not aware of any method to query a MySQL database
>> without one.  Scripting languages under Xitami typically require CGI.
>>
>> When CGI runs like that, the CPU gets hammered because you've got new
>> processes being created left and right.  The system is spending most of
>> its time starting up and shutting down processes.
> 
> Doesn't Xitami create an individual Perl process per cgi script being 
> called?  If 25 users hit the server at once then that would be 25 perl calls 
> with 25 instances Perl.exe running?  How would Apache and IIS handle a 
> similar situation?

When running as a CGI, both Apache and IIS would handle it the same way. 
  However, Perl has both mod_perl (Apache) and Perl for ISAPI (IIS) 
modules available.


>> I ran a similar test spread across 15 machines on a LAN once with Xitami
>> via CGI and got similar results (I wrote my own tool).  Xitami simply
>> couldn't handle the load.  Most of the time it just returned blank
>> pages.  I don't know what tool you are using but socket code fails if
> 
> Using Microsoft Web Application Stress Tool ver1.1 .  Do you recall the load 
> it was able to handle?  And is there anyway you could think of to push the 
> 25 connections per second without moving to PHP?  And doesn't the Xitami PHP 
> get handled by the CGI processor so there is no real advantage to moving to 
> PHP?

I was using PHP as an example.  And, as I said, I don't recall the load 
but it wasn't much.  See below for improvement ideas.


>> you mass connect to a server in rapid succession (Windows hangs onto
>> socket handles until TCP closes down cleanly or times out)...for my
>> test, I wrote a tool to manage the process and just retried the
>> connection on failure (i.e. it is almost always the client that fails to
>> connect because all sockets are in use).  Keep in mind that this test
> 
> The Client fails to connect because the client sockets are in use or the 
> Server sockets are in use?  If its the Server sockets in use, using Win2003 
> Server is there away to increase buffers specfically for more web sockets to 
> be created ?

Client sockets are in use.  Haven't run into the issue of running out of 
server sockets before.


>> In theory, if you are using PHP, you should be able to drastically
>> improve performance and security by using Xitami LRWP, multiple
>> instances of the ISAPI LRWP daemon (isapid - probably still a 'beta'),
>> and the ISAPI PHP module.  Then, in your PHP code, use persistent
>> connections to the MySQL database (i.e. mysql_pconnect()).  LRWP, IMO,
>> is a weak protocol - it can only handle one request at a time.  For the
>> load you describe, 10-12 instances of the ISAPI LRWP daemon will
>> probably be sufficient.  The server will still be hammered but should be
>> able to handle the load.

The above applies to "Perl for ISAPI" as well.  Apparently ActiveState 
includes a closed source ISAPI filter with their Perl distribution. 
However, as far as I know, Perl doesn't have a mysql_pconnect() 
equivalent - so you'll be hurting performance in the database area.

-- 
Thomas Hruska
Shining Light Productions




More information about the Xitami mailing list