Continuing on my recent theme of security pain points, I'm finding that many companies suffer horrible log-on delays because of their computer security defenses. I'm not talking about a minor inconvenience. I'm documenting 8- to 10-minute boot-ups and log-ons versus 1.5 minutes without the host-based firewall or anti-virus software that's getting in the way. It doesn't matter which operating system the end-user is running. The problem affects both Windows and Linux/BSD machines -- mostly during log-on, but often again when the user starts a browser session or an e-mail program.
I think we all rightfully expect a performance trade-off when running PC-based computer security defenses. But I'm seeing cases where popular security products are causing absolutely unacceptable delays. Even worse, administrators and users alike are accepting the poor performance as a necessary cost of doing business with computers.
[ Whose endpoint security products stay out of your way? See the InfoWorld Test Center's endpoint security shoot-out. ]
They shouldn't give in. It's common and expected to trade some level of performance for greater security. But extremely bad performance shouldn't be the cost of implementing a computer security product. So what can you do about it?
First, get a baseline to measure against before starting to troubleshoot. Using a stopwatch or watch that increments by the second, measure the time it takes the computer to go from a cold boot to a fully usable desktop. "Usable" means the user can begin operating programs without significant delay. CPU utilization should be sustained under 5 percent. Further, I normally break the boot-up process into two phases: from cold boot until the user is prompted for their log-on credentials, and from the time the user successfully enters their log-on credentials until a usable desktop. If possible, configure the computer to automatically log on the user to prevent mistyped credentials from distorting your time measurements. Restart from a cold boot at least three times or until you have a fairly consistent boot-up time, differing by maybe 5 or 10 seconds.
If the boot-up time is horribly long, try temporarily disabling your host-based firewall or anti-virus product, then redo the boot timing tests. In some of the worst cases, I've found various popular firewall or anti-virus products to be responsible for the most significant parts of the delay. I've seen host-based firewalls slow network packet performance by a factor of 6 or even 10. Sometimes it's just the first packet to any new host that is delayed, but this is enough to cause local resources to respond too slowly, prompting even slower remote or backup resources to serve the request.