E1 Fat Client Usage

Jeff George

Jeff George

Well Known Member
Since part of my team is not in the location where the servers are we use remote desktop to connect to fat clients at the server site. However, it's frustratingly slow. The one I'm using is extremely slow and gets slower with use. I can literally click on something and wait ~30 seconds for the click to register. I reboot it and it's fine for a short period of time but then the behavior begins again. Is there really no better way to have remote access to a development machine?
 
Are the fat clients used for RDP the exact same specs as the ones used by the on-prem team or are they VMs? I suspect the issue is most likely the machine or VM you are RDP'ing too and not necessarily RDP in and of itself - unless I guess RDP is leaking memory or something and causing swap file thrashing...

We have two instances of E1 in my organization. For one instance we use Bare Metal development boxes and for the other instance we have a set of Development client VMs running on a Hyper-V cluster that we RDP into. The VMs are noticeably slower for some development operations when compared to my bare metal development box that I use for my other E1 instance even though my Bare Metal box is pretty old at this point. The VMs are properly sized from a CPU/RAM perspective. I have never really tried to track down exactly why, but I suspect primarily disk throughput on the VMs (or possibly network bandwidth) - my bare metal development box has its own SSD which I am guessing makes a big difference...
 
Actually, there are no developer/fat client users left at the site that contains the servers. Everyone is remote now. They are not VMs but physical workstations running Win 7 Enterprise and with 8 GB of RAM. I have no faith in the CNC or network set up, but don't imagine that there's much I can do about that. The performance just seems to be getting worse. My client workstation seems to be performing the poorest. I'm also wondering if maybe the hard disk in it is going back. I shouldn't be seeing screen rewrites chunk by chunk. I'll keep monitoring it and see if it stays the same. Maybe something is just going on with it lately.
 
Jeff,

When you are seeing the screen refresh in 'chunks' that is one of the indicators I use to indicate network issues. Can you run Task Manager and confirm that your memory and CPU consumption are reasonable?

Tom
 
Like Tom, I start to question the network connection if you start seeing the video artifacts like you describe. I still wonder if you might have performance issues even if you were on-prem. Do you have issues with all the workstations or do you mainly just connect to a single workstation?
 
I only use one workstation. My location is connected to the server location through a dedicated Internet line and we use Remote Desktop to connect to the workstations. Many people here think the network performance has always been a problem, but our network people at the other site insist it's fine. Other people at my site have had similar behavior with their fat clients, though it doesn't seem consistent between users or workstations, nor does everyone experience it at the same time. From my perspective the CPU and RAM is not being excessively used. The biggest memory user is oracle.exe, which is using about 5x what activConsole.exe is using, with java.exe using about double activConsole.exe. I think I'm stuck with this situation. It's just extremely frustrating trying to get things done when your input doesn't even register on the remote system.
 
Jeff,
it really does sound like a network issue.
Out of curiosity please define your "dedicated Internet line". Unless someone has run a line from your PC to the Remote PC there's really no such thing as "dedicated" anymore. Its all traffic management over shared resources anymore.
Have you tried the following when its acting up?
1. Run continuous ping from your PC to the remote.
2. From both your machine and the remote PC run a internet speed test (ookla)
 
Also check your RDP settings and set it to a lower experience level (something like WAN), don't let RDP detect. And make sure everyone else does the same... no need to chew up bandwidth to send the remote's wallpaper back. Also check for local printer connections through RDP, sound, etc. Basically you want everyones RDP connection to use the bare minimum.
 
Last edited:
You aren't by any chance short on network wall plugs and using hubs are you? They can be the death of network performance, and the network itself will show all is fine.

Just a thought.

Tom
 
The connection is an MPLS. It occurs to me as I think about it that I also remote directly to a Windows Server 2008 system to use a non-JDE application's Development Studio. I have none of the issues with this server that we have with the Win 7 workstations, so maybe it is something with a Win 7 bug. I'll check out that link.
 
I had similar issue and the machine were old VMs. I had Infra build new VMs and performance got much better .

Chan
 
Back
Top