| | |
Help with RDP latency, ideas for optimization?
![]() |
We have a VB6 application that was developed in-house, that are trying to make available to remote users. The remote users are connecting from the other side of the world, through a VPN tunnel to our network; RDPing into a terminal services server and then running the VB6 application. Essentially, the application is a data entry one - it displays an image on the left side of the screen and data entry points on the right side of the screen.
Remote users are complaining about bad UI lag, screen repainting, etc. Their latency is reported at ~300ms, compared to <1ms locally.
Now, this app never was intended to be run remotely, it was developed against a LAN environment, and so we're starting to see some quirks come out when trying to run it in an environment where the users are not onsite. We're trying to figure out how and where we can optimize things, if there's a problem with the VB6 app, or with RDP, or what. Can anyone offer any ideas on things to try?
We've toned down all the settings for the RDP clients. It's set for a 28.8k environment (nothing turned on except bitmap caching), and I recently connected using a 256-color setting. It may have been a small improvement over the 16-bit colors, but not much.
I guess I feel like I'm fishing in the dark here. My understand of RDP is that everything runs locally on the RDP server; the protocol is just sending lots of screenshots of sorts over the wire, plus info on input devices like mouse location, etc. What else might affect the quality of the "experience" of using an application over RDP? The users are comparing our app with another division's app, saying the other one performs better. Both basically do the same thing.
How does the application architecture affect things? There *are* a lot of controls painted on our VB6 app, and when I test the high latency situation, I do see it paint the controls if it refreshes the screen. Is this just a nature of the way the app was built? Is there anything I can look into to see if I can improve things?
Thanks!
Remote users are complaining about bad UI lag, screen repainting, etc. Their latency is reported at ~300ms, compared to <1ms locally.
Now, this app never was intended to be run remotely, it was developed against a LAN environment, and so we're starting to see some quirks come out when trying to run it in an environment where the users are not onsite. We're trying to figure out how and where we can optimize things, if there's a problem with the VB6 app, or with RDP, or what. Can anyone offer any ideas on things to try?
We've toned down all the settings for the RDP clients. It's set for a 28.8k environment (nothing turned on except bitmap caching), and I recently connected using a 256-color setting. It may have been a small improvement over the 16-bit colors, but not much.
I guess I feel like I'm fishing in the dark here. My understand of RDP is that everything runs locally on the RDP server; the protocol is just sending lots of screenshots of sorts over the wire, plus info on input devices like mouse location, etc. What else might affect the quality of the "experience" of using an application over RDP? The users are comparing our app with another division's app, saying the other one performs better. Both basically do the same thing.
How does the application architecture affect things? There *are* a lot of controls painted on our VB6 app, and when I test the high latency situation, I do see it paint the controls if it refreshes the screen. Is this just a nature of the way the app was built? Is there anything I can look into to see if I can improve things?
Thanks!
We recently did much the same thing with some enterprise type software - from the Middle East to London.
A VPN tunnel is bound by internet message fragmentation with associated red tape, checksums and the like. Mixed into this is the question of how keystrokes are echoed to the screen, usually one at a time. All the multiplexors on the way, the CIA, GXCHQ and all the other routes, paths and dodgy circuits, etc.
So 300ms is nothing unusual (the electrical path will be nearly double the straight line).
Wherever we could, we used a Citrix session from the remote site (the VB application running on the Citrix server at HQ) because Citrix has very strong compression and you could see what you were typing on a message rather than per character basis.
Does all that help and make sense?
A VPN tunnel is bound by internet message fragmentation with associated red tape, checksums and the like. Mixed into this is the question of how keystrokes are echoed to the screen, usually one at a time. All the multiplexors on the way, the CIA, GXCHQ and all the other routes, paths and dodgy circuits, etc.
So 300ms is nothing unusual (the electrical path will be nearly double the straight line).
Wherever we could, we used a Citrix session from the remote site (the VB application running on the Citrix server at HQ) because Citrix has very strong compression and you could see what you were typing on a message rather than per character basis.
Does all that help and make sense?
Suspishio
My advice is at your risk
Qosmio G50-10H; T9400 2.53GHz Core 2 Duo; 4GB RAM; Vista HP (32)
nForce 680i LT; Q6600 Quad Core 2.4GHz; 8GB RAM; XP Pro (64)
Dell XPS M1710; T7200 2GHz Core 2 Duo; 2GB RAM; XP Pro (32)
My advice is at your risk
Qosmio G50-10H; T9400 2.53GHz Core 2 Duo; 4GB RAM; Vista HP (32)
nForce 680i LT; Q6600 Quad Core 2.4GHz; 8GB RAM; XP Pro (64)
Dell XPS M1710; T7200 2GHz Core 2 Duo; 2GB RAM; XP Pro (32)
![]() |
Other Threads in the Windows NT / 2000 / XP Forum
- Previous Thread: Ebay Running Slow
- Next Thread: deleting .dll files
| Thread Tools | Search this Thread |
.net 3.5 3daccelertion 64bit 2010 activedirectory alaris android application arm auto black blue book bsod canonical cellphones chinese codeplex collaboration combofix computer computerfreezes crash deployments desktop desktops domain dotnetnuke drive error errors explorer fax folder fonts freeze gadgets hardware home intel killprocess laptop laptops latitude lcd linux load mac markshuttleworth memory microsoft minimalizes mobile monitor netbooks opensource operatingsystems options oracle osinstallationproblem outlook partition patch port product program proxy raid rds reformat remotedesktopconnection retail screen security server. slowperformance sp1 sp3 spyware studios ubuntu unreadable update upgrade usb verizon virtual virus vpn vulnerability wab webos weecam window windows windows7 windowsxp worm xp






