[Tickets #12705] Re: Rate limit polling for new mail notifications

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12705
------------------------------------------------------------------------------
  Ticket             | 12705
  Updated By         | arjen+horde at de-korte.org
  Summary            | Rate limit polling for new mail notifications
  Queue              | IMP
  Version            | Git master
  Type               | Enhancement
  State              | Assigned
  Priority           | 1. Low
  Milestone          | 6.2
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


arjen+horde at de-korte.org (2013-10-01 19:43) wrote:

>> In my IMAP account, I have a fair number of folders that need to be
>> polled for new messages (about 25) as I use Sieve to sort messages
>> upon arrival. This means checking for new messages is a relatively
>> expensive operation.
>
> What does Sieve have to do with this?  Sieve is independent of polling.

I tried to provide some context why I'm polling this many mailboxes.  
Most of my users don't use filters at all, in which case they are only  
subscribed to the INBOX and this doesn't seem to be a problem.

>> When 'Display notification when new mail arrives?' in the Mail
>> preferences is selected, it looks like this check is performed for
>> each POST request. This means that if multiple POST requests are send
>> more or less simultaneously, this check is run many times in
>> parallel. For instance, if in a month view of Kronolith I move to the
>> next month, 13 POST requests are fired off within a few milliseconds
>> (in my agenda there are six calenders, five address books, one
>> tasklist and one holidays). Each of these will run
>>
>>     horde/services/ajax.php/kronolith/listEvents
>
> That shouldn't happen.  For a task such as this in kronolith, we  
> should really be pooling all of these into a single request.  But  
> that's a separate enhancement ticket...

Will this be tracked in this ticket or do I need to create an additional one?

>> All in all this takes approximately 10 seconds, during which time the
>> check for new messages runs 13 times (pretty much in parallel). If I
>> disable the new mail notifications, the same action takes less than 2
>> seconds (I made sure these aren't cached results).
>>
>> It would be nice if there was a preference that would allow to
>> prevent polling for new messages if less than 'X' seconds have passed
>> since the last poll was started. This would prevent running polls in
>> parallel, fighting for attention from Dovecot and which in the end is
>> just a waste of resources.
>
> We should probably just use the "refresh" interval that currently exists.

Suits me fine.

> This seems a reasonable feature to put into 6.2.

Great!