In my last entry, we showed how portions of X-Link processing not during message transfers appears to use a large amount of CPU time. This entry shows the results of the 1st set of changes to the engines to improve CPU usage.
Did we Find the CPU Usage Culprit?
All of the information found so far suggests that some changes should be made in the Enterprise Edition to improve the way the engine utilizes resources, especially CPU. I made two changes to engine and reran the test environment. The two changes were the removal of the DoEvents command and the removal of the capturing and writing of message statistics - an item assumed to be the major culprit of CPU usage in the engines. Here's what we found:
It appears that these two removals did cause a significant decrease in CPU usage as proposed. This change is very significant, reducing CPU usage by approximately 50% overall. A very impressive change. All mainly due to the message statistic capturing and saving. This new graph also gives us a look into how much time the DoEvents command used. Turns out the DoEvents command did have a minimal usage impact as expected, and it comfirmed it's removal is a positive change.
This is a great reduction and has been incorporated into Version 20.01 of X-Link - All Editions. So let's take a closer look at these data transfers and CPU usage and see what else can be improved upon. Here's a zoomed-in view showing the 15 minute period of data transfers followed now by 20 minutes of no data transfers:
Not really different than expected. We still see data transfer time used to check the database for updated records is less than when data is found. The purple/green still seems a bit large, especially if you consider this is only one engine.
Let's Get Analytical
When we compared the timing for data transfers only between sending and not sending data, we found it took an additional 60% more CPU time when sending data verses not sending data. However, there was also an increase of 15% more CPU time when sending data verses not sending data while performing the scheduling and other non-data transfer functions. A typical message takes 4 cycles to transfer, so it makes sense the scheduling takes a bit longer. Again, nothing really dramatic, other than X-Link does take a lot of time deciding what to do next and this adds a load to the server in Enterprise mode.
In my next entry I will talk about what other changes can be made to X-Link in Enterprise mode to reduce it's CPU usage in a server environment while not degrading message delivery time.