Stress test Sun Fire T2000

Compiling of the sniper went smoothly on the Sun. Luckily, I use the same gcc version under Debian as under Solaris now. The compiling went really very quickly and my subjective assessment, in comparison with our dual processor HP Proliant DL 360, is that the T2000 compiles the code only a bit faster. Granted, the code only compiles for a few seconds and therefore doesn’t offer much leeway for speed measurements. In comparison: my Apple iBook also compiles the code only a bit slower than the much faster HP Proliant. Judging from that, one can’t lend these benchmarks too much weight.
I configured the actual stress test in which the T2000 had to prove itself as follows. Because the sniper was not in the productive range under Solaris, the HP Proliant server acted as if it were eBay.com, which in turn attempted to receive the sniper’s inquiries as quickly as possible. In order to have a comparative reference, the HP Proliant did the same with the T2000 as the sparring partner. The initial situation was nearly identical on both servers: A freshly installed Solaris on the T2000 and a freshly installed Debian Sarge on the HP Proliant. I fed both mySQL databases with test data for exactly two hours, continuous commands that rattled on the sparring partners. The commands increased linearly in frequency for an elapsed period of time and peaked at six times the load our current server is subjected to on a Sunday evening at 8:30pm (Primetime on eBay). This means that up to 1200 threads were open simultaneously in the end, all of which occupied memory and processing time.
In order to have a comparison of the performance, I tested the response time of the mySQL database on both systems with a simple script. For the sake of simplicity, I made the inquiries from my iBook instead of directly on both systems.

To build some anticipation, I should probably start with the results of the HP Proliant, which already exhibited large performance problems at approx. 600 threads, and consequently with at least 600 open connections to the mySQL database. At this time, it was subjected to somewhat more than half of the maximum load in the stress test. At 800 threads, the system only responded very sluggishly and the mySQL database only returned timeouts, which in turn resulted in killed threads. When the system hardly responded to input at all, I needed a minute before I could deactivate the database via SSH with /etc/init.d/mysql stop.

The stress test, then, seemed to exhaust the limits of the HP Proliant optimally. The T2000 in absolutely no way mimicked the behavior of its »colleague in silicon«. The first sign that the T2000 was even doing anything showed up shortly before the spot where its competition was nearly wrecked. Thereafter, the load increased speedily on it as well, measured by the connection times. A nearly full utilization of capacity, revealing its limits, did not show itself during the test.

Conclusion: After the test, it was clear to me what a performance monster the T2000 is. I would not accuse the HP Proliant of being disgraced, as it surely would have held out somewhat longer with the same amount of RAM as in the T2000.