Hi, Thanks for the guide.
----snip---- > First of all, it is important to know that most EAS devices will keep > HTTP connections open to SOGo (and thus, Apache) for a long time. This > is required for "push" to work properly. Connections can stay open for > up to one hour, or 3600 seconds. ------------- It is very informative, but might be improved if you want to minimize future help-requests, by: * explaining what symptoms one would experience when SOGo is not correctly setup to handle push devices * explaining if "Push" is mandatory mode or not on the devices (maybe for some devices and not others) * explaining how to setup the EAS device according to the current SOGo setup (possibly disabling the Push feature) ==> this way if a user have a specific issue that is listed in this document, google would immediately index the issue and the corresponding solutions As a testing reader, here are the specific questions I would like to get answers while reading the document: * What would/could occur if a device configured to use "Push" EAS is disconnected from the SOGo server before the one hour timeout ? * Would the synchronization be stopped and the device never reconnecting ? * Will the device reconnect later, leading to the feeling that the SOGo server is not responding ? * Can this lead to inconsistent responses from SOGo (no mail, some objects syncrhonized and not others, ...) ? * Isn't there the same requirement to increase the TCP session lifetime on firewalls ? Indeed they might be set up to cut down old connections. * As the requirements to support "push" is not easy to meet, one solution would be to refuse Push devices connections. Is it possible ? If yes, it would be nice to have an url to the EAS device setup with/without activating "Push" ? ----Snip---- > Example 2 - 1000 users, 100 EAS devices ------------- The 2 examples are great, but an administrator would immediately like to translate this to the server's requirements, so for these 2 examples, it would be great to have an idea of how much RAM/CPU would be required. Thanks again for the great work on SOGo. Best regards, Thibault Envoyé de mon iPad > Le 6 févr. 2015 à 19:09, Ludovic Marcotte <lmarco...@inverse.ca> a écrit : > > Hello, > > Here is the first draft related to tuning SOGo / Microsoft Enterprise > ActiveSync. > > Feel free to comment - as it'll be included in our official documentation. > > === SNIP === > First of all, it is important to know that most EAS devices will keep > HTTP connections open to SOGo (and thus, Apache) for a long time. This > is required for "push" to work properly. Connections can stay open for > up to one hour, or 3600 seconds. > > The first parameter to check is related to Apache's proxying to > SOGo: > > ProxyPass /Microsoft-Server-ActiveSync \ > http://127.0.0.1:20000/SOGo/Microsoft-Server-ActiveSync \ > retry=60 connectiontimeout=5 timeout=360 > > The above line sets a timeout for up to 360 seconds, or 6 minutes. If > you want to let EAS clients keep their HTTP connections open for up > to an hour, you must change the timeout parameter and set it to 3600. > > If you change this value, the WOWatchDogRequestTimeout parameter must be > changed > accordingly in SOGo's configuration file (/etc/sogo/sogo.conf). By default, > a SOGo child process is allowed to handle a request that can take up > to 10 minutes before it gets killed by its parent process. When using > EAS "push", the client expects to keep its connection open for up to one > hour - so the WOWatchDogRequestTimeout, which is set in minutes, > must be adjusted accordingly. > > EAS clients clients will keep HTTP connections open for a long time > during these two EAS commands: Ping and Sync. By default, SOGo will prevent > EAS clients from keeping connections for a long time. This is to avoid the > situation where all SOGo child processes would be monopolized by EAS clients - > rendering the SOGo web interface or DAV interface unavailable. The > default SOGo behavior is thus similar to disable EAS push entirely. > > Two SOGo configuration parameters are available to modify this behavior: > SOGoMaximumPingInterval (set by default to 10 seconds) and > SOGoMaximumSyncInterval (set by default to 30 seconds). If you want > connection to stay open for up to one hour, you should set these > slightly under 3600 seconds (say 3540 - or 59 minutes). During a > long-lived HTTP connection, the SOGo child process will perform > internal polling to detect changes and return them to the EAS client > if any changes are found. The parameter used to control this > is SOGoInternalSyncInterval. By default, polling is done every 10 > seconds. This might generate too much load on large-scale system. > > The last configuration parameter to adjust is WOWorkersCount - which sets the > number of SOGo child process that will be used to handle requests. > You should have at least one child per EAS device configured to use > "push". You must also have more children than you have EAS devices > configured to use "push" - in order to handle normal SOGo requests to > its Web or DAV interfaces. > > Here are some usage examples for EAS devices using "push". In all > cases, the Apache timeout is set to 3600 and the > WOWatchDogRequestTimeout parameter is set to 60. > > Example 1 - 100 users, 10 EAS devices > > WOWorkersCount = 15; > SOGoMaximumPingInterval = 3540; > SOGoMaximumSyncInterval = 3540; > SOGoInternalSyncInterval = 30; > > Example 2 - 1000 users, 100 EAS devices > > WOWorkersCount = 120; > SOGoMaximumPingInterval = 3540; > SOGoMaximumSyncInterval = 3540; > SOGoInternalSyncInterval = 60; > === SNIP === > > Thanks, > > -- > Ludovic Marcotte > lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca > Inverse inc. :: Leaders behind SOGo (http://sogo.nu) and PacketFence > (http://packetfence.org) > > -- > users@sogo.nu > https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
