RemoteApp and Bandwidth Usage
-
We recently deployed a new RDS server and are using RemoteApp for users to run Epicor at our remote sites. The Epicor servers and the RDS server are running at our main site with all remote sites connected back to the main site via site-to-site VPN connections using Cisco ASAs.
At one site in particular, we only have a T1 as the internet connection (about 10 users). The users at that site are telling me that RemoteApp is just too slow and that they want Epicor installed on their location machines. They seem to think having the client on their local machine and running it normally will improve performance greatly.
I can tell you we moved away from a Server 2003 terminal server that we were using for people to use to run Epicor, and the users at this site had issues with the connection to the terminal server being too slow (screen in RDP session was being repainted slowly enough to keep them from being too productive) and had to have Epicor installed on their local machines. They claimed it was faster, and it was because of the RDP issues.
So my question here is...how much bandwidth does RemoteApp use compared to just running a database driven application on a workstation over the VPN? We know (theoretically) that running Epicor on the RDS server will make Epicor run faster than running it over VPN because the RDS server and the Epicor servers are VMs on the same ESXi host. But, if the connection speed to the RDS server is not that great, I guess that really puts a chink in the chain.
I'd love to hear any comments on this one. I just do not see what makes RemoteApp so much slower from this site. Users at sites with 10/10 connections are not giving me the same story.
-
I'm not sure how Epicor works exactly, but you say it's a database driven application. Now, RDP sessions require minimal bandwidth, and if the RDS server and Epicor server are on the same network, all you're viewing is that screen and all the other traffic stays local. Installing Epicor client software? on the remote PCs and accessing the database over the VPN means that you are, in my opinion., pulling an enormous amount of data over the VPN, which strains the VPN, the ASAs, and their WAN connection. If the database is 10GB (I'm guessing that's probably way low but just throwing it out there), you've got each person using Epicor trying to connect to basically 10GB of data each individually. The RDS server makes the most sense.
It likely isn't the case, but have you ruled out things like their local machines running slow, etc? Assuming your firewall has pretty much all traffic route through it, I think there are stats you can view on the ASA to look at bandwidth usage, etc.
-
Do you have a dedicated switch between the RDS servers and the Epicor servers?
-
@technobabble said:
Do you have a dedicated switch between the RDS servers and the Epicor servers?
From what @NetworkNerd mentioned these are both hosted on the same physical machine. So connectivity shouldn't be an issue.
-
@coliver said:
@technobabble said:
Do you have a dedicated switch between the RDS servers and the Epicor servers?
From what @NetworkNerd mentioned these are both hosted on the same physical machine. So connectivity shouldn't be an issue.
Yep - the VMs are on the same ESXi host. There about 5 switch hops between the ESXi host and the ASA that goes to the remote site and then only one hop from the ASA at the remote site to the workstations in question.
-
I think it would depend on how much data the users actually use per connection to Epicor. I know RemoteApp basically uses almost no bandwidth to begin with (64kbps comes to mind but don't quote me on that). Do you have a router/firewall over at this remote site where you can monitor traffic and see how much RemoteApp is actually using?
-
@coliver yep...totally glossed over that info!
-
@coliver said:
I think it would depend on how much data the users actually use per connection to Epicor. I know RemoteApp basically uses almost no bandwidth to begin with (64kbps comes to mind but don't quote me on that). Do you have a router/firewall over at this remote site where you can monitor traffic and see how much RemoteApp is actually using?
I can monitor to some extent with the ASA 5505 at the remote site and look for calls to the ip of the RDS box. As far as bandwidth monitoring, the ASA does not really give you much to see. I guess I could use a free monitoring tool from Solarwinds, but it's really only for a switch port's bandwidth monitoring.
-
@NetworkNerd said:
@coliver said:
I think it would depend on how much data the users actually use per connection to Epicor. I know RemoteApp basically uses almost no bandwidth to begin with (64kbps comes to mind but don't quote me on that). Do you have a router/firewall over at this remote site where you can monitor traffic and see how much RemoteApp is actually using?
I can monitor to some extent with the ASA 5505 at the remote site and look for calls to the ip of the RDS box. As far as bandwidth monitoring, the ASA does not really give you much to see. I guess I could use a free monitoring tool from Solarwinds, but it's really only for a switch port's bandwidth monitoring.
I was just looking for numbers on my firewall at our remote site to see what the 2X Application is using for bandwidth and couldn't find anything specific.
-
I have a suspicion that this may have more to do with latency between sites than anything. When nothing is happening, the latency between a client pc at the remote site and the RDS server is 8-10 ms. And as you can imagine, Epicor runs like a champ via RemoteApp. At times you will see latency go up over 100 or 200 ms. There's not a consistent pattern to it, really. You can tell when the latency spikes because the Epicor performance stutters (screen refresh stutters).
I think we have some network issues to sort out over there. The users at this remote site have no web filter and are pulling files, a company intranet site, Epicor, e-mail, and most everything else from the main site. There is one Engineering server over at this site that synchronizes with a server at the main site occasionally, but I was thinking we had verified that this is only happening in the evenings.
I think I'll end up being forced to install the app for people at the remote site. We just migrated to a new version of Epicor over the holiday and are trying to work out the kinks. But during these latency spikes, instead of people having screen update stuttering, they are just going to have application errors or a nonresponsive application. So how can they really say it is faster when running on a local pc?
-
@NetworkNerd said:
I have a suspicion that this may have more to do with latency between sites than anything. When nothing is happening, the latency between a client pc at the remote site and the RDS server is 8-10 ms. And as you can imagine, Epicor runs like a champ via RemoteApp. At times you will see latency go up over 100 or 200 ms. There's not a consistent pattern to it, really. You can tell when the latency spikes because the Epicor performance stutters (screen refresh stutters).
I think we have some network issues to sort out over there. The users at this remote site have no web filter and are pulling files, a company intranet site, Epicor, e-mail, and most everything else from the main site. There is one Engineering server over at this site that synchronizes with a server at the main site occasionally, but I was thinking we had verified that this is only happening in the evenings.
I think I'll end up being forced to install the app for people at the remote site. We just migrated to a new version of Epicor over the holiday and are trying to work out the kinks. But during these latency spikes, instead of people having screen update stuttering, they are just going to have application errors or a nonresponsive application. So how can they really say it is faster when running on a local pc?
There are a lot of things it could be. In NY, it was not uncommon (ask @Minion-Queen if you don't believe me) for someone to have great internet speed, but not when it rained, or something like that. If the weather is bad, or there is another person on the main pipe eating up all the bandwidth, etc. There are any number of things it could be.
-
Yes every time we get bad weather our internet connection stinks (like today for example). Also our Cell service goes down hill as well. I hate winter weather, thanks for reminding me to complain about it @thanksaj
-
At this site in connection we know the connection to the internet is solid. That's the one aspect that has never been an issue.
-
@Minion-Queen said:
Yes every time we get bad weather our internet connection stinks (like today for example). Also our Cell service goes down hill as well. I hate winter weather, thanks for reminding me to complain about it @thanksaj
You're welcome.
-
@NetworkNerd said:
At this site in connection we know the connection to the internet is solid. That's the one aspect that has never been an issue.
Then is a faster connection possible?
-
@NetworkNerd said:
I think we have some network issues to sort out over there. The users at this remote site have no web filter and are pulling files, a company intranet site, Epicor, e-mail, and most everything else from the main site. There is one Engineering server over at this site that synchronizes with a server at the main site occasionally, but I was thinking we had verified that this is only happening in the evenings.
This seems like quite a bit of traffic going over a T1, how many users do you have over there? Do some of them stream music/video? Do you use a client based email system where some users will be downloading the same attachment multiple times (more then one user downloading the same attachment?)
-
@coliver said:
@NetworkNerd said:
I think we have some network issues to sort out over there. The users at this remote site have no web filter and are pulling files, a company intranet site, Epicor, e-mail, and most everything else from the main site. There is one Engineering server over at this site that synchronizes with a server at the main site occasionally, but I was thinking we had verified that this is only happening in the evenings.
This seems like quite a bit of traffic going over a T1, how many users do you have over there? Do some of them stream music/video? Do you use a client based email system where some users will be downloading the same attachment multiple times (more then one user downloading the same attachment?)
We have about 10 users total. I'm not 100% certain about the streaming aspect, but I would think if anyone knew they were streaming they would quickly be lynched as the people over there know they have limited bandwidth.
We use Exchange 2010 hosted at our main site (clients using cached Exchange mode). But users at this site normally tell us things pick up when Engineers are not over there working.
-
@NetworkNerd said:
@coliver said:
@NetworkNerd said:
I think we have some network issues to sort out over there. The users at this remote site have no web filter and are pulling files, a company intranet site, Epicor, e-mail, and most everything else from the main site. There is one Engineering server over at this site that synchronizes with a server at the main site occasionally, but I was thinking we had verified that this is only happening in the evenings.
This seems like quite a bit of traffic going over a T1, how many users do you have over there? Do some of them stream music/video? Do you use a client based email system where some users will be downloading the same attachment multiple times (more then one user downloading the same attachment?)
We have about 10 users total. I'm not 100% certain about the streaming aspect, but I would think if anyone knew they were streaming they would quickly be lynched as the people over there know they have limited bandwidth.
We use Exchange 2010 hosted at our main site (clients using cached Exchange mode). But users at this site normally tell us things pick up when Engineers are not over there working.
So it works fine 80% of the time but then the latency spikes for 20% of the time? Guessing on the actual numbers but it does sound like link saturation. Not sure how else you could test it though.
I find it hard to believe that an application linked to a live database is more forgiving with latency then a RemoteApp.
-
@NetworkNerd said:
@coliver said:
@NetworkNerd said:
I think we have some network issues to sort out over there. The users at this remote site have no web filter and are pulling files, a company intranet site, Epicor, e-mail, and most everything else from the main site. There is one Engineering server over at this site that synchronizes with a server at the main site occasionally, but I was thinking we had verified that this is only happening in the evenings.
This seems like quite a bit of traffic going over a T1, how many users do you have over there? Do some of them stream music/video? Do you use a client based email system where some users will be downloading the same attachment multiple times (more then one user downloading the same attachment?)
We have about 10 users total. I'm not 100% certain about the streaming aspect, but I would think if anyone knew they were streaming they would quickly be lynched as the people over there know they have limited bandwidth.
We use Exchange 2010 hosted at our main site (clients using cached Exchange mode). But users at this site normally tell us things pick up when Engineers are not over there working.
Yeup, someone is slurping bandwidth.
Can you get a second pipe into the place, cheap DSL or Cable? I have a Peplink 300 I can loan out to you, can handle 15Mbps total worth of traffic, more than enough for a single T1 and a 6Mpbs pipe. Don't even have to do anything on the T1/VPN side of things, just put it into drop in mode and set up some rules to shuffle HTTP/HTTPS traffic over the cheap pipe.
That way you can bug management to get a bigger pipe into the place. Or a bigger Peplink.
-
Here's a shot of what is happening. The 8-9 ms is what we get when everyone is away from their computer (pretty consistently). But even during periods of heavy use, there's never a latency spike like this at our other sites. But none of them are running over a T1, either.
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.
The investigation continues.
