We measured performance information to see the differences between Windows and Linux platforms. The test done against the Windows server gave users marginally shorter wait-times by electing to turn some traffic away. The Linux server, however, scaled to serving a greater number of users with reasonable responsiveness before its maximum capacity was reached.

In Part 1 of this article, we examined the relative performance differences, noting the behavioral differences as the servers approached capacity. This limitation was easily remedied by increasing the memory available to Tomcat. Here we'll present the behavior of the servers after this change was made to their configuration.

Our guidelines and testing procedures remained the same, except where noted.

Testing Procedure
The testing tool managed the test case recording, virtual user simulation, and data gathering. The testing tool used was Web Performance Trainer 2.8, Build 629.

Servlet Container Preparation
Tomcat was installed following the procedure described in the first part of this article. The only difference was to increase the JVM memory limits. Since each server was equipped with 512MB of RAM, the new memory configuration setting was arbitrarily 200MB initially, with a maximum of up to 384MB. In the Windows server, the settings were entered directly into the configuration manager applet installed with Tomcat. In the Linux server, the same effect was achieved by specifying the JVM parameters in the CATALINA_OPTS variable.

Results
Throughput
Our first measurement of interest was roughly how much through-put the server could sustain under an increasing load. This measurement was taken from the total megabytes of HTTP traffic and didn't consider lower-level implementation overhead.

The test was terminated after 100 minutes after a plateau made it evident that the server couldn't improve its responsiveness to further users. Since our load was distributed from multiple engines connected to a 1GbE switch, the throughput of both servers was well below the total Ethernet bandwidth of our test lab and can be ruled out as a significant limiting factor in these results.

The leveling of the throughput indicates that the server had reached its absolute capacity to serve data and couldn't scale any further. The maximum throughput measured was approximately 8.8MB/s on the Windows server compared to 12MB/s on the Linux server. It was evident that the Linux server could scale to meet the needs of many more users than the Windows server (see Figure 1).

CPU Utilization
CPU Utilization gives some insight on how well the server could cope with the increasing load. Each server in the test was equipped with a single physical CPU with the HT Technology enabled. This graph is then an average of the processor load of the two virtual CPUs (see Figure 2).

We see here that the Windows server started out consuming more CPU time earlier in the test. As more users are added, performance eventually becomes processor-bound and the server was too computationally overwhelmed to continue to accept users. The Linux server too was fated to produce the results, but lasted longer before the CPU time was completely exhausted.

Errors per Second
During the tests the only errors that propagated their way to the virtual user were transmission errors that occurred when a user would try to open a connection to the server. To the end user this meant that his web browser would display an error message usually something similar to "Connection refused by server." Every page returned during the test was a complete page, not an error page from the server.

We noticed that the Windows server tended to refuse connections instead of trying to service them. The Linux server wasn't completely without error, but rarely exceeded a consistent rate of over one error a second, enough to account for over 180 errors logged after our 100-minute test. However, this number is still negligible considering the Windows server was turning away more traffic per second than the Linux server turned away during the entire test (see Figure 3).

Hits per Second
The next step was to examine how responsive the servers were under an increasing load. We measured the number of responses per second of HTTP traffic. We anticipated that under an increasing amount of traffic, we would see an increasing number of completed responses from the server.

We produced this graph by examining the servers' throughput (see Figure 4).

One can see that once again the two servers maintained a relatively even and competitive pace with each other until the Windows server began to slow down under an increasing load at approximately 1,200 users and leveled out at a capacity of around 1,300 users. The Linux server also leveled out as the user count continued to rise but only after it scaled to nearly 1,800 users. The increase in user capacity let the Linux server serve at slightly over 1,800 hits per second compared to the 1,400 hits per second reached by the Windows server.

Duration
In the last phase of this category, we concerned ourselves with how long a user has to set aside to complete his task. We measured the full time until we got a response from the server, waiting until it arrived before moving onto the next page of the test.

For the duration times of a business case, the baseline for each graph is defined as the amount of time the user spends "interacting" with the page before moving on to the next page. The simulated time the user spent on the last page was omitted (see Figure 5).

The duration graphs show the full range of measured durations during a given interval (dark background), with the averages on top (highlighted points).

Complete Scenario Durations
We started by examining the amount of time the user spent working his way through the entire test case up to the response of the last transaction from the server. Note that each column shows a series of graphs occurring roughly concurrently. Hence, the number of users for each graph is measured for the number of users in a specific case and not the total hitting the entire server (refer to User Distribution in Part 1 of this article if necessary)(see Figure 6).

In each figure, we trimmed off the extreme outlying maximum durations. These outliers were measured as high as 10 minutes in the long scenario, seven minutes in the medium scenario, and 100 seconds in the short scenario.

However, a general trend seemed to emerge: the longer scenarios with more pages are more likely to get stuck on a resource that didn't get a prompt response and will see a greater increase in average duration. Overall, the Windows server maintained a somewhat even average duration under load, though this number appears to jitter more under increasing load. The Linux server showed a gradually increasing average duration under load once the server's capacity was reached. Both servers showed that the potential maximum duration grows with the amount of load on the server.

Static & Dynamic Content
Evidently for the entire duration of the test the average request for any given URL used was followed by a practically instantaneous response from the server. Our maximum durations were more pronounced than those for our static URLs during lower user counts, but this was only because there were significantly more static URLs in each test to potentially return with a maximum duration. However, we noticed that the maximum duration for URLs had a greater tendency to increase on the Linux server under high load. Presumably, since our average durations were returned at a quick rate, the perceived long durations for each test was the consequence of users getting "stuck" on a resource that was delayed to the maximum duration.

Capacity
When we discussed error counts, we mentioned that the only errors were purely transmission errors with the server. However, with the delays we saw, we needed to impose some restrictions so the server would respond in a reasonable amount of time. With this in mind, we used the Web Performance Trainer to see the server's total capacity and focus on how much load could be handled when at least 95% of the users had a total page duration of six seconds or less, with no more than 5% of the responses indicating errors. This value appeared somewhat smaller than we might expect from looking at the scalability of the server. Despite an increasing throughput from the server under higher load, an increasing percentage of users were likely to hit significant delays or connection failures as the load increased. Hence, we can use this analysis to evaluate the realistic capacity of the servers, given the parameters we have provided above (see Figures 7 and 8).

Analysis
We gave Tomcat the opportunity to compete when installed on two different platforms. We saw that the average duration of each URL, even under extensive load, remained relatively instantaneous on both servers. However, the Linux server slowly had an increasing number of URLs that didn't get serviced quickly and delays service for longer periods of time than the Windows server when forced under load. In contrast, the Windows server showed somewhat shorter durations per URL by turning away traffic that it couldn't handle. Despite this quick but incomplete response on some resources, many users found themselves waiting for another resource that wasn't serviced as promptly.

From an administrator's standpoint, the Linux server didn't tie up its CPU resources as early and was able to service many more connections overall, but some of those connections were consistently delayed, leaving users waiting on the other end. However, even given some normal delays, the Linux server was still able to serve more users than its Windows counterpart.