More Information More InformationPriorities and their purpose are often poorly understood. Usually the misapprehension exists that if a process is taking a long time to complete then, if anything, its priority should be increased with the intent to make it finish faster. In most cases the CPU is spending near to all of its time executing the process anyway, so increasing the priority is only going to tell the scheduler to do what it is already doing.
It may seem paradox but it is in fact more sensible to reduce the priority of the busy process so that the system is prepared to let other processes have some time thus allowing them to remain functional. In most cases other processes will not be using a significant amount of the CPU's time and allowing them to execute when they want to will not slow the busy process by any notable amount. Computer applications simply have to be idle practically all of the time in order for them to react quickly when the user interacts with them. Therefore, allowing a well behaved application to continue to respond in such a way will not take a significant amount of time away from the busy process.
Even if reducing the priority of the busy process would cause it to run marginally longer, the subjective user experience remains unchanged. As soon as people have to wait for more than a few seconds, it makes little difference to the perceived interruption if it takes a little longer or not. However if the user, or even worse, other users wish to do other things on the same system, the overall perception of system performance drastically worsens if everything seems to freeze up.
ProcessGovernor has been designed considering the reliability and dependability of the system. It enables the operating system to help itself by optimally using the existing process priorities, which has long since been an integral and well established aspect of Windows. It therefore differs from solutions, which intervene and perform risky operations within the operating system.
Terminal servers allow for the installation of thin clients with little or no customization and administration. Instead the clients connect to one server with enough horsepower to serve several users. ProcessGovernor is essential on such multi-user systems since a process belonging to a single user can exploit the CPU's time to the point where the other users cannot continue working effectively. The operation need not be anything particularly hostile - it could merely be a print job or a webbrowser displaying a page with a poorly designed animation, for example. The correct use of ProcessGovernor on a terminal server can allow more users to work on one server without them severely interfering with each other's work. This improves its efficiency meaning fewer terminal servers are required and reduces the cost of installing and administering further servers.
The CPU usage that ProcessGovernor detects is relative to one processor. Therefore if a process would completely utilize both processors on a dual processor system, the usage would be 200%. However, in many cases a process is not able to fully utilize all of the processors unless it has been written in a way as to split long operations up into multiple threads of execution. Therefore most processes will continue to produce a maximum of 100% CPU usage. Basically some experimentation may be required on such systems to tune the rules set up for controlling the processes.
As much as I would like ProcessGovernor to be the answer for all computer problems, sadly it is not. Technically speaking, ProcessGovernor helps when two or more processes are competing for CPU time. However users may experience non-responsiveness for other reasons.
At the time when I wrote ProcessGovernor, I was working for Symplasson Informationstechnik GmbH in Germany and was with writing software in C++, which took quite some time to compile. It was practically impossible to use my computer for doing anything during these long compile operations, until I realized that all I needed to do was to reduce the compiler's priority in the task manager. The compilation didn't take any longer and I was able to use my computer as if it were doing nothing else. From that point on I wondered why Microsoft hadn't thought of doing that automatically when they wrote the compiler. I also wondered why nobody had thought of that and why Windows was not able to provide automatic assistance for managing busy tasks.
At the time Symplasson was introducing their application service provider (ASP) services and on one occasion when some of our software was deployed on a terminal server, a problem caused the application to comsume 100% of the CPU resources. Consequently all other users could hardly use the system and I realized it would have been helpful if the priority of the application could have been reduced in the same way that I was always manually reducing the priority of my C++ compiler. However some means of doing this automatically was needed and thus the idea for ProcessGovernor was born. ProcessGovernor then became a valuable asset and part of Symplasson's formula setting their ASP services ahead of their competitors.
While working for Symplasson, it was convenient for me to let them sell it. However I have since left Germany and moved back to my home in New Zealand. To meet the continued demand for ProcessGovernor, I have decided to release a new version and continue selling it.
If you have any questions, I can be contacted with this feedback form.
Copyright 2009 Peter Ball