Engineering Corner: The Improved Stability of Windows RATL Server

Microsoft® Windows® RATL Socket is the primary interface server process used by most Agile Business Suite (AB Suite™) on Windows clients in production. Windows RATL Socket is mature, stable, and has demonstrated its ability to handle a large number of transactions.

The RATL protocol is a wrapping of a standardized and extended set of NO-Form (NOF) messages that provides all the functionality needed to support GUI forms in a deployed application. It is the primary interface protocol used for communication between the GUI clients, such as Component Enabler, and the deployed runtime application. RATL protocol is implemented separately on Windows and MCP platforms. This article focuses on the RATL protocol server, or “RATL Socket,” used in AB Suite on Windows deployments.

Recent Enhancements

In order to make RATL Socket even more robust and stable, enhancements have been made to reduce its memory footprint for some specific system settings, such as “Unicode.” These improvements are available in AB Suite Interim Correction levels 4.0.1026 and 5.0.1016 onwards. And, by default, these improvements will be part of AB Suite 6.1.

To demonstrate the impact of these changes, stress and load tests were conducted in the AB Suite engineering labs. RATL Socket was tested with a load of 50 million transactions using an automated NOF driver client program, which established a connection to RATL Socket and performed Ispec transactions in a loop 50 million times. This automated stress and load test took around a month to complete on our low-end machines.

For the entire duration of the testing period, RATL Socket was extremely stable in terms of both CPU and memory usage. During the test run, the maximum CPU usage consumed by RATL Socket hovered around 20 percent on our low-end machine. The memory consumption (Private Working Set) of RATL Socket averaged roughly 4 MB for both AB Suite 4.0 and 5.0 throughout the testing period.

Below are snapshots of RATL Socket’s process statistics (via the Task Manager) after processing roughly 90% of the transactions.

AB Suite 5.0:

AB Suite 4.0:

Lab Test Hardware Configuration
With AB Suite 4.0 and 5.0, the testing was done on virtual machines with the following configurations:

• Processor: 2x Intel® Xeon® CPU
• E5-4640 @ 2.40
• RAM: 2 GB
• Virtual Memory: 4 GB

Although production sites typically have high-end configurations, low-end machines were used for the tests to ensure that RATL Socket can handle large workloads on systems with minimal configurations. As our results show, RATL Socket seamlessly supported these transactions. The CPU and memory usage metrics obtained through Windows Performance Monitor indicate that RATL Socket was fully stable during the entire one-month testing period.

Monitoring RATL Socket

The important metrics to monitor center around CPU and memory usage – things like Private Bytes, Private Working Set, and the Commit Size values – of the RATL Socket process. You can check these details through any monitoring program or do so manually using the Task Manager. The Private Bytes and Private Working Set indicate the amount of memory that can’t be shared by other processes. The Commit Size indicates the amount of virtual memory reserved for use by a process.

In AB Suite 5.0, the AB Suite for Windows Runtime is 64-bit, as is RATL Socket. Therefore, this combination can handle higher volumes of process memory, so you should consider recycling RATL Socket once every few months. Conversely, as the AB Suite for Windows Runtime 4.0 and its RATL Socket are 32-bit, it is advisable to recycle RATL Socket at least once every month.

Running Multiple Copies of RATL Socket

An important aspect of RATL Socket is its ability to run multiple copies in parallel using different port numbers. So, typically, a single RATL Socket can handle all clients and all systems. However, in some very high-volume transaction environments, you could consider configuring more than one RATL Socket process to effectively spread the load and keep the process from getting overloaded.

AB Suite on Windows and RATL Socket Server: Ready for the Future

Today’s IT world has already started its transition from 32-bit to 64-bit computing. We have software systems that have already exhausted the 4 GB RAM limitation on 32-bit machines. But the theory of addressable memory permits you to use up to 16 exabytes – or 16.8 billion gigabytes – of RAM in a 64-bit machine.

The size of the computing device is shrinking day by day even as its computing capabilities expand exponentially. The day when we have a server with 16 exabytes of RAM to take advantage of full-fledged 64-bit computing is not too far away.

But here’s the good news: AB Suite and RATL Socket are already future-proof – and future-ready. The 64-bit AB Suite for Windows Runtime 5.0 software combined with the parallelism of Windows RATL Socket is already available and ready to take full advantage of the capabilities of tomorrow’s computing hardware.

All you need to do is update your environment to AB Suite 5.0. If you need help getting there, please reach out to us at ABSuite@unisys.com.