I'd like some feedback from sites that handle a fair amount of webmail 
traffic; specifically the CPU load and memory footprint.  I am considering 
switching to a different internal architectural design.  Right now, a new 
process is started to handle every HTTP request.  After generating the 
response, the process terminates. 

A new design under consideration involves a much smaller cgi stub process.  
A  succesful login leaves a permanent process in place; and the small cgi 
stub process forwards each HTTP request to the login process to handle. 

It's not possible to have a one-size-fits-all estimate of the resulting 
impact.  This design should work better on platforms with an expensive 
exec(), but a cheap fork(),  since each HTTP request will result in a much 
smaller process to exec().  On the other hand a cheap exec() and an 
expensive fork() will make things worse due to an extra fork() in the new 
model.  Another good metric to have is an estimate on the number of active 
login sessions.  Under the current model a login session does not require 
any resources except when an HTTP request comes in.  Under the new model 
each login session will have an idle process; until the session logs out or 
times out due to inactivity.  The issue is whether the lessened CPU load, 
from replacing an exec() of a heavyweight process with an exec() of a 
lightweight process, and an extra fork(), offsets the increased RAM 
requirements from keeping login sessions idle. 



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to