Slow performance of GMS on Windows.

  • 3724926
  • 10-Mar-2008
  • 10-Dec-2013

Environment

Novell GroupWise 7
GroupWise Mobile Server 2.03

Situation

Over a day GMS users do not get updates on their mobile PDA devices, updates are also not visible via end-user WebPIM interface.
During the same time GroupWise end-users face a decrease of performance doing normal work within their mailbox.
This situation can last rather longer time from several minutes up to few hours.

Resolution

A reason behind this usually a GMS user that tries to synchronize larger data into his GMS mailbox / PDA device. It is caused by few mails with larger attachments, for instance +5MB in size, that are requested by a GMS to be synchronized. A situation may vary based upon how much memory resources are available on the server where the POA is loaded.
A Windows based GMS version during this sync process keeps creating many SOAP requests for the POA to get attachment data transfered. Due to a size of requested data Windows server can run out of available TCPIP connections. Moreover, default TCPIP Windows setting keeps a connection locked also on GroupWise POA site for longer time still even after a data was transfered. The POA then consequently cannot handle normal GroupWise client C/S connections.
You can change a Windows TCPIP protocol behavior via Windows registry. More details about fine tuning Windows server can be found, for instance at:
You can adjust following registry settings:

TcpTimedWaitDelay

TCPTimedWaitDelay adjusts the amount of time that TCP waits before completely releasing a socket connection for re-use. Since a GMS server opens many connections to a GroupWise POA to get data included in larger attachments, the Windows server runs out of available entries in the TCP connection table. Even when a request for data has been finished, the Windows server keeps this connection still locked. This prevents other GMS users to get new data synchronized in their GMS mailboxes.


Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: TCPTimedWaitDelay
Data type: REG_DWORD
Range: 0x0 - 0x12C (0 - 300 seconds)
Default: 0x78 (120 seconds)
Recommendation: 0x1E (30 seconds or less based upon a testing results in your production environment)

MaxUserPort

MaxUserPort sets the number of actual ports that are available for connections, we set the highest port value available for use by TCP. This setting enables GMS to open more connections toward a GroupWise server thus allowing more simultaneous synchronizations.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: MaxUserPort
Data type: REG_DWORD
Range: 0x1388 - 0xFFFE (5000 - 65534)
Default: 0x1388 (5000)
Recommendation: 0xFFFE

TcpWindowSize

By default TCP will try to automatically negotiate the optimal window size depending on the maximum segment size. It initially starts at 16 KB and can range to a maximum of 64 KB.

Key: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value: TCPWindowSize
Data type: REG_DWORD
Range: 0x0 to 0xFFFF
Default: 0x4470 (17520 bytes, the Ethernet MSS (1470)) multiple closest to 16 K)
Recommendation: 0xFAF0 (64240)
Few performance tests showed much faster data transfer when a GMS version for Linux was used on SLES10 server. Those tests were based upon a scenario when a test PO with a mailbox filled in by several larger mails was synchronized one-by-one by two GMS servers running on Windows 2003 server and SLES10.
Due to better performance of a GMS running on SLES10, there are also no performance decrease problems on a GroupWise server.
This improved performance on Linux is due to a newer technology implemented in a Linux GMS code. The Linux version of GMS streams attachments via the HTTP protocol instead of via the SOAP. According to Nokia information, this newer technology will be also implemented in a next GMS version for Windows.