[imp] IMP 5 polling

Joe Besko jbesko at msu.edu
Fri Sep 30 00:04:31 UTC 2011


Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Joe Besko <jbesko at msu.edu>:
>
>> I've installed Horde Webmail Edition 4.0.3 in a test environment.
>>
>> I've also noticed that it was taking about 18-20 seconds to go from  
>> one message to the next (with an additional 15-20 seconds for the  
>> sidebar to refresh.)
>>
>> I thought it was odd that it behaved that way, since my previous  
>> version of Horde Webmail 1.2.5 did not behave this way.
>>
>> After some searching and some testing, I found that the "poll all  
>> folders" option was the culprit to these long delays.  When I turn  
>> off the "poll all folders", IMP and DIMP are very snappy and  
>> perform as I would expect.
>>
>> Now I have a question, is IMP supposed to poll all folders after  
>> deleting/moving to another message?  It seems in the prior version,  
>> we just polled all the folders after we processed the current list  
>> of messages we were viewing.
>
> If you are using the traditional view, and you have the sidebar  
> open, then yes - this is the intended behavior.  Horde 3 loaded the  
> sidebar in an IFRAME so its refresh rate was independent of what was  
> happening with the application.  Horde 4 now loads the sidebar in a  
> DIV instead, so it is reloaded every time a page is changed (sidebar  
> data is not loaded if the sidebar is collapsed).
>
> The dynamic view does not have this problem.  It polls only at  
> whatever interval you configure it to (and is independent from any  
> message action).

Ok, that makes sense.

>> The problem I run into when I don't poll all folders is that I  
>> don't know where the filter has moved new messages outside the inbox.
>
> You should really be using dynamic view then.  Traditional  
> view/sidebar was not designed for performance - dynamic view is.

Noted.  We'd probably push users this way, since most have griped  
about the "dated" look of the Traditional mode.

> Although some other issues are at play here also.  The base IMAP  
> 4rev1 spec was *NOT* designed with this sort of polling feature in  
> mind and, in fact, the RFC explicitly discourages it  
> (http://tools.ietf.org/html/rfc3501#section-6.3.10).
>
> That being said, it is tremendously useful for practical purposes,  
> so the LIST-STATUS IMAP extension was recently introduced (RFC  
> 5819).  15-20 seconds seems long to poll all mailboxes; my guess you  
> are using an old IMAP server that doesn't support mailbox caching  
> and/or LIST-STATUS and an upgrade to an IMAP server that does  
> support this functionality (e.g. recent versions of Dovecot, Cyrus)  
> will dramatically improve your performance.  We can only do so many  
> tricks on the MUA side to increase performance.  If you truly need  
> real-time updates of mailbox counts, we can't provide those updates  
> any faster than the IMAP server gives them.

This is probably our IMAP server then.  We're running courier, but I'm  
not certain which version, nor when we last updated it.

> Also important - you should really rethink using poll ALL mailboxes.  
>  I use filtering, but I filter to a certain subset of mailboxes  
> (10-12).  Unless you are truly using every mailbox in your mailstore  
> to filter messages into - I highly doubt, for example, you are  
> filtering incoming messages into things like your Drafts or Sent  
> mailboxes - you should manually select the mailboxes to poll instead.

Good point and putting this information to good use, and I am in the  
situation you described.

> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]

Thanks for the feedback, it was quite helpful.

-- 

Joe Besko                      Phone:        517.432.5335
Systems Programmer             Fax:          517.353.9847
Michigan State University      E-mail:       jbesko(a)msu.edu
313 Computer Center
East Lansing, MI 48824-1042





More information about the imp mailing list