In this day and age, real-time mobility is crucial to drive end-user productivity. Users need instantaneous access to their email, calendar, and address book. IBM Traveler provides just that, enabling a wide range of mobile devices to securely synchronize critical data over-the-air for quick access.
As any business-critical application, Traveler requires comprehensive monitoring to guarantee uptimes and ensure high quality of service delivered to the end-user. Traveler is a very stable platform –it is widely considered “always on” and indeed almost never goes down – but this can interestingly work against you, as it’s difficult to discern when the quality of service declines. In fact, you often only become aware of an issue when end-users report problems with the service. And of course, such problems tend to arise at the worst possible moments – for instance, right as your CEO is about to walk into a pivotal meeting.
Thus, it is critical that your Traveler infrastructure is appropriately sized and especially well configured to provide the best possible quality of service. A good way to achieve this is to have a better understanding of how Traveler’s constraint processing feature works.
Traveler constraint processing is proactive code that monitors the system to see if it has entered a resource constraint state. This happens when the system memory or database connections exceed a given threshold. Once this is detected, Traveler won’t allow any new device sync or prime sync threads to initiate; they will be denied with a 503 status code. This is usually when your CEO calls…
Constraint processing can most of the time be prevented through proper fine-tuning of your servers configuration. The underlying Domino can be configured to provide more resources to Traveler, in most cases using the existing hardware. This allows to take full advantage of your existing infrastructure while providing better quality of service. However, if fine-tuning is not sufficient, action must be taken at the infrastructure level. You can add more resources to the existing hardware (more CPU, RAM, etc.) or add new Traveler servers to the existing HA Pool. The trick is to be fully aware of the situation to be able to take the appropriate action.
So, in short, your options to maintain high quality of service and minimize mobility services downtime are: 1. throw quite a bit of un-optimized money at the problem by oversizing your Traveler infrastructure; or 2. automate Traveler resources availability monitoring to be able to optimize resource and infrastructure utilization.
GSX Monitor and Analyzer allows to monitor key Traveler metrics in real-time, enabling you to avoid issues and downtime with your mobility services, maintaining a high quality of service. By automatically detecting Traveler resource constraints and problems related to synchronization, GSX Monitor and Analyzer helps optimizing usage of the existing infrastructure, thereby also optimizing costs. You can keep tabs on HTTP CPU Usage, HTTP thread allocation, and outdated device synchronizations – including the number of successful and unsuccessful syncs on all devices in the organization.
With GSX Monitor and Analyzer, you’ll be alerted of potential issues before they impact users through pre-defined performance indicators and usage thresholds. You’ll find you have better control over service quality, delivery, and in ensuring mobile business continuity to the end-users. By optimizing usage of the existing infrastructure and optimizing the end-user experience, you’ll lower overall IT costs whilst redefining the meaning of “always on”.