Network Computingwww.networkcomputing.com

I tested a beta copy of WebSniffer in Network Computing's Syracuse University Real-World Lab® and was intrigued by its in-depth analysis. The product consists of two parts: an agent that runs on the same machine as your Web server and a repository that stores and analyzes the data from the agent. You can view the analysis via a Java client. I loaded the agent and repository on the same Unix server, which was also running a Web server. Version 1.0 will support only SunSoft Solaris; support for Windows NT is expected later this year.

Although WebSniffer provides real-time analysis of Web-server, host-machine and local-network performance, it is designed so that the Web administrator doesn't need to watch--or understand--these metrics. Instead, WebSniffer provides alarms and analysis as problems arise. You can view the alarms via the client, your e-mail or pager. The analysis explains the problem in simple terms, and it suggests a solution or tells the administrator what other factors to inspect.

Warning: This Is Only a Test Because WebSniffer is designed to detect errors and suggest solutions, I created a few problems for our server (a SPARC10 with 128 MB of RAM running Solaris 2.6). With our server running smoothly, I rapidly began gobbling up memory. (Incidentally, it's amazing how much memory six copies of Netscape Communications Corp.'s Communicator can consume.) Just as I expected, the server slowed as I used more and more memory.

In response to this test, WebSniffer quickly produced an alarm, warning me of a host memory shortage. Looking at a graph that WebSniffer provided to show how much memory I needed, I saw that the system was using the entire 128 MB of physical RAM. The graph showed that with an additional 40 MB, the system would be in better shape.

Next, I flooded our server with requests for invalid URLs, which set off several alarms. First I received an alarm that the URL availability was too low. I also received an error indicating too many errors on the network. It warned that either a host was spewing bad packets, or the network was overloaded. Because the network was overloaded with my requests, this was an appropriate response.

The third error was the most interesting: The CPU was overloaded because the run queue was too long and the load average too high. WebSniffer advised me to check the CPU time graph, which depicts the percentage of time that the CPU spends in various states (user, system, wait, idle). It suggested that if the CPU spends too much time in the waiting mode, the system is most likely I/O-bound, waiting for data from the network. WebSniffer's diagnosis was right on target--I had overloaded the network with bad requests.

I appreciated that this information was easily available via the Java client. In the lab, it was easy to use and performed its tasks efficiently.

David Daly is a network administrator at Syracuse University. He can be reached at ddaly@syr.edu.