VPN and VFP

Microsoft Visual FoxPro - Programmer Exchange

Usenet
I've seen some, largely negative, references to this combination in 
these groups and am now being put in a position where I might have to 
use it.

My recollection is that it is said to be slow, and indeed the one 
test I've run in the new VPN environment is *much* slower than the 
previous pure terminal server environment.

The network boys are telling me that it's just the same as before, I 
still access a terminal server (although they are now a clustered 
group of load balanced machines), it's just the underlying link 
that's changed.  Doesn't sound right to me, and having trawled the 
net for a while with Auntie Google I haven't been able to find 
anything pertinent.

Can someone help me out here?

Regards
Mark
                                            
swdev2
There are two main bottlenecks for IO, you'll have to track it and tweak the
system.

1.  File I/O with database files.  In some instances with VPN, you really
are pulling that entire table and it's index file across the wire.
2.  Screen updates.  do you really need to sling 1024 x 768 in 24 million
colours with 'high def' ?
Usually the answer is NO, your users can live with lower colour depths -
even 1024 x 768 om 256 colours is sufficient for a remote user to 'USE' the
app.

VPN vs Terminal Server usage, for FILE I/O, is different.
VPN vs Terminal Server usage, for SCREEN I/O, is different.

What I've done in the past is to map out the functional areas on 'the
system' where file I/O will get bogged down, then optimize for LOW amount of
file i/o, low amout of SCREEN res.

Where I see the majority of 'stupid designs' is in:
1.  a VPN connection is made, the drive mapping or UNC is set up.
2.  user launches a VFP EXE AT that drive or UNC - so the runtimes and the
EXE and the datafiles AND the temp area are all at the VPN 'drive'.  All
that stuff must travel across the pipe to the local workstation.

Now, if the network boys put the Terminal Server instances across a VPN,
thats doubly stupid, IME.    did they do something like this? (enjoy my
ascii art)
physical location o files -> VPN -> Terminal Server -> VPN -> Client
Instance

At least get your network monkies to make a visual map for you for your VFP
application, so you can start to pinpoint bottlenecks and possible
application redesign.

This can become harder, unfortunately, if 'a change' has to have a VP or CIO
signoff, especially if the prior  'change' hosed your application
performance.
                                            
Mark
Hi William,

So it's possible to have a setup with VPN that does work well in this context?

I now have a network connection that sets up the VPN, and then I run mstsc (MS Terminal 
Server Client?) to run my session.  

It looks like the (ascii art version) of the setup is Company Network -> Terminal Server 
Host -> VPN to me via RDP.  So it *appears* that all the work is going on on the terminal 
server host which is within the company LAN.

It looks like the real use they're making of the VPN is to limit my machine here to just 
their connection, I can't run any other internet links whilst that VPN is active. It 
sucks but is at least standard corporate paranoid stupidity.  In slowing me down it will 
impact my billing to effectiveness ratio, but that's their concern really.

In fact it seems that it's running reasonably well.  Is there somewhere I can see the i/o 
parameters that have been set up?
                                            
swdev2
What you've described in yer ascii art is standard, ime/o.

They give you an address on the internet to 'link' into --
maybe it's the Internet(tm) that's slowing you down?

Try a traceroute from your comptuer to the corporate vpn address, without
being logged in to their vpn - see how many links are betwen you and them.

If it's more than 20 - well - hey - you will have some 'latency' issues.

THANKFULLY - it's not as if yer mapping a drive locally at your machine -
all is done with TS .

As to the limitation of what you can do - ya, sorry, that's a feature, not a
bug !!!

I'm fairly sure YOU can't see the I/O for the TS client back at the TS
server.

What WOULD be interesting, from a metrics standpoint, is to KNOW how many
users logged in to that TS , by day, for last week.  The IT department
should be able to generate a nice graph showing user count, I/O by hour.

150 users on a TS cloud is really gonna slow you down, btw.   All that
contention for 'local temp file processing' .

If they can put you specifically on a 'less used segment' of their TS
cluster, life would be good.
OR

DanF's mentioned VNC.   I've shipped remote workstations to my remote
clients with VNC, so that I can do things INSIDE their network - maybe you
should suggest the same thing, but instead of VNC, ship an old windows 2000
machine with Remote Desktop installed...

Hang In There !!!   I'm sure you've got a nice 'mix' with click/wait time
and how much longer it takes for development - it'll bite into their 'usable
hours' for your billable time.   A remote workstation inside of their LAN
MIGHT be faster - depending on how close/near/far it is to that Internet WAN
port.

Mondo Regards [Bill]

--
===================
William Sanders / EFG  VFP / mySql / MS-SQL
www.efgroup.net/vfpwebhosting
www.terrafox.net  www.viasqlserver.net

context?
(MS Terminal
Terminal Server
on the terminal
machine here to just
active. It
me down it will
can see the i/o
the
really
million
the
amount of
the
VFP