In my last entry, we made some changes to X-Link to decrease CPU usage during the non-data transfer functions. This intial change had a significant impact on CPU usage - approximately 50% overall reduction - quite amazing. However, we also found there are still areas of higher CPU usage that we may be able to decrease. This entry discusses a possible 2nd set of changes to the engines to improve CPU usage and the results.
Still looking for the CPU Usage Culprit?
All of the information found so far suggests that Enterprise edition uses a significant portion of CPU usage even after the 1st set of changes in Enterprise mode. After some deep investigations, we found the scheduling function for Enterprise, which was the same as used in a single engine environment, needed to be changed. It is due to the fact that running multiple engines is by it self a subsitiute for much of the scheduling functions used in the single engine X-Link. Since the multiengine scenario is different, the scheduling functions needed to be modified to be more efficient in the multiengine environment.
The changes made are all only in the Enterprise Edition. The Application and Service Edition scheduing function is highly reactive and works well in the single engine scenario. Enterprise editon had these following changes made:
- Change the 1 second/0.1 second cycle times to 3 seconds/0.3 seconds
- Change the Fast Linger from 10 cycles to 2 cycles
- Do not trigger Fast Linger for TCPip tasks
- Do not update flags during message processing, only update flags at the end of a full cycle.
These changes will slow the delivery of messages by approximate .9 to 1.5 seconds while significanntly decreasing the CPU load on the server for non-data transfer activities. The original load is 330 cycles per minute, while this new configuration should produce only 32 cycles per minute per engine for our test scenario. One might think the reduction should equal 90%, as the number of cycles is reduced by 90%; however, it will probably be closer to 80% as now each cycle will have more tasks to process. Here's what we got:
It appears that these four changes did cause a significant decrease in CPU usage as proposed. This change is very significant, reducing CPU usage a lot. A very impressive change, so impressive that it has been incorporated into Version 20.03 of X-Link Enterprise Edition (pending release).
Let's Get Analytical
It's somewhat hard to tell exactly how much improvement these changes have made with the graphs presented so far. Let's compare the 3 scenarios to get a better view of what was done and how dramatic the results were. We'll remove the Data Transfers and DoEvents from the graph, and only look at the remaining 4 segments that constitute the non-data transfer CPU usage:
The Data Transfer and DoEvents were the layers between the two sets of purple/green layers above. The colors are the same as with the other graphs. The first scenario on the left was before any changes were made and the total CPU usage for non-data transfers was 0.491%. After the first change, that usage decreased to 0.094%, a 80% reduction (which netted in a 50% overall reduction). Then with the second change, the usage decreased to 0.019%, another 80% reduction. Both of these changes together net a total reduction of 96% between the original and the final versions. This is simply amazing and rather unexpected. But I do want to say I'm glad I built the X-Link to be easily modifiable for concerns like this one.
This concludes this set of blog entries on CPU usage. We hope this type of information on what and how we assess our software and make changes helps you understand our commitment to our customers.