[horde] Best timing settings for Horde ActiveSync

Mon Jan 12 12:57:30 UTC 2015

Citeren Patrick De Zordo <patrick at spamreducer.eu>:

>>
>> The best thing to do is to allow the device to manage the heartbeat unless
>> you have a really good reason for not doing so.  The heartbeat interval
>> indicates the amount of time that a PING (or looping SYNC) is allowed to run
>> (thus keeping a connection open on the webserver) if no changes are
>> encountered. It doesn't have anything to do with how long after the request
>> completes that another request is issued.
>>
>> You should tail the synclog of a OL2013 client and see what request is
>> running
>> when you see this slowdown. If there is an active PING or looping SYNC
>> running and you are seeing this delay, it could be that decreasing the
>> "waitinterval" might help. This determines the number of seconds that the
>> server sleeps between each iteration of the loop that checks for changes
>> within a single PING/SYNC request. Though this value is used for every
>> request (and is not something the client
>> controls) so I'm not sure why it would affect OL and not other clients.
>>
>> If you notice a delay in the time between the end of one PING and the start
>> of the next, then there is nothing we can do server-side to change that.
>
>
> I've tried to debug a bit the things..
> Please download this file:
> https://www.dropbox.com/s/tsdjfeaumhiy79p/BUG%20OL%20slow%20response%20on%20new%20message.zip?dl=0
>
> This is the timeline:
> - I have connected 1 Android and 1 OL2013 client via ActiveSync to our server
> (we are using Horde GIT version from some weeks ago).
> - The problem is happening just with the OL2013 client
>
> In "9A9F4000B00444C8BC2C1E40D55ED522_sleeping.txt" log file you can see some
> tailed details about the OL2013 client
>
> OL2013 is working normal till 10:07:32: You can see "Sleeping for 15  
> seconds."
> In log again and again..
> From 10:07:32 - 10:12:50 -> nothing, sleeping, winter sleep..
> From 10:12:55 - 10:18:04 -> nothing, sleeping, winter sleep..
> From 10:18:05 - 10:23:23 -> nothing, sleeping, winter sleep..
> From 10:23:23 - 10:28:45 -> nothing, sleeping, winter sleep..
> From 10:28:50 - 10:34:08 -> nothing, sleeping, winter sleep..
> From 10:34:13 - 10:39:31 -> nothing, sleeping, winter sleep..
>
> Then 3 times:
> 2015-01-12T10:39:32+01:00 INFO: [3158] Sleeping for 15 seconds.
> 2015-01-12T10:39:47+01:00 INFO: [3158] Sleeping for 15 seconds.
> 2015-01-12T10:40:04+01:00 INFO: [3158] Sleeping for 15 seconds.
>
> From 10:40:23 - 10:45:41 -> nothing, sleeping, winter sleep..
>
> Then again lot of times:
> 2015-01-12T10:46:09+01:00 INFO: [10625] Sleeping for 15 seconds.
> 2015-01-12T10:46:25+01:00 INFO: [10625] Sleeping for 15 seconds.
> ..
>
> On 11:30:xx - I have marked 1 message as read on smartphone..
> From 11:30:16 - 11:48:24 -> nothing, sleeping, winter sleep.. (at  
> 11:45:25 - I
> have deleted another 2 messages on smartphone, just to clarify log lines)
> From 11:48:28 - 12:08:05 -> nothing, sleeping, winter sleep..
> From 12:08:10 - 12:13:28 -> nothing, sleeping, winter sleep..
>
> OL2013 is showing "All folders are up-to-date" all the time..
>
> So what is maybe causing this big delays?

What is your webserver configuration? Could it be that the process  
that is looking for changes in the mailboxes is killed before the  
$conf[activesync][ping][heartbeatmax] (in your case, 2700 seconds) is  
elapsed? That might explain why some devices (which use a lower  
heartbeat interval) may not notice anything strange, but one that does  
use the maximum allowed time, to show erratic behaviour. The requests  
will just timeout in that case, meaning your Outlook client expects to  
be informed of any changes, but the process that should do that, died.

Note that you should configure the idle time for your PHP processes  
(and connections to them) to at least an hour, since ActiveSync allows  
this to be up to 59 minutes. In my case, I had to set

     ProxySet timeout=3600

in my Apache config (I use mod_proxy_fcgi to connect to php-fpm) in  
order to prevent this.

> Could this be a BUG, so I could create a new BUG?

I suspect this is just a process timing out.

> If you need a complete Horde sync log, I could give you another link.
>
> Thank you!
> Patrick.

-- 
This message was sent from a mailinglist subscription address.
For off-list replies, you must remove the address extension.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 11647 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20150112/22fbf74f/attachment.bin>