Timo Sirainen wrote:
Promising. After running a bit less than 9 hours, zero errors with ext3 +maildir and 10 concurrent imaptest clients:
I think dP alluded to this question earlier but I'm not sure if I see a response -- the default setting for login procs is:
#login_process_per_connection = yes
...with all the notes about security ans so forth. The question is though what's a best recommended practice for efficiency and speed? What I'm wondering is that most clients like ThunderBird spawns multiple threads, which cause multiple logins. Typically 3-5 per user on TBird.
So would it be correct to say that 50 people logged in at once would have ~150 login-auth procs running in order to get work done? At what point is a small tradeoff in security worth the recovery of CPU and process space?
If one login proc is already running for the first thread 'user=tengel', do the subsequent threads re-use that same proc instead of launching another? Right now with min=3 and only myself logged in, I see 6 imap-login procs on the stack, and I'm worried that we'll start overloading the system.
Thanks for any input -- just looking at how to best optimize here.
-te
-- Troy Engel | Systems Engineer Fluid Inc. | http://www.fluid.com