[Xitami] 50+ simultaneous users...

[Thomas J. Hruska]

At 05:20 PM 3/14/2002 +1300, Ewen McNeill writeth:
>Without having run into this before myself, my hunch is that there's
>perhaps some race condition in Xitami between when the temporary files
>are read in (from the CGIs), and when the size of the file is recorded.
>In which case this would be most obvious when the load on the machine
>gets fairly high (and 50 simultaneous users all running CGIs at once
>would start to do that).
>
>Is it only the log entries affected?  Or are the results that are sent
>back wrong as well?

The results are incorrect as well (that is, the logs reflect what is
returned to the client and vice versa).  Xitami isn't dropping data being
sent back to the client.

>These sorts of problems are very time consuming to track down (often
>debugging is a matter of staring at the source code to try to figure out
>what might be causing it, changing something "likely" and trying again).

I can modify the DAS for localhost use only and send you the DAS and DAC
along with the CFM, PHP, and Perl scripts (Nuclear Vision scripts would be
semi-worthless since the executable hasn't been released yet).  The DAC
isn't 100% bug-free yet (but it is close - I just pinpointed one very
elusive bug that took forever to figure out what was going on), but the DAS
should be able to withstand anything thrown at it.  Ewen, let me know if
you want a localhost version for testing Xitami.

>If anyone else has seen anything similar and/or has any hints about what
>triggers it, it'd be useful to know.

My best guess is that there could be an OS limit on the number of processes
Xitami is allowed to start.  If that is the case, it is somewhere around
100 (50 * 2) processes (XiFusion creates a process for the CFML
executable).  I'm wondering if the NT service process limit has anything to
do with this.  I would generally think processes started by services would
be separated from the service, but they could be counted as service
processes (I think 128 service processes is the default limit).  If this is
the case, a DoS/DDoS attack could easily be created to cause about 90% of
connections to Xitami servers to fail.

If a service process limit is the problem, the solution is to track if
starting the process failed, and if it did, wait a bit (.25 seconds -
controllable from the configuration files) and then try again.  If it can't
create the process for 30 seconds, then kill the client connection with a
response that the server is overloaded.


          Thomas J. Hruska -- shinelight@shininglightpro.com
Shining Light Productions -- "Meeting the needs of fellow programmers"
                  http://www.shininglightpro.com/