With servers, this kind of thinking will always lead to trouble because of computing rule No. 1: All computers eventually will seem slow. Servers are no exception. The server that today has more CPU power and disk speed than you can use will be as slow as an old dog tomorrow.
The good news is that with the right tools, you can prolong any server’s life. The first step, of course, is to find out just what the server is doing and exactly where it is too slow.
For that, you’ll need a good performance monitor. In fact, you’ll probably need a whole set of performance monitors, because in the client/server world, the “server” most users see is actually a combination of hardware and both operating system and application software.
The bad news is that we need a much broader and more powerful set of performance monitors than are currently available. What’s out there today only scratches the surface of the total information picture we’d like to see.
The lowest levels of a server, the baseline hardware performance, are in many ways the easiest to check. The main data you need is fairly straightforward: CPU, RAM and disk consumption, network-interface card activity level, and so on.
Not as easy as it seems
Even that data, however, can be tough to get in a complex server loaded with multiple processors, multiple disk controllers and lots of disk drives. In such a system, for example, it’s not enough to know that your disk subsystem is the bottleneck. You also need to know which controllers and/or drives are the problem.
Stepping up a level, you also need to know just how well the operating system is performing. Relevant information ranges from simple things, such as the number of users currently active, to more complex data, such as the percentage of the disk buffers that stay dirty over time.
While in the world of PC-based servers neither of these types of performance-monitoring technologies is where we’d like it to be, vendors at least seem to be working on the issues.
The big hole in PC-based server-performance monitoring is in the server applications. When your E-mail server is slow, what’s happening? Just what is that database server doing, anyway? Worse, what interaction between those two is causing both to crawl?
Server applications need their own performance monitors, which should allow high-level overviews right down to the hardware. You should be able, for example, to start with a generic problem: slow query response time. With the database server’s performance monitor, you discover that 90 percent of your queries are going against one table.
Look deeper. Three-quarters of that 90 percent are using the same index. Look even deeper. That index and the table into which the index leads the queries are on the same (slow) disk drive.
Move the index and the table to separate, faster drives, and your performance will improve.
To make even such relatively simple performance examinations possible, the server application monitors must know how to work with the underlying operating system and hardware monitors. Each level of performance monitor should provide a consistent interface to all the higher levels that want to use it. Without such interfaces, you’ll end up dashing from monitor to monitor, trying to relate the problems displayed on one screen to the bottlenecks shown on another.
The basic technology to provide this level of integration isn’t very hard, but it does require that a lot of different vendors work together and that standards emerge for all the key platforms. Those vendors that put in the effort to create such standards and tools that use them eventually will be rewarded with sales for their willingness to plan for the inevitable rough times.