|
|
|
|
|
|
|
SERVER PERFORMANCE
hen
computers break, I am always surprised how often the obvious cause is ignored.
I used to work for a small software consulting company whose main product
is a suite of tools for trading emerging market assets.
One of the suite's components is a server application. It listens for messages from client applications, responds by recalculating a collection of statistics, and then informs the client applications to refresh their displays. This may seem complex, but it is actually quite simple. So, I was surprised when a client complained that the server was "slowing down."
The software was running six other clients, and none had reported any similar behavior, so I told the client it must be a hardware configuration issue. The client "educated" me on why this was not the case. All systems undergo rigorous compliance testing. I reluctantly agreed; of all our clients, this one had the most sophisticated and competent IT staff.
The logs showed that at midnight the server was automatically shutting down and rebooting. A minute later the server came alive and began performing the necessary daily update to prepare for the new day of trading. Around 4 a.m. the system began responding to activities initiated by the few traders in London. It was only when the main office opened that the server started to exhibit problems.
When client applications began making requests, the server was swamped within minutes. Later, benchmarking revealed that the server was performing at half its normal speed. When we re-booted the server, performance returned to normal, but only temporarily. Three or four hours later, the system again inexplicably slowed down.
If it was not a hardware configuration issue, what could it be? A memory leak, network issue, or backup software conflict? Every possibility was explored but brought us no closer to an answer. Frustrated, we developed a workaround. Programs quantitatively tracked the server's performance, and if it fell below a certain threshold, the server could be rebooted remotely.
I have since moved on to a new job and had all but forgotten about this problem. And then I received a call from a former co-worker who, chuckling, explained that all the client's computers are EnergyStar-compliant. This meant that without someone hitting the keyboard, the computer would go into energy-saving mode and cut power to the processor, causing the server to slow down. Merely changing a BIOS setting solved the problem. It was a hardware issue--my first instincts were correct.
Max Abramowitz is the software consultant and developer for Oliver, Wyman, & Company LLC in New York.
 |
|
|
|
|
|
|