Time travel and factors that increase client startup or login time
This entry is written concerning the following issue; How applications and services can add to the startup or login time of clients.
The basics first; On any operating system, performing any operation takes time. This is just a fact of life and is more related to the nature of time than a question of performance.
Exactly how much time the operation takes is on the other hand a performance question.
The question and complaint commonly put forth by the end-user to the support engineer is as follows;
"My computer has gotten slow, why?"
The important bit here is not which operating system you're performing the operation on, it is how much time you expect the operation to take vs. how much time it is actually taking.
If there is a large gap between your expectations and the actual performance, chances are your expectations need to be adjusted or else you'll need to take a closer look at the operation and what it is actually doing.
This is why it is important in any sort of performance measuring to establish a baseline; both because you want to know how the system is expected to perform under conditions which you have full control over and because otherwise you can’t say with any degree of certainty that the system performance is better or worse than at any given date in the past.
Consider the following: Operating System X (No, not OS X….we’re still talking Windows) takes Y seconds to start up after the BIOS POST tests have completed and Z seconds to log user Q onto the system so that Q can start working. There is in addition an unknown time period between Y and Z where the CTR+ALT+DEL prompt is sitting on the screen waiting for the user to press said keys and enter their credentials, but this is irrelevant to the calculation of the expected startup+login time.
The total amount of time it takes for the OS to get from the point where the user has control of the workstation is Y+Z. If Fast Logon Optimization is turned on, Y and Z may actually be being performed at the same time in which case you will not be able to calculate the total startup+login time so for simplicity's sake we're assuming it is turned off.
Expected total startup+login time will be Y+Z.
Several applications, drivers and services are then installed onto the machine and configured in such a way as to start Automatically (for the services) and applications are configured to start automatically at user logon (through the Run registry key, Startup folder or otherwise).
- The Services and drivers will add time to Y (Startup time), we’ll call this Y1, Y2, etc.
- The Applications will add time to Z (Login time) , we’ll call this Z1, Z2, etc.
Startup time will be Y+Y1+Y2, etc.
Login time will be Z+Z1+Z2, etc.
Expected total startup+login time will be Y+Y1+Z+Z1.
Once you have a baseline; you can start determining how much time each service or startup application is adding to the startup or login phase.
In a perfect world, all applications or services would came with a label that says 'You can expect this service to add X seconds to the startup time of the machine' and this would have been tested by the application developers on one of your baseline systems.
For in-house applications this could easily be accomplished as you have relative control over both ends of the operation and can require the application to be tested on a baseline system that you have established earlier.
This would also provide internal quality control as you then also have a baseline to compare with and an application performance history and can start asking questions like ‘Why did the startup time suddenly increase when we went from Application version 1.0 to 1.1?”
For external applications, you have few options other than to do the tests yourself and then vote with your wallet depending on the results. There are just too many variables (like different hardware) to be able to generalize for an application unless you’re looking at a specific baseline system.
In either case you should also do your own acceptance testing and consider rejecting applications that are adding themselves to the startup or login phase unless there is a clear need for them to do so.
Bottom line is that if an application or service designed for end-users is adding itself to the startup or login phase it *will* increase the startup and/or login time, there should be a clear and legitimate business justification for doing so. Additionally, both parties need to recognize that adding to the startup or login phase of a client *will* increase the startup or login time and that they have chosen to have longer startup or login times by doing so.
If the business justification for adding the application or service to the startup or login phase outweighs the additional time the users spend waiting for the system to log them on, then that is a business decision that the end-user need to be aware of.
Note that applications which claim to have a ‘Quick-launch’ feature or similar which ‘speeds up the application load time’ commonly place themselves into the login phase, what this does in reality is that it makes the user wait longer for the login to complete as the time that would otherwise be spent on waiting after the user opens the application is instead spent on waiting for the login to complete.
I.e. this doesn't magically speed up the application; it's just moving the wait from one place to another.
A quick test you can do to determine whether an application or service will increase startup or login time:
· Pick your favourite Boot Timer application and use it to create a baseline for the startup and login time of the client on a clean system
· Run Autoruns from Sysinternals on the baseline system before the application is installed, export to file.
· Run Autoruns again after the application is installed on the baseline system.
· Do a text comparison of the pre-install and post-install files.
- If there are differences between the files, examine what is being modified and why.
As a general guideline, to maintain acceptable startup or login time on clients;
- Avoid adding services that take more than a couple of seconds to start AND that are set to Automatic. Ask yourself if this is a service with a genuine need to be set to Automatic.
- Avoid putting applications into the Run, RunOnce or the Startup folder of the users
Ask yourself if there is a genuine need to start the application immediately at login.
- Avoid using applications or services that don’t consider the possibility of the workstation being disconnected from the network as part of login or startup. For a laptop this will be the rule rather than the exception