| || |
Server versus Workstation OS for load testing
I am trying to figure out if there are good reasons to upgrade our load testing machine from Windows 2000 Pro to Windows 2003 Server. The application we are testing is J2EE, so some members of our team maintain that because the app is running inside a JVM it has no knowledge of the OS, and that hardware will affect performance the most.
I suspect, however, that Windows Server probably makes more resources available to applications, and therefore would affect performance. I know that IIS, for example, is limited to 10 concurrent connections on Windows XP Pro, but can use "unlimited" connections on Windows 2003 Server.
So I'm thinking that for load testing, which by definition is multi-user, we should be using a Server version of Windows rather than a Workstation version. What I'm lacking is sufficient justification for making the switch.
Any advice is much appreciated. Thanks.
Re: Server versus Workstation OS for load testing
Your restriction on Microsoft Server offerings on Microsoft workstation OS's is correct, only a limited number of inbound connections. This restriction is microsoft monolithic however. Place Oracle, DB2 or Apache on a workstation OS and they work just fine up to the limit of the OS or the license (whichever comes first). This lockdown in many respects dates from as far back as 1994 when Microsoft changed the way that SQL Server and SNA Server customers had to deploy their server products. With SQL Server 4.21, unless you were deployed on a Micrsoft NT Server OS, then you had only ten connections. SNA Server and SQL Server had been leading the charge for the (then new) NT operating system on a departmental basis, but NT Server was not making much headway except into traditional Microsoft Lan Manager shops. BOOM! Overnight thousands of NT Server products were sold to underpin existing SQL Server and SNA Server installations which "broke" with the latest patch upgrade and all of the sudden Microsoft was "on the map" with thousands of server versions of NT sold. In short, Instant Critical Mass.
Microsoft locks the restriction down in the APP, not in the OS, so the number of inbound and outbound sessions is limited only by your hardware and registry settings, some of which you may have to improve for additional headroom. MSDN and Technet have great articles on registry settings for network if you need to go that route.
Your colleages are right about the JVM. Effectively it is a hosted OS within an OS. It does not know the difference between server and workstation versions of Windows, which vary only in specific Microsoft networking components and the number of processors and RAM supported on a box (RAM directly related to number of processors).
If you are using these boxes as load generators, then you should be fine using Windows workstation products. I have yet to see a load generator that goes beyond the limitations imposed by two processors and the amount of RAM associated with such a limit.
I would advise you to consider treating the load generators as servers from the standpoint of RAM, offloading CPU intensive operations whereve possible though the use of co-processed video, network, disc cards. If you can spring for hardware that contains tcp offload engines and hardware management of SSL then all the better. This will leave the maximal headroom on the processor to service the user threads for load generation.
... a change agent
Replace ineffective offshore contracts, LoadRunnerByTheHour
. Starting @ $19.95/hr USD.
Put us to the test, skilled expertise is less expensive than you might imagine.
Twitter: @LoadRunnerBTH @PerfBytes