[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