[ QUOTE ]
We have been using JDE Xe, with Citirx XPe for years. The rule I have always followed was to only have about 35 users per citrix box. When I look at the utilization of our 3 citrix boxes, I see that they dont appear to be overwhelmed.....
[/ QUOTE ]
I just saw this thread, and thought it might be apt to comment on it, since I'm the chap who initially came up with the 32 users per box sizing estimate. I've commented on this before, and it requires a little bit of a history lesson of how OneWorld and Citrix/Terminal Server came to be.
First of all, you have to be aware that OneWorld has been supporting Terminal Services since 1997 - more than 10 years. The sizing "estimate" was scientifically created in 1998 - TEN YEARS AGO ! So of course, it isn't necessarily accurate with todays technology. But that is also why the W environments aren't accurate either.
Secondly, remember if you're using OneWorld Xe - it is also a product that appeared in 2000 - a product that is more than 8 years old. So you're trying to use old software on new technology using old sizing methodologies that have never been updated.
In 1997, I was given the task at ATG (The Advanced Technology Group in Denver) to test OneWorld under Terminal Services and Citrix (then, the products were in beta and were named "Microsoft Hydra" and "Citrix Picasso") to show that they DID NOT scale - that the technology was NOT as good as general CNC practices !!
Our test bed was a DEC Intel server with quad 180MHz Pentium Pro processors and 2Gb of memory. Yup, this was in 1997 - so the box back then was (almost) state of the art !
Our initial test was against a SQL 6.5 database server and we had a script set up in Macro Scheduler to plug away orders in P4210 - 5 line sales orders every minute or so per user.
When we loaded up Oneworld, we noticed that at around 5-6 users, there was a huge spike in CPU processing - ramping up to 100% - and although we could load a couple more, soon each of the sessions were becoming unusable due to this CPU utilization and each session "hanging". Our initial test, therefore, proved that Terminal Servers (and therefore Citrix) was NOT a solution that JDE should be recommending.
However. I sat back and looked at what exactly was hammering the CPU's - and thought to myself that if I mapped the business functions away from the Terminal Server (say, onto the Enterprise Server) - using our latest CNC practices - that we might get over the initial CPU utilization issue. Lo and behold, almost all CPU utilization disappeared, and suddenly we were able to start scaling the terminal server. We were able to show, therefore, that with the business functions mapped off the terminal server - that Citrix/Terminal Services COMBINED with CNC practices produced a scalable, recommended solution.
The next limit we found occurred at around 40-42 users or so. In effect, the memory was being utilized and when the physical memory started to "top out" that the amount of paging from each of the sessions started to impact the CPU utilization again - and we started to see some performance degradation that would impact end users.
Looking at the average memory utilization per session - each user seemed to be utilizing around 40Mb of memory. Therefore with a standard windows NT 4.0 Terminal Server Edition setup, we saw around 40 concurrent users with 2Gb of memory.
However, because of the stability (back in 1998) of the Terminal Server and the amount of "memory leaks" we saw both in the OS and in the product, we felt that a company with, say, a few hundred concurrent users - we wanted to scale the Terminal Server to 80% of the number of expected users - so that for every 5 servers, we would have the ability for one of those terminal servers to fail and still be able to support the customers users. 80% of 40 users is 32 users.
Fast forward to 2000. By now, almost every customer of OneWorld utilizes Windows Terminal Servers and Citrix. (for the comparison history between Terminal Servers RDP and Citrixs' ICA protocol - thats altogether another story). Lots of customers have a requirement to deploy across a WAN - and many customers like the terminal server since it dramatically reduces the management but also provides predictable network utilization.
But in 2000, the Pentium III processor was available - two full generations beyond what we had tested in 1997 - and the processor speed was able to peak to 1.4Ghz by 2001. That was a total of more than SEVEN times the amount of processor speed compared to the pentium pros'.
Therefore, by the time that Pentium III 1.4Ghz processors were available - together with the improved Windows 2000 server OS - the requirement for mapping business functions to scale to 40 concurrent users had disappeared. Since JDE hadn't fully got their business functions to work on application servers by then, there was a convoluted list of BSFN mappings - around 450 or so - that the install team introduced with Xe and called the "W" environment. Of course, logically, the "W" environments were a terrible idea since developers sitting on fat clients weren't viewing the same type of environment as the end users on terminal servers with the W environments !
Over the next few years, I went through a huge struggle to reverse the "W" environment mappings - instead recommending either running fully 2 tier (only mapping business functions for business reasons) - or going fully 3 tier using something that is now referred to as the "J" environments, and running ALL users on that environment type - no matter what client type they are running. That way, the users are on a consistent environment and support issues between fat clients, Java clients and Citrix clients cease to become and issue.
[ QUOTE ]
For instance, we have dual proc machines with 6 GB ram, with 35 users we are still only using about 2.8 GB RAM
[/ QUOTE ]
So, why did the 32 user sizing limit stick ? After all, in your example you have 6Gb of memory - so could conceivably utilize 96 concurrent users on the box !
Well, until recently, the limit for Windows 2000 server has been limited to 2Gb of Memory. This was increased to 4Gb for Windows 2003 server - though the "enterprise" edition could be utilized - but at a significant increase in cost. Secondly, the COST for slamming lots of memory into a single box was FAR in excess of the cost for two boxes with the same memory. Therefore, since you can provide more REDUNDANCY with more smaller boxes compared to fewer large boxes, it was recommended to stick to the 2Gb limit. Today its probably wise to size to 64 users for every 4Gb of memory, providing the latest CPU's are being used - and, as the price point falls, the sizing should be re-evaluated.
If you ARE seeing issues, however, and you're not seeing paging issues or CPU utilization - then maybe the number of context switches is becoming an issue ? Windows has some limits there - and a simple run of Perfmon and a google of performance monitoring will identify issues like this.
So - that is the reason. There are a couple of interesting points that come out of this.
First of all, the 40Mb utilization is specifically around the oexplorer.exe process (the OneWorld Explorer). If you are using Solution Explorer (activera.exe) - then expect DOUBLE the memory utilization. I've noticed that customers using solution explorer literally can scale to half the users compared to OneWorld explorer users. So, 8.9 and 8.10 - since they require solution explorer - requires more memory per concurrent user.
Secondly, a web client uses about the same amount of memory per session as a OneWorld explorer users - ie, about 40Mb. Therefore the JVM recommended size of 1.2Gb means that you can run about 30 concurrent sessions per JVM - coincidence ? I doubt it ! Of course, you can load up dozens of JVM's on a single server - especially using 64bit OS's - providing you have the physical memory to handle them...!
I hope that provides some explanation. I can forward links to the original Terminal Server testing documents (which are on my website) for anyone interested in the history behind these numbers !!!
