I’ve decided to occasionally look back on some of the weird and wonderful projects I have had over the last couple of years to remind myself of the journey I have taken.
Today I am writing about a project I created to fix a problem with a misbehaving version of our CRM software (to remain nameless).
Our workflow was interrupted by the slow and unresponsive ticketing system, there was no ETA for an update but work had to continue. In a little under a week I decided to write a small Visual C# application that would throttle the CRM process to allow the computer to do other work. We obviously only wanted this to happen when not working in the CRM software, so we had two distinct behaviors:
When CRM is not focused (idle)
- Set’s CPU affinity to core0. (does this once, multi-core machines only)
- Deprioritise CPU Threads. (sets priority to LOW, allowing other processes to use CPU)
- Throttles CPU usage. (when throttling is enabled)
- Monitors CRM to make sure is responsive. (when Throttling)
When CRM is focused
- Prioritize CPU threads.
- Monitor CRM to make sure responsive. (when Throttling)
When active, Thermostat would take average load down from 100% to ~38%.
Side effects of throttling
Throttling was done by using the standard Windows
SuspendThread() method in kernel32.dll. One of the side effects of throttling the process was that occasionally the application would become completely unresponsive.
To overcome this, a built in health monitor within the application would attempt to send several calls to
ResumeThread() to try bring it online. To keep the user informed of the changes to the state of the CRM system, Thermostat would notify the user via a Balloon Tip.
Recovered CRM process:
Dead CRM Process: