[horde] Best timing settings for Horde ActiveSync

[Michael J Rubinsky]

Quoting Arjen de Korte <arjen+horde at de-korte.org>:

> 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.


I agree. There is nothing in that log (other than the weird,  
non-sequential order of some of the timestamps and process  
numbers....) that looks like a bug to me at all.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/horde/attachments/20150112/617682e9/attachment.bin>