PS 4.5 on x64 box, in the x64 Terminal Server / Citrix forum on BrianMadden.com

Hi,

We will be coming up with a project for a client to upgrade their PS 4 to 4.5 and rebuilding their hardware to a 64 bit OS. As well as this we will be installing another 2 processors and upgrading their ram to 8GB.

They will be running Microsoft Office 2003 products, MYOB and other applications that are 32 bit.

Has anybody run PS 4.5 in 64 bit and how well does it perform if all the client applications are 32 bit?

All of them are relatively light users, we have 75 users over 2 boxes with a single Xeon 3Ghz dual core and 4gb of RAM just FYI.

If they are all 32-bit applications what is the rationale for going to 64-bit? what are they hoping to accomplish? remember 32-bit apps take 1.5 times more memory on 64-bit than they did on 32-bit machines.


[quote=jasebert@hotmail.com]Hi,

We will be coming up with a project for a client to upgrade their PS 4 to 4.5 and rebuilding their hardware to a 64 bit OS. As well as this we will be installing another 2 processors and upgrading their ram to 8GB.

They will be running Microsoft Office 2003 products, MYOB and other applications that are 32 bit.

Has anybody run PS 4.5 in 64 bit and how well does it perform if all the client applications are 32 bit?

All of them are relatively light users, we have 75 users over 2 boxes with a single Xeon 3Ghz dual core and 4gb of RAM just FYI.[/quote]

For what it's worth, Benny Tritsch just did a session about this at BriForum, and you need to have BIG boxes before it's worthwhile to go 64-bit.. I forget the exact number, but it was like 16 or 24GB RAM minimum before you will see a benefit over 32-bit.

Brian

[quote=Brian Madden]For what it's worth, Benny Tritsch just did a session about this at BriForum, and you need to have BIG boxes before it's worthwhile to go 64-bit.. I forget the exact number, but it was like 16 or 24GB RAM minimum before you will see a benefit over 32-bit.

Brian
[/quote]

Brian,
Even with 4.5? You do not have the pod cast of this do you by any chance :)

Well what we have is that we have 45 users on a dual core, single processor 4gb box. I want to boost this up to 90 users hence my reasoning behind 4.5 and 64 bit and go to around 12GB, but this may not be a good configuration?

[quote=jasebert@hotmail.com][quote=Brian Madden]For what it's worth, Benny Tritsch just did a session about this at BriForum, and you need to have BIG boxes before it's worthwhile to go 64-bit.. I forget the exact number, but it was like 16 or 24GB RAM minimum before you will see a benefit over 32-bit.

Brian
[/quote]

Brian,
Even with 4.5? You do not have the pod cast of this do you by any chance :)

Well what we have is that we have 45 users on a dual core, single processor 4gb box. I want to boost this up to 90 users hence my reasoning behind 4.5 and 64 bit and go to around 12GB, but this may not be a good configuration?


[/quote]

We are a fairly new Citrix shop and we dove in head first with x64 on almost all of our 15 (and growing) servers. We are running PS4.0 and our two biggest problems is the lack of support from Citrix in regards to hotfixes and printing in x64 has also been a nightmare. We have not started testing 4.5 yet nor do we have any real experience with a heavy user load on x86 vs. x64 so it's hard for me to give advice but from our troubles i'd recommend maybe beefing those boxes up but sticking with 32bit.

If you look at Citrix's HFRP roadmap, you'll see that x64 isn't even on the radar...

Matt

[quote=jasebert@hotmail.com]Brian,
Even with 4.5? You do not have the pod cast of this do you by any chance :)[/quote]

No Podcast, but I know Benny was working on a huge paper about this, the results of which he presented at BriForum. I think his original paper is in German, but he's working on the English translation which he will publish here on BrianMadden.com.

I'll follow up with him right now!

I published a first article including some results of my 64-bit TS scalability tests on http://www.wtstek.com/item2/Article_64Bit_20070424.htm. As Brian said, I just finished the German version of a new article comparing OpenOffice 2.1, Microsoft Office 2003 and Microsoft Office 2007 both on 32-bit and 64-bit Windows Server 2003 R2 TS. (for those who speak German, it's on my http://www.wtstek.de site) Right now it's being translated into English and will be published on the Login Consultants website as soon as it's available.

If there is any interest I can also create an extra article describing the kinds of issues I encountered when setting up 64-bit TS environments. This would be something like "The making of 64-bit scalability tests -- behind the scenes" ;-)

Benny

[quote=Benny Tritsch]I published a first article including some results of my 64-bit TS scalability tests on http://www.wtstek.com/item2/Article_64Bit_20070424.htm. As Brian said, I just finished the German version of a new article comparing OpenOffice 2.1, Microsoft Office 2003 and Microsoft Office 2007 both on 32-bit and 64-bit Windows Server 2003 R2 TS. (for those who speak German, it's on my http://www.wtstek.de site) Right now it's being translated into English and will be published on the Login Consultants website as soon as it's available.

If there is any interest I can also create an extra article describing the kinds of issues I encountered when setting up 64-bit TS environments. This would be something like "The making of 64-bit scalability tests -- behind the scenes" ;-)

Benny
[/quote]

Look that is seriously awesome. Had a read and what you have done is taken my exact issues and put them into a test. Answered ALL my questions to a tee. Love your work on this one.

Also I would be very interested in what issues you had in setting up TS in a 64 bit environment.

As promised an English version of my whitepaper comparing the scalability of OpenOffice and Microsoft Office on both 32-bit and 64-bit platforms is available on my WTSTEK.COM Website now. Check out http://www.wtstek.com/item2/Article_OpenOffice_20070510.htm

Benny

We currently have a small (13 server) 4.5 farm on 64bit running production apps. So far things are running pretty well. Based on our experiences with citrix 4.0 64bit we should comfortably hit the 100+ users per server for most of our apps on the 4.5 environment. We are moving quickly to upgrade our current 32bit and 64bit 4.0 environments over to 4.5. The main reason to upgrade 4.0 to 4.5 is inconsistent patching. Now that 4.5 is based on the same codebase it should remain at similar patching levels across versions. As for server size, look for 12gig to be your standard for 64bit.

Just stood up a farm of all 64bit. We went with 16gb of ram per blade. So far so good with Windows 2003 R2 and PS 4.5.

My main annoyance is the lack of 64-bit print drivers. Mainly HP. I know go figure.

Greg

Hi there,

we where running Citrix PS4 on 62 x86 HP blade server which need to be replaced. On the other hand we needed to bring out MS Office 2003 plus Adobe Reader (used toghether with some web applications) to about 200-300 users with eventually some extra 500-1000 users comming soon in 2008. So we decided to replace the existing blade infrastructure with x64 hardware running Windows Server 2003 x64 and moved to Citrix PS4.5 x64. The goal was to reduce maintenance costs and administration effort by decreasing the number of servers. The sizing result (from tests of last summer with a single powerbuilder application) for the replacement was 15 servers with 4 cores and 8GB RAM with four extra servers for the new MS Office 2003 Silo.

I don´t want to bore you with more details but on request I´ll give you more. Anyway we expected to get more users on those servers....

The facts (regarding the silo with MS Office 2003): The blade servers (2P with 2GB RAM) running Windows Server 2003 x86 can handle about 30 user sessions. The new servers (HP DL 360 2P DualCore with 8GB RAM) running Windows Server 2003 x64 can handle more user sessions, but with about 55 user sessions the CPU load starts increasing and at about 60 user sessions the CPU reports "full load". Is that what we should expect?

Strange thing: With an 8GB pagefile the servers reports 95% usage of the pagefile while about 4GB of RAM is still available.

Next strange thing: At "full load" we had about 900 processes on the server. The process queue lenght increased to 120 and more. There are more than 50k context switches per second.

What we did: In summer (beginning of this project) we tested one of the new servers with a single application (x86, Powerbuilder). This test server was configured with 16GB of RAM. We experienced an increased CPU load at about 110 user session. But in this moment only 9GB of RAM was in use (plus nearly all of the page file). So we decided to buy servers with 8GB of RAM because obviously Windows and/or the application(s) cannot utilize more than about 8GB of RAM (or: using more than 8GB of RAM means high CPU load). Reducing the page file size to 4GB or 2GB did not make any difference.

Next stept: After the experience with MS Office on the 2P DualCore with 8GB RAM configuration we tested another server with two QuadCore CPU´s (again with 8GB of RAM) - with quite the same result (80 users / 1150 processes / 100+ on the process queue / high CPU usage / high page file usage / 4GB RAM free). Again - this is not what we expected.

I have read Benny´s article on the x86 x64 comparison (which is great compared to various existing white papers realted to this topic - thank you for this). I am little confused on the conclusion that a 64bit solution "only" performs much better than 32bit when the system is equipped with more than 16GB of RAM. The chapter regarding the PTE-Usage was quite interesting. Unfortunately we did not check this while testing - under normal load the new servers report 16 million of free PTE´s (41 users, 660 processes, 50k context switches)

Anyway our opinion is that currently "every server hardware" is 64bit aware and this is why every terminal server should use a 64bit OS to utilize more than 4GB of RAM and to handle a maximum of users. Adding extra CPU´s and Memory is not that cost intensive and so we would like to invest as much as neccesary to build a number of servers that can handle much more user sessions (we would like to reach 200 and more sessions...).

Is there anybody out there who can tell us what´s going wrong in this project?

For your understanding: I am Citrix administrator in our company since 1998 starting with Citrix Winframe 3.8 so I am quite experienced in this subject....

...waiting for your opinions. And thanks in advance for your support.

br, Gregor.

Hey Gregor

Is there an update to your situation?

In january 2007 we got a new version of a software. With the old version we could have 12 connected users per system or 6 connected user per core. Hardware were dual processors, single core, 3.0 GHz, 4 GB RAM. The constraint were the cpu contention.
We changed the complete architecure and software and switched from 32-bit to 64-bit for the terminal servers and the oracle database.
The initial load tests were done with dual processors, dual cores, 8 GB RAM, 3.0 Ghz. I don't have the results available but the conclusion was that we would have memory problems with such a configuration.
We measured the response time of the client application. This could be done because it is developped as an extension to ArcMAp by a third party. The degradation in response time was significant when we stressed the systems with more than 20 clients per core.

The final result was a dual processor, four cores, 16 GB RAM, 2.66 GHz, RAID1, 15k SAS, 128 MB cache, bbu with write-cache enabled. Nowadays I would buy 32 GB RAM but this was too costly with this hardware.

In the 32-bit world we had 60 users on 5 systems, now we have 120 users on 2 systems with only 2 height units.
Don't forget it is a real fat client (ESRI ArcMap based) with orthophotos loaded and where digitizing is done remotely. The perceived performance is better than before.
Memory goes up 70%, cpu to 30 to 50% constantly in the peak times.
The real constraint now is the number of licenses for ArcMAp.

I would recommend to measure the preceived reponse time of your client application. This is your real indicator. If you have problems then look at counters like processor queue length, context switches and so on.
The absolute values of this counters are pretty useless if you have no problems.
E.g. where is the problem of a fill rate of 90% of a pagefile of 16 GB if the i/o-system is able to handle i/o-requests in a timely fashion?
You should weight the counter values observed with the measured values of your target variable.

greetings

Andreas