Blog Entry

(View Disclaimer)

We reached another important milestone today by shipping Data Synchronizer Mobility Pack 1.2.

This Mobility Pack release offers new functionality, increased stability and performance, and resolution for customer-reported issues. Please note that since this release includes security updates, it is available to all GroupWise customers, regardless of maintenance status. For more information on these security updates, please consult the available TIDs. Customers can download Novell Data Synchronizer Mobility Pack 1.2 from Patchfinder or the Novell Customer Center.

Specific product enhancements include the following:

• Increased Number of Supported Users: A single Synchronizer server can now support as many as 500 users/devices. I will talk more about this below.
• HTML Support: E-mail items that display in HTML format in GroupWise now display in HTML format on Apple iOS mobile devices.
• Reply/Forward Icons: If you reply to or forward an item on your mobile device, the typical Reply or Forward icon now displays when you view the item in a GroupWise client.
• Plug-in for the Novell Technical Services supportconfig Utility: The Mobility Pack now includes a plug-in for the Novell Technical Services supportconfig tool, which gathers system information for analysis and troubleshooting your Synchronizer system.
• Performance and Stability Improvements: Synchronization occurs more rapidly and consistently.
• Improved Browser Support Synchronizer Web Admin now displays correctly in Internet Explorer 8 and 9 without enabling Compatibility View. Firefox 4 is fully supported.

For additional details on enhancements and resolved issues, you can access the product readme. For a list of the bugs that have been fixed since Mobility Pack 1.1, see Section 8.0, Mobility Pack 1.2 Bug Fixes in the product documentation.

Scalability
As mentioned, we did focus on scalability with this release, and we feel that we have been moving the bar since the initial release last year. We initially recommended 150 users per server, because we had seen issues with initial sync internally. At that point we were running about 220 users on our own server but felt more comfortable with a slightly lower recommendation. With this release we feel comfortable recommending 500 users or devices per server, based on the results we are seeing from our superlab testing.

Regular System
We tested this on a 2 Core 2.2Ghz system, with 4Gb of RAM. In order to better scale the system there are some tweaks that you will have to implement. NOTE: These recommendations are a departure from what we have listed in the documentation - what we have documented is where we are comfortable, given the testing we have done and as far as we can scale internally.

In /var/lib/pgsql/data/postgresql.conf:

• set log_temp_files = 0
• set max_fsm_pages increased to 409600
• set shared_buffers to 256MB instead of 32MB

After making the above postgres configuration changes, you will need to restart postgres. To do that you will need to stop datasync (rcdatasync stop), restart postgres (rcpostgresql restart) and then start datasync again (rcdatasync start).

With this configuration we recommend maximum Users/Devices of 500.

Larger Systems
In our Superlab testing we were scaling way beyond this 500 number, however, this was with demo data and not real world usage. We are actually looking for customers who would be willing to push some limits on their Mobility Pack systems and give us feedback. If you have need to support more than 500 mobile users and/or devices then please let me know. This is what we believe are requirements to scale beyond the 500 mentioned.

Hardware Recommendations:
System Tested:8 Core 2.66Ghz, 8G Ram

Essentially we are finding the Mobility Pack is more CPU bound than anything else, and so really benefits from having additional (and faster) processors. The 8Gb of RAM is what was working for us, though we never consumed anywhere near that when running over 1000 users in the superlab.

Software Recommendations:

# Update the Sync Engine xml:
    * <redeliveryInterval>3480</redeliveryInterval>
    * <workerThreads>16</workerThreads> 

	

The syncengine xml changes <redeliveryInterval>3480</redeliveryInterval> and <workerThreads>16</workerThreads> need to be placed in the <settings> section of the syncengine .xml file. You can add it right below the </log> tag and above the <cacheRetention>0</cacheRetention> setting.

# Update the mobility device threads to 30.
    * <threads>30</threads> 

	

The mobility connector setting <threads>30</threads> needs to be added in the <custom> section of the mobility connector xml file. You can put it right after the <custom> tag on a new line.

# Update the GroupWise Connector threads.
    * <numWorkers>8</numWorkers> 

	

The groupwise connector setting <numWorkers>8</numWorkers> is already in the groupwise connector xml, but the default is 4, so you just need to find the tag in the <custom> section and change the 4 to an 8.

Add "ulimit -n 4096" to /opt/novell/datasync/syncengine/sbin/datasync-connectors right before the line that reads "if [ -f $appBinDir/$appScript ]; then" so it looks like this:

ulimit -n 4096 
if [ -f $appBinDir/$appScript ]; then

# Update the postgresql.conf
    * set log_temp_files = 0 (so you know if you need to adjust work_mem)
    * max_fsm_pages increased to 819200 (based on WARNING message in logs)
    * shared_buffers to 512MB instead of 32MB (based on memory)
    * work_mem increased from 1MB to 10MB based on log messages
	

After making the above postgres configuration changes, you will need to restart postgres. To do that you will need to stop datasync (rcdatasync stop), restart postgres (rcpostgresql restart) and then start datasync again (rcdatasync start).

With these settings we believe you may be able to scale as high as 1000 with all other options left as default. If you start to change configuration options, like maximum attachment size, or the length of time to keep items, you will see the maximum number of users or devices that you can support decrease.

Again, the settings we have in the documentation are what we are officially stating as supported, but if you need to scale beyond those recommendations then we want to support you to do so. Let us know and we can work with you.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.