RemoteApp and Bandwidth Usage
-
@coliver said:
@NetworkNerd said:
Regarding the additional connection, I remember looking into that not long ago, but the issue is we are on the hook for 3 years for the T1. I think we are about 1.5 years into it now.
It may be worth eating the cost and getting another connection in there. Even bonding it and just allowing the RemoteApp traffic to go through the new connection. Something to consider especially if productivity is being impacted as much as you described.
You may have to prove that it is a saturated line though.
Agreed.
-
It's not a straight "either uses this much." It is a factor of "how it is used" and what data goes across the line. A heavily graphical application will have a lot of RDP bandwidth. And poorly written queries will have poor SQL bandwidth. You'd have to test real world usage to know the numbers.
-
@scottalanmiller said:
It's not a straight "either uses this much." It is a factor of "how it is used" and what data goes across the line. A heavily graphical application will have a lot of RDP bandwidth. And poorly written queries will have poor SQL bandwidth. You'd have to test real world usage to know the numbers.
Are there any great free tools out there that will give you bandwidth usage by application on your LAN?
-
@NetworkNerd said:
Are there any great free tools out there that will give you bandwidth usage by application on your LAN?
Your switch should tell you a lot of that info. Mostly just the point to point numbers is all that you need.
-
Human feel is a big deal too. RDP might use more or less bandwidth but the responsiveness of the app might not be easily portrayed by that number.
-
@scottalanmiller said:
It's not a straight "either uses this much." It is a factor of "how it is used" and what data goes across the line. A heavily graphical application will have a lot of RDP bandwidth. And poorly written queries will have poor SQL bandwidth. You'd have to test real world usage to know the numbers.
I thought all RDP bandwith was minute. This surely explains a lot.
-
@technobabble said:
@scottalanmiller said:
It's not a straight "either uses this much." It is a factor of "how it is used" and what data goes across the line. A heavily graphical application will have a lot of RDP bandwidth. And poorly written queries will have poor SQL bandwidth. You'd have to test real world usage to know the numbers.
I thought all RDP bandwith was minute. This surely explains a lot.
Indeed it does. I tested Epicor via RemoteApp last night from this site, and as Scott said, there are small delays in the app (i.e. expanding folder trees is a little slower) that you would not experience if it was installed on your local machine. Though they be very small, it is noticeable to end users.
-
@technobabble said:
I thought all RDP bandwith was minute. This surely explains a lot.
Varies wildly. Size of desktop, amount of graphical change, if audio is passed, if printing is passed, how often the screen changes, how much of it changes, what types of graphics are used, colour depth, full desktop versus just one application... all factors.We've seen RDP top 10Mb/s. That's many T1s. And that was for a single connection and was rate limited by being on a 10Mb/s line!
-
@scottalanmiller said:
@technobabble said:
I thought all RDP bandwith was minute. This surely explains a lot.
Varies wildly. Size of desktop, amount of graphical change, if audio is passed, if printing is passed, how often the screen changes, how much of it changes, what types of graphics are used, colour depth, full desktop versus just one application... all factors.We've seen RDP top 10Mb/s. That's many T1s. And that was for a single connection and was rate limited by being on a 10Mb/s line!
That's nuts!
-
@NetworkNerd all it took was someone opening YouTube or a similar website. There is no way to significantly compress already compressed video. The bandwidth that YouTube needs expands when viewed over RDP rather than being compressed further. So the amount of bandwidth needed can rapidly explode.
-
@NetworkNerd said:
Regarding the additional connection, I remember looking into that not long ago, but the issue is we are on the hook for 3 years for the T1. I think we are about 1.5 years into it now.
Meh, that's OK. Like I said, something cheap on the side.
http://www.att.com/smallbusiness/internet/internet.jsp
Hell, even one of those cell devices that you pay by the month would work to prove it out. As long as it has ethernet.
-
is there no option to get a faster connection? Does this site require 100% connection? Rather, can it afford to drop connection at night? (Typically, I've seen this with Comcast Business Class) ..
Everything you've said regarding the RemoteApp leads me to believe it's the graphics that are chewing it up. Is the switch in the office manageable? Can you monitor your uplink port to your ASA? Could you dangle a sniffer off of one of the other ports on the switch and look for app traffic?
-
@scottalanmiller said:
@technobabble said:
I thought all RDP bandwith was minute. This surely explains a lot.
Varies wildly. Size of desktop, amount of graphical change, if audio is passed, if printing is passed, how often the screen changes, how much of it changes, what types of graphics are used, colour depth, full desktop versus just one application... all factors.We've seen RDP top 10Mb/s. That's many T1s. And that was for a single connection and was rate limited by being on a 10Mb/s line!
Well that explains the project I worked on for 2 years. The end users were using their own business class internet and we provided them the RDP icons only. So if you can't control their ISP, how would you make the system more responsive to compensate for the lag/delays that @NetworkNerd found?
-
@technobabble not much that you can do. Lag is lag. How do you get more traffic down a road? You add lanes. It's the only real answer.
You can move to more efficient protocols like ICA and View. You can see how a VPN differs. You can use WAN acceleration. You can create complex cache mechanisms. But at the end of the day the answer is bandwidth, latency and reliability.
-
@scottalanmiller said:
@technobabble not much that you can do. Lag is lag. How do you get more traffic down a road? You add lanes. It's the only real answer.
You can move to more efficient protocols like ICA and View. You can see how a VPN differs. You can use WAN acceleration. You can create complex cache mechanisms. But at the end of the day the answer is bandwidth, latency and reliability.
Thanks @scottalanmiller. I learned a lot on this subject today, which is why I joined this community!
-
Once you face bad latency complete app redesign might be the answer.
-
@scottalanmiller said:
Once you face bad latency complete app redesign might be the answer.
I felt that way many times when talking with the developers and the client. I felt that the program had been built for Server 2003/2008 and of course it "can" work with RDS, but we don't use it like that but there should be no problems. Actually had the lead programmer say stuff like that.
Many times i lamented to the client that perhaps a web based software would be better.
-
It's almost a foregone conclusion that a web-based package would be better. There is a reason that that is the standard answer for software design today - it works insanely well for the vast majority of applications. ERP would be one of the most obvious "always better as web software" scenarios. There is no good reason for any ERP software to have been anything but web-based since the very early 2000s. If they are still running legacy code, chances are there are a lot of other problems in the software too. It indicates a fundamental inability to make modern or good software. And in the IT world, being over a decade out of date is a really big deal.
-
Even if they decide against web-based for whatever reason (there are VERY few where a C# client, for example, would be beneficial unless they are doing crazy amounts of multi-threaded heavy processing on the client) since you lose flexibility, increase cost and lost cross platform support - you still design modern systems with light calls between the client and the server. If SQL calls are crossing the client-server connection then you have a massive design failure even bigger going back decades to where that was even remotely considered and acceptable design practice for newbie developers.
-
@scottalanmiller said:
Even if they decide against web-based for whatever reason (there are VERY few where a C# client, for example, would be beneficial unless they are doing crazy amounts of multi-threaded heavy processing on the client) since you lose flexibility, increase cost and lost cross platform support - you still design modern systems with light calls between the client and the server. If SQL calls are crossing the client-server connection then you have a massive design failure even bigger going back decades to where that was even remotely considered and acceptable design practice for newbie developers.
In the case of this application (Epicor), they made some big steps to just take out the Progress layer that was there even if you had a SQL back end. I'll take that for now.
