HostBridge recently conducted a customer benchmark on the CPU savings that result when switching from CICS Socket Support to HostBridge Socket Support (HBSS). The savings were substantial, reducing CPU consumption by at least 33% for this large banking client. This CPU savings in turn improved application response time as well.
These test results are significant. The annual Syncsort “State of the Mainframe” study for 2018 reveals that over 70% of study participants ranked reducing general processor CPU usage and related costs as a top priority. For organizations whose CICS applications perform socket I/O, HBSS provides a fast, easy way to reduce CPU consumption.
This particular client came to HostBridge looking for help in reducing CPU consumption. They also wanted to improve performance for CICS applications that run across 9 regions. Testing involved two customer-written programs that used the “Original COBOL Interface” for performing Socket I/O operations. This is the original (and oldest) API for COBOL programs to act as socket-oriented applications.
The customer-provided COBOL programs were very straight forward. This gave us the opportunity to compare the performance of the “Original COBOL API” with the “Extended API” as implemented by CICS Socket Support. To make this comparison, we cloned the COBOL programs and changed the form of all the socket API calls. Then, holding the API constant, we compared the performance difference between CICS Socket Support and HostBridge Socket Support (HBSS supports both APIs and performs identically regardless).
CICS Socket Support Benchmark Environment
The CICS COBOL programs were benchmarked by running them through a standardized test of 5,000 requests/responses for each of the following cases:
- COBOL programs using the Original COBOL API, with CICS Socket Support implementing the API functionality.
- COBOL programs using the Extended API, with CICS Socket Support implementing the API functionality.
- COBOL programs using the Extended API, with HostBridge Socket Support implementing the API functionality.
The test was run 12 separate times for each case. The results were averaged to determine the performance impact. A summary of the average CPU utilization for each case is shown in the table below.
When using CICS Socket Support, we always suspected that CPU consumption was higher using the Extended API than when using the Original COBOL API. These tests confirmed our suspicions. When using CICS Socket Support, using the Extended API resulted in a 12% increase in CPU. This CPU increase is solely due to the implementation of the API under the covers of CICS Socket Support.
The table that follows shows all test cases side-by side, highlighting our analysis.
Given that their programs currently use the Original COBOL API, we are confident that HBSS can reduce CPU consumption by at least 33% for the infrastructure components that handle socket communications. For customers whose existing applications use the Extended API, we are confident that HBSS can reduce CPU consumption by 40%. And, we make these assertions not just based on this particular benchmark, but on years of experience with similar CICS socket-based applications.
One of the customer-provided programs functioned as a simple, single-threaded listener program (not uncommon). However, in any real-world, high-volume environment, you should expect that such a listener program would constrain the total workload able to be processed. And, such a constraint often causes customers to spread their workload across more CICS regions than are really necessary. Thus, for a customer like this one, we would strongly encourage them to use the multi-threaded Listener included with HBSS. This will further improve throughput and allow them to maximize the processing power of each region – perhaps reducing the number of regions required.
If your CICS applications perform socket I/O, you should test HBSS to learn how much CPU reduction you can realize. Contact HostBridge using the form below: