The results show that roughly 30 to 40% more users can sign on to the platform with Microsoft Office 2003 than with OpenOffice.org 2.1 with identical hardware and an identical configuration of the terminal server on Windows Server 2003 SP1. Even for terminal servers with Microsoft Office 2007, one can expect that the system resources can be used roughly 20% more efficiently than is possible on a system with OpenOffice.org. This applies both for the 32-bit and the 64-bit version of Windows Server 2003 when used as the primary platform.
Memory requirements of all three Office Suites on 64-bit Windows Server 2003 are increased by the factor 1.1 to 1.5 if compared to the 32-bit platform.
Can I point out that in both cases they managed to interactively log on more than 100 users onto a single 4GB server. This seems like really quite an achievement to me. Similarly while the methodology might be OK, it strikes me that no effort was entered into to measure the 'quality' (response latency) of the resulting sessions.
I also wonder as to the relevance of thin client benchmarking in this day and age. I think it has become the case that 'the thin client' now means a web browser, and that the smart way of dealing with 'fat' applications would be via external storage and standards based interoperability. Think IMAP for office applications (ODF over WebDAV for instance). Or, ironically, RSS.
With benchmarks like this they usually only focus on one application, so 100 users is probably for only a single Office application use. If you add in multiple windows, a business app, and maybe Outlook or Thunderbird then 100 users is less likely. I suspect that Office being a Microsoft app uses shared memory better, more application plumbing in the base OS. Which is what drives the better performance.
I would think though that response latency is very subjective and would have difficultly meeting one of the important requirements for a benchmark test: repeatability.
In a business setting the moving away from even "fat" thin client servers to SAAS style internal services is not so straight forward. Latency applications will continue to drive the needs for old fashion platforms. For example, I have a TCL accounting application. It is designed for Windows clients, the server can run on Linux and I have the source. Unfortunately the developer unexpectedly passed away before I was able to get him to fix the client end on Linux. The guys who have taken over the software are not able to this stage or maybe even soon consider even doing this sort of work. So the client platform choices are restricted.
CIFS or NFS are pretty much IMAP for documents, but as with IMAP, without change control. More advanced DM systems like Knowledgetree provide the more advance storage framework but don't have the 'online' editing functionality. The online editors like ThinkFree don't really have the DMS functionality a business needs. Plus only one online spreadsheet I've found so far handles the more complicated sheets I use.
In fact I was thinking the other day that a merger of functionality of both ThinkFree and KnowledgeTree would be nice. Maybe some way for a ThinkFree server to use KnowledgeTree in the back end.
Another aspect to consider in all this is scale. A 4 way Linux system with 32Gb of memory might handle more OpenOffice instances than a similar Windows System. Then you'd have to add in the RDP vs NX protocol analysis for that level of load. Benchmarks like all statistics is usually not clear cut in the big picture, but provide useful reference points.
Is there a step by step routine out there for installing OO.org on a Windows2003server running terminal server? I am looking for an installation routine that will enable all my clients to access OO.org simultaneously.
You should be able to install it in "Install Mode" as per normal. If you want GPO control, try Enterprise OpenOffice .