Hello, I was attempting to run this patch in a FreeBSD jail (very lightweight virtual machine). The first problem was that this patches peruser.c, and I don't have that (yeah, well, had, but I rm -rf'ed my apache-dir, to apply this patch to a clean checkout). So, I looked at http://www.telana.com/peruser.php, but the patch downloadable there was with the same name as the attachment, and from 4 oct 2007. Is there some 'full version' somewere ?
(I was intending to start FreeBSD-bughunting myself) Btw, I haven't found the meaning of those 'Multiplexers', what are they ? -- Jille Taavi Sannik schreef: > 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Ü > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Peruser mailing list > [email protected] > http://www.telana.com/mailman/listinfo/peruser _______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
