http://www.mail-archive.com/peruser@telana.com/msg00347.html

Re: [peruser] Peruser Major update

   Taavi Sannik
   Sun, 18 May 2008 11:44:47 -0700
Greetings From DataCode Team!

This our update patch for peruser 0.3.0. Praise and criticism is welcome.

Features it provides:
* Multiplexer pool: Multiplexer are spawned automatically if more of them are
needed. No need to
specify duplicate Multiplexer configuration lines anymore. If you do that, then
apache starts with
more multiplexers, but maintenance will clean them up in a while.

Configuration variables:
MinMultiplexers 3 #minimum amount of multiplexer that will be kept
alive. Defaults to 3 if unset.
MaxMultiplexers 20 #maximum amount of multiplexer that will be allowed
to spawn. Defaults to 20 if unset.


* Multiplexer now checks if the processor has any available children and will
try to wait for it, if
it doesn't. If the multiplexer is not able to pass the request within given
time then the request
will be dropped. With each failed pass, the multiplexer will wait less time
(and eventually it won't
wait at all).
This should protect the multiplexer(s) from hanging if someone is hammering the
processor with
number of requests it can't handle.
The multiplexer should actually return an error page if it can't pass the
request , but I haven't
found a way to do that without locking up the multiplexer.
I've also added AVAIL property to the server status page, which shows how
available the processor
has been to the multiplexer with last requests (100 = ok, 0 = not available at
all).

Configuration variables:
ProcessorWaitTimeout 2 10 # First argument defines the maximum time multiplexer
waits for the
processor (defaults to 2 seconds), second argument defines the number of steps
between maximum
waiting time and no waiting time (defaults to 10 and is optional).


* Processor server environment configuration directive has been changed. We
added this style of
directive because of new variables coming in the future that need to be
specified per processor (eg.
nice level). This addition also allows us to set further possible restrictions
to specific
processors (cgroups, memory limit?). If people would really like to use the old
style, then I can
supply with a modified version of this patch (which then also lacks the feature
of nice level).

Example processor configuration:
<Processor [unique string processor identifier]>
   User bob # Processor user
   Group  bob # Processor group
   Chroot /home/bob # Processor chroot (optional)

   # Optional nice level, this is relative to main httpd process's nice level
   NiceLevel   0

   # Additional server environment variables can be overriden here
   MaxProcessors       10  # total number of processors at the same time
   MinSpareProcessors  3   # how many idle processors to keep alive (to handle
request spikes)
   MinProcessors       0   # minimum processors that will always be kept alive
(idle or working).
</Processor>

In <VirtualHost> you must use "ServerEnvironment [processor identifier]". The
MaxProcessors,
MinSpareProcessors and MinProcessors directives should still work within
<VirtualHost> directive.


* Server status now displays the child scoreboard status. This is more useful
for debugging.


* Bugs fixed:
- MinProcessors and MinSpareProcessors should now work correctly.
- Multiple definitions of Processors with same senv is not allowed anymore.
- Fixed "Could not pass request to proper child, request will not be honoured."
error hanging the
multiplexer for 10-15 seconds.
- Fixed IdleTimeout and ExpireTimeout not set to default if it was removed from
configuration and
graceful was used
- Fixed invalid error message for MinProcessors (stating that the MaxProcessors
directive is invalid)


   Note: As always, this is experimental. Use at your own risk. For
   information we are running this on production environment for 2 hours
   now. No sparks so far. Everyone can make their conclusions from there.

--
Taavi Sannik
DataCode OÜ