.
In the database test, for example, we've divided the total execution time by the number of queries. As the graph shows, when the servers are fielding more than four queries, the time required to process each additional query is essentially a constant low value.
A similar situation occurs when the average time to
serve 100
URL requests is derived from the Web test data. As the number of URLs served increases, the start-up overhead of the test becomes less significant. The response to additional requests again becomes a proportionate increase in time.
Both Sun and SGI were at a loss to explain the extra 20 seconds or so that their servers took to handle each Web test compared to the other machines in the review. If you don't count this "start-up" time, the servers responded similarly to in
creasing load. In this case the SGI required only 3 seconds to handle each additional 700 URLs -- the least time of any machine in this review. For the same increase in load, the Sun required the longest additional working time: 4.17 seconds.
The bottom line is that these servers like to work hard. The more you load them up -- until you hit a bandwidth limit somewhere else in the system -- the more efficiently you use them.
illustration_link (10 Kbytes)
Once server begins to deliver a heavy load, its performance suffers little from start-up overhead.
illustration_link (12 Kbytes)
When all four processors are kept busy, the time to process additional queries is relatively constant.
Interpreting Performance
