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