Our tests were performed with a two server MOSS 2007 farm with the same databases running on a fairly robust (physical) SQL cluster. One server was an indexer only, and the other served the SSP, web front end, etc. No special Sharepoint caching was turned on for any sites. The physical servers tested were HP servers with 2GB RAM and two (older) 3.4 ghz dual core processors in each. The virtual servers ran with 2GB RAM and variously 2 or 4 processors on an ESX system that I believe had two dual quad core machines and LOTS of RAM.
Three categories of test were performed:
- Indexing performance
- Web page traffic
- Document library traffic/search queries
Results were monitored from various sources - HP OpenView, Loadrunner, WAPT, Windows native, and subjective.
Indexing virtual to virtual with 2 processor machines seemingly outperformed physical in all categories except CPU usage, which was significantly higher on the virtuals (though acceptable). The time to complete the index was almost the same for physical and virtual farms.
We did not have any HPOV data on the indexer.
2. Web Page Traffic
An older script was run with Loadrunner, simulating 250 users for 15 minutes. The script was web page views only. In general, the virtuals outperformed the physicals in these tests. Neither was overloaded.
3. Document Library - File and Search
A short script was created to download two large files (30 MB) repetitively and do some search queries. This is a realistic document library scenario of Intranet content being downloaded simultaneously by multiple users. The script was run with WAPT via several different PC's, with anywhere from 20 to 200 sessions simulated. The tests were run from the same part of the building and presumably through a small number of ports on the same network switch.
None of the systems performed this test well. Heavy file activity can be the bane of SharePoint's existence, even though we often use it as a document management system that is easy to use and access from any office. Large files are common, and access to such files usually cannot be managed (if it were managed, we could easily cache such files and more easily serve up large files to many users).
The physical servers were slow but remained responsive during this test. CPU utilization was usually below 50%, with some higher spikes. Four processor virtualized servers remained responsive during this test, but were very slow (slower than the physicals) and CPU utilization was between 30 and 75%, with some higher spikes. Two processor virtualized was almost non-responsive. CPU utilization rose to 100% and stayed there as long as the test was permitted to run. This happened for as few as twenty connections.
I don't want to draw too many conclusions until we have had further discussion of the testing. There may have been other limitations to tests 1 and 3 from the SQL server. Microsoft spends more time discussing SQL than it does SharePoint servers in the latest tuning info http://go.microsoft.com/fwlink/?LinkID=105621&clcid=0x409. I previously distributed this Microsoft tuning document (published in late December).
Microsoft recommends using 4 or 5 web front ends (without much qualification). Serving up files over 15 MB or having content databases over 50 GB is taxing on SharePoint and may degrade performance significantly. This latest tuning information from Microsoft is very conservative.
Our tests indicate that multiple processors are a key to maintaining reasonable performance from web front ends. Indexing seems to work fine from a virtual server.
So am I objective or what? My tests did little to confirm any of my original line of thinking.