JDE Xe running XP Fat Clients on VM Ware : Performane Issues

[JDE0101]

Hi all,

We are running JDE Xe, SQL Server SP21_L1

Our fat client environment is on a VM-ware server ESX 3.0 4GB ram and Dual Core 3.2ghz

We have allocated approx 512 (some 256 for testing) ram to the 8 clients running XP SP2 fully patched

We are seeing really poor performance on object checkout and general fat client work. Typically checking out p4210 takes ~2mins and next time less. But we cannot see anything consistent. it seems lilke it takes an eternity to begin the checkout and then the screen appears to hang. The activeconsole.exe evnetually takes up 100% CPU and quite often JDE freezes..

Does anyboday have any advice on why this could be? i have tweaked the following things:

1. System Restore Off (marginal gain)
2. Mc Afee off / non scanning of JDE files (marginal gain)

Is there anyhting i can do regarding this?
is 512mb RAM too little?
is XP and Remote Desktop poor for development?

any help appreciated..

 

[Sebastian Sajaroff]

Hi there,

In my humble opinion, it seems that your problem may
come from your server NIC. Is it a 100 Mbps link?

If so, you're sharing 100 Mbps across 8 users, it would
be like 12 Mbps per user. Quite poor...

On the other hand, your JDE SP level is quite outdated,
you should think about updating to SP23 something.

I think you'd get much better performance from that
same server if you reinstall it as a Terminal Server,
there's a document somewhere in Knowledge Jungle that
explains how to setup a Terminal Server as a multiuser
development machine.

Have a nice day,

 

[altquark]

go to my website to find my document on setting up citrix for development (or terminal server alone, whatever).

Your issue lies within vmware. Its a great testing/development tool - but your issue is actually a production issue (I treat development users equally as production users - after all, there is a cost associated with their work). vmware is having issues performing against its local disk file - the way that specs are brought across means theres a lot of chatter and realistically, P4210 is a pretty big file to check out - the biggest in OneWorld. I'd expect 2 minutes to check it out with your configuration.

Get rid of all fat clients. Replace them with a single terminal server set up for development. You won't regret it.

 

[JDE0101]

the n/w link is a 1000mbps so no issues there. I understand the principal of setting this vmware server as one development server and giving each person a slice of it..but i think this customer wants to maintain the individual FAT Client approach..

re the vmware, does anyone have anything to chip in re our version of ESX and any settings/config that are vital. i keep thinking we have simply missed a config set-up etc....anyone got a vm ware checklist???

thanks for all the comments so far.

 

[gregglarkin]

I like your approach of slicing up the vm-ware server into seperate virtual fat clients. I am attaching an white paper I wrote on the topic for JDEtips. I'm no vm-ware expert, but I know there there are some settings that the admin can tweak to give the v-fatties more cpu time than other, less important virtual servers. I tested out a vm-ware terminal server. It's performance stunk until the server admin made the tweak. The question I have is, how busy is that vm-ware host? If it is hosting a bunch of other CPU and disk intensive servers, than that will impact your performance. Food for thought.

Gregg Larkin
Praxair CNC guy

 

[JDE0101]

just a note -
the mdac version on my fat client (2.8.1) is later than deployment server (2.7.0)

i also dont have visual C++ installed as we do not do any bespoke c++ coding, only standard report/application changes.

is there anyway to "tune" the SQLServer ODBC on the client?

could any of these explain my poor performance??

ta

 

[JDE0101]

just a note -

1. the mdac version on my fat client (2.8.1) is later than deployment server (2.7.0)

2. i also dont have visual C++ installed as we do not do any bespoke c++ coding, only standard report/application changes.

3. is there anyway to "tune" the SQLServer ODBC on the client?

4. we are running version 3.0 of ESX, any known issues??


could any of these explain my poor performance??

ta

 

[Alex_Pastuhov]

No, neither would. It's VMWare. In fact, you are lucky you didn't try this with MS Virtual PC first ;-), it's even slower...

 

[altquark]

I thought I already explained above where your performance issue lies. Its VMWares disk activity. One way to increase the performance is for your virtual machines to set it up to directly access raw disk sectors. Not nice, but a lot faster.

I bet you're using a physical RAID 5 device with only 3 or 4 drives for all your virtual machines too. That would also explain the performance issue.