Re: TS vs VPN
- From: "Josh Rosenberg [MSFT]" <joshrose@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 26 Jan 2007 15:10:01 -0800
I'm not entirely sure I understand what you are getting at here, so let me state the assumptions in my answer.
There are three machines involved:
1. A client machine at your remote site
2. A Terminal Server (TS) at your "local" site
3. A SQL Server at your "local" site
There are two possible scenarios:
1. Using TS, w/o VPN
a) The remote client connects to your local TS via Remote Desktop (RD).
b) In the RD session, they run program "Foo" on the local TS.
c) "Foo" accesses the SQL server, which is nearby in a protected part of the network.
2. Using VPN, w/o TS (Note: At no point is machine #2 involved in this scenario)
a) The remote client establishes a VPN link to your protected network.
b) The remote client launches program "Foo" directly.
c) "Foo" accesses the SQL server over the VPN connection.
You want to know which of these would exhibit better performance.
The answer is... It Depends.
In terms of startup time, a properly secured VPN usually takes a minute or two to fully establish the connection and audit the machine for security purposes.
By contrast, a Remote Desktop connection can be established in as little as 5 seconds, and usually no more than 40.
Winner: Terminal Server
In terms of general usage, it gets trickier. How much data is being exchanged with SQL Server, and of that data, how much is displayed onscreen?
If it's a huge amount of data, or a lot of small queries, but it is condensed for viewing purposes (i.e. pulling out statistical information for instance), you definitely want to stick with the TS approach. That way, the majority of the network traffic is on your (presumably fast) local network, and the relatively small amount of TS traffic goes of the (presumably slower) external lines. If there are a lot of small queries, and the program needs to make them to provide on the fly feedback to the user, the TS wins due to reduced latency. After all, if they are running the client locally and it needs constant communication with the SQL server, the chokepoint will be the SQL communication. The client won't get any benefits from running the application locally because it will be waiting on the network.
If communication with the SQL server is minimal and not needed for snappy user experience and/or the UI for your program has a lot dynamic animation, it may improve performance if you skip TS. Fast moving animation will choke a slower TS connection, so running the program locally removes that bottleneck. If this is your scenario, but you still want to use TS, layering Citrix on your TS may help with efficient animation redirection. With their Seamless Windows (name?), you could even run your program in an integrated fashion with the remote client's desktop, so they still use their desktop while your program is loaded. When Longhorn Server is released, there will be a similar feature, Remote Apps, which will accomplish the same result.
Usability is another point. If your VPN locks off access to the internet, it may cause headaches for users which TS doesn't involve.
Finally, reliability matters. With TS, everyone has a single point of access to the program in question, and it is under tight control. If anything goes wrong, your local team can work on it and fix the problem. In the VPN scenario, you have a higher total maintenance cost; if your program starts messing up, you have to figure out whether it is the machine or the program exhibiting problems. Since the client isn't under your direct control, viruses, spyware and nifty toolbar widgets mean that the problem is often unique to particular machines and hard to pin down. Often this will involve dispatching IT personnel to the remote site. Since there are X client machines to maintain, each of which exhibits a higher rate of failure due to lack of complete IT control, vs. just one or two locked down TS machines, you may end up paying a lot more in long term support due to fragmentation in your installed base.
Under most scenarios, the TS approach will serve you best. It keeps the heavy network traffic in the LAN, and it saves you a lot of IT support headaches. Yes, I'm a bit biased, but after years of hearing about the headaches caused by decentralized IT, I've really come to appreciate the benefits of centralizing to reduce IT costs in the long run.
If I've misinterpreted your question or you would like additional information, please post a reply.
--
Josh Rosenberg [MSFT]
SDE - Terminal Services
"Jonathan" <11user@xxxxxxxxx> wrote in message news:1ssuh.1751$O%3.1112@xxxxxxxxxxxxxxx
Hello -
We're wanting to set up a remote site that will be running some software that will need to access our SQL server located on site. I've currently got them set up using a remote desktop/terminal services connection with the software running on one of our local machines. I'm considering switching to a VPN connection where the software would run on their machine but the VPN would still allow access to our SQL server. My question is which of these methods is likely to provide the best speed. With TS I understand it's more of a refresh issue that slows things data because less data has to be sent. With VPN more data would have to be sent but it seems like the software itself would run faster because it's on a local machine.
Any advice would be appreciated!
Thanks,
Mike
.
- Prev by Date: Re: RDP Causes Blue Screen in Vista
- Next by Date: Re: win32admin.dll
- Previous by thread: Re: unc path issue
- Next by thread: "Start program on connection": It isn't centered
- Index(es):
Relevant Pages
|
|
