Performance

The test application involves a number of SELECT and UPDATE statements, including INNER JOIN and LIKE sub-clauses.  INNER JOIN sub-clauses are relatively expensive as they involve joining tables together based on relational fields.  LIKE clauses are also expensive in that they involve a fuzzy (non-absolute) comparison of strings to find records which are similar.

The test duration was 3 minutes and was run over a 100-BaseT network.  We used 25, 225, and 625 simultaneous connections as the basis for the test.  625 and 225 simultaneous connections are very large numbers, and actually caused the test router to fail in the real server tests.  Unfortunately, given the deadline of this article a higher-performance router was unavailable.  However, with the results we did find it appears that higher-concurrency data will not be important.

The data we did acquire, however, paints an interesting picture:

Test System	Connections (Concurrent)	Requests Per Second	Throughput (Total Requests)
Virtual Server	25	17.69	3209
Virtual Server	225	45.29	8152
Virtual Server	625	60.89	10900
Real Server	25	89.23	16062
Real Server	225	*	*
Real Server	625	*	*

Looking at this data it appears that there is a pretty heavy overhead in Virtual Server, despite the fact that the virtual server was connected directly to the hardware network adapter (not a virtual network).

Performance Comparison 

Here we see the real server beating the virtual server by a factor of more than 5.0.  Also, during the tests, the virtual server frequently became backlogged so that it took many seconds (in the case of 625 connections, more than 15 seconds) to respond.  It is clear that Virtual Server brings with it a hefty performance price.  However, 17 requests per second is still acceptable and, in fact, represents a very heavy load by small and medium business server standards.