Re: replacing dovecot POP3 with qpopper (1st post)

Ken A <[email protected]>
Newsgroups gmane.mail.qpopper
Message-ID <[email protected]>
Timothy Meader wrote:
> Wait, so are you saying that on a single system, with 5000 users, that 
> dovecot's POP3 implementation was even faster than qpopper in server 
> mode? If this is true, I might consider switching our POP servers here 
> on center (funnily enough, the same NASA center that an earlier 
> responder to this thread works at) to an all dovecot implementation 
> instead of a hybrid qpopper 4.1/dovecot beta 8 (which incidently has 
> been working fine). There's 3 boxes with roughly 2000 on each.

Yes that's correct, we were running qpopper in server mode with 
fast-update, etc. And not just a little faster, much faster. The system 
load avg went from 3 or 4 down to 1 and has stayed there with dovecot. 
We have mailboxes ranging in size from 0 to 100mb, with lots of mail 
left on the server. Dovecot handles about 10,000 pops an hour. The speed 
is due to the indexed mboxes, caching and less i/o. However, dovecot 
works a bit differently and isn't rfc compliant out of the box, so there 
are some trade-offs.

One notable trade-off with pop3, is that dovecot doesn't copy the file 
to a temp drop like qpopper does, so there's less i/o. But, by default, 
session locking is off, so 2 users can simultaneously pop the same mbox, 
  which isn't a good thing sometimes :-\. If you turn on session locking 
(which is part of the rfc for pop3), you can get into problems with your 
LDA processes waiting for Dovecot to release a lock on the mbox file if 
a client leaves a pop3 session open a long time. You can tweak timeouts 
in dovecot to work around this though. Obviously, you have to make sure 
all clients and your LDA are using compatible locks.

Ken
Pacific.Net


> Thanks in advance.
> 
> At 11:16 AM 6/2/2006, Ken A wrote:
>> Obantec Support wrote:
>>> Hi Ken
>>> I cannot live with the file .lock problem beta8 is supposed to fix 
>>> but so
>>> far Timo has not come up with a reason for beta8 not running on my mail
>>> server.
>>> if he can resolve the issue then i will stay with dovecot as its 
>>> easier to
>>> have the 1 system set-up. I currently only have around 200 mbox POP3 
>>> users.
>>
>> We'd used qpopper for 9 years, and had very few problems with it. It 
>> logs some spurious errors now and then that generate questions on this 
>> list, but the answer is usually 'read the faq'. 200 mbox users should 
>> be a perfect fit for qpopper.
>>
>> Ken
>> Pacific.Net
>>
>>> Mark
>>> ----- Original Message ----- From: "Ken A" <[email protected]>
>>> To: "Subscribers of Qpopper" <[email protected]>
>>> Sent: Thursday, June 01, 2006 5:11 PM
>>> Subject: Re: replacing dovecot POP3 with qpopper (1st post)
>>>
>>>> Just went the other way, and won't be back to qpopper unless it gets
>>>> indexed mboxes. I still like qpopper, but it's just too slow for > 5000
>>>> users on a single box. Even with all the speed tweaks you can do with
>>>> qpopper, with lots of users leaving mail on the server, dovecot is much
>>>> faster and has been very reliable - so far!
>>>>
>>>> Ken A
>>>> Pacific.Net
>>>>
>>>> Obantec Support wrote:
>>>>> Hi
>>>>>
>>>>> i am having lots of problems with dovecot as a POP3 server with file
>>> locking
>>>>> and the latest beta8 that is supposed to cure this will not run on my
>>> live
>>>>> servers but is fine on a test box.
>>>>>
>>>>> just built qpopper 4.0.8 on the test box and it seems fine. has anyone
>>>>> turned off POP3 in dovecot and used qpopper as their POP3 server?
>>>>>
>>>>> Mark
>>>>
>>>> -- 
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.1.394 / Virus Database: 268.8.0/353 - Release Date: 
>>>> 31/05/2006
>>>>
> 
> ---
> Tim Meader
> CNE Internet Services
> NetCommerce Corporation
> [email protected]
> (301) 286-8013
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.