Speed Issues

[AlastairP]

This may not quite be the right forum for this, however, maybe there are some solutions in VFP that could assist the situation

The server set up is as follows:
12 Gigs Ram
3 Gig CPU 8 cores (I think)
Raid 5
Windows Server 2008
Terminal Services
Microsoft Exchange Server

Our users use RDP to connect to the server from work stations. All software, files and programs are located on the server.
We usually have between 2-8 users at any one time, occasionally 10 - 12
The workstations just have basic OS, considered a dumb terminal
Most applications seam to work OK, there is some small lag from time to time.
However, my VFP application is slow

Now, I have made several improvements in the slowest portions of the application and I am sure there is plenty of room for improvement.
I will be undertaking this progressively over time

Careful examination of the problem seams to stem from slow disk read/write and server load
For instance, if a form takes 1 second to load on the development PC, this will take approx 10 seconds on the server

I have taken a copy of the database from the server, and run this on the development machine and the application is very fast

I have conducted speed tests by copying files from one place on the server to another and the speed seams to run about 2 m/b sec
If I copy similar bunch of files on my development PC, I get at least 10 x the speed

I have been discussing the issue with the outside contractor who maintains the system, and he has indicated that the terminal services and Microsoft exchange is probably slowing the whole system down.
He said the only way to improve the situation would be to update the hardware.

He is probably right in some respects, maybe a dedicated database server would improve things somewhat, however, our experience in the past with some outside contractors is that they could be
"Steering" the situation to suit their own goal. (Sell us more servers)

However, I am of the belief that possibly the HDD's may just be slow

Any pointers would be much appreciated

 

[Mike Lewis]

All software, files and programs are located on the server.

You will get a big speed improvement by moving your VFP executables (including any supporting runtimes, DLLs, help files and other related files) from the server to the client computers. The fact that you have seen slow loading of forms tends to support that view. A VFP program is constantly fetching bits of itself from its EXE file and other files, and if those files are on the server, this will slow down the entire operation.

maybe a dedicated database server would improve things somewhat

If he means switching from using DBFs files to a full back-end database like SQL Server, well, that could improve performance substantially, but it might require you to make extensive changes to the architecture (including the user interface) of your application to take advantage of it - with no certainty of success.

I would see to moving the executables first, before you embark on major changes in the database department.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JimmyTheFish]

If you're running the system as a remote desktop (which I'm assuming your reference to RDP implies) have you tried simply running the system directly on the server? Does this exhibit the same slow time to load forms? If not, it would point the finger at the RDP setup. However, I don't have any expreience of that, so can't really help further. Could it, perhaps, be something associated with the locking on the server?

 

[AlastairP]

Moving the program files to the workstations is not an option, due to using remote desktop exclusively to access the server.
Plus, I am still fine tuning the application and adding extra features daily, so having only one version to maintain at this stage is an advantage.

I will run some tests directly on the server next time we are loading it up.
What do you mean by "Locking" on the server?

 

[Mike Lewis]

Moving the program files to the workstations is not an option, due to using remote desktop exclusively to access the server.

That raises the question: Why are you using remote desktop? Surely, it would be more efficient to store and run the executables locally, and to just keep the data on a server?

Plus, I am still fine tuning the application and adding extra features daily, so having only one version to maintain at this stage is an advantage.

That's a valid point, but there are plenty of ways of having the application automatically update itself when you issue a new version. If yuo are really issuing updates daily, then it could be as simple as having the client computer download a fresh copy of the EXE file from a server each morning at startup.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JRB-Bldr]

Moving the program files to the workstations is not an option, due to using remote desktop exclusively to access the server.

In addition to Mike's question above about - Why?...

RDP merely opens a 'window' from the 'real' physical remote workstation into an 'in-house workstation' through which applications may be run.

These 'in-house workstations' may be physical or virtual, but they are Not 'seen' by RDP as the Server itself.
Instead they are 'seen' by RDP as individual workstations.

Each separate 'in-house workstation' is capable of hosting its own set of applications, just like a 'real' in-house workstation would be capable of doing.

Is the executable resident on these 'in-house workstations' (Not the Remote physical workstations)?

If not - why not?
That is where you would see speed improvement.

Additionally RDP is, all by itself, quite often SLOW in its execution of applications.
* Due to possible bandwidth limitations between the 'real' remote workstation and the 'in-house workstation'
* Due to 'in-house workstation' resource limitations.
* Etc.
And some individual users may experience more slowness than others when running RDP due to variations in the environments.

Good Luck,
JRB-Bldr

 

[Nigel Gomm]

Alistair,

try....

1. =SYS(602,0)

2.

http://fox.wikis.com/wc.dll?Wiki~OpportunisticLocking

(and lots of threads here on tek-tips)

3. sys(3050) and progcache may also be worth looking at.


hth

nigel

 

[Olaf Doschke]

In the first place it would really be good to sit in front of the physical machine (if they don't use a virtual server for the terminal server) and see how fast the app is there. If it's fast, it's obviously RDP or bandwith or network slowly serving clients with the desktop graphic. If the look is of no concern lowoering the colors can help with the graphics problem. But newer RDP versions don't transport desktop as graphic anyway, the send the gdiplus or direct draw 2d commands needed to redraw the desktop to clients, if clients support that. If you have a version mismatch of client and server RDP version, you get what both versions can support.

Bye, Olaf.

 

[AlastairP]

Thank you every one.

JRB - let me ask -

Currently the application and the database reside on the server in the C:\ drive in its own application folder
When I log into the server as admin, and look at the running services, there are multiple instances of the application running (One for each user running the application) and these are running within each users environment

If I left the database where it currently resides and move all the program files to each users private file structure, is that going to make an improvement?
I only ask, because as an experiment, I copied the executable file a number of times with different names, (All in the same location on the C:\ application folder), and got each user to use one of the versions to run the program
There was no noticeable improvement in speed when using separate versions of the program (but in the same location)

Before I go down the road of shifting the program files I think a little experiment may be helpful -
I will make a couple of small single form applications, one that access the main program data base, and another that has its own.
I will have the applications run a few simple tasks, and also have intensive operations that makes calls on the database(s)
Each of these operations will be timed and logged to file

I will then install these in various locations and run these apps under different load conditions to see how differently they behave and compare the log files

 

[Olaf Doschke]

The idea to copy the application to each user, is an idea not including terminal server at all. The bottleneck remains the connection from each client to the terminal server, several users running at the same time also reduce that bandwidth for each user. This can still make sense, eg if you have big advantages having the application and data on that TS. The application running on the TS Server itself may be fast, only the remote part may be slow. And you won't find tat out by logging in to that server via RDP yourself. Even, if you work alone, you only will find out the speed, if the bandwidth isn't shared.

You kind of know the speed that you would expect, if you used the server directly, it's most probably the same as on your dev computer, unless the server really is having old drives, not even raid or ssd and your dev machine is having that.

12GB are already fine, as each user may at max use 2GB and most probably need less, I still assume the speed issue only is a thing about the bandwith between users client computers and TS server.

Bye, Olaf.

 

[Mike Lewis]

If I left the database where it currently resides and move all the program files to each users private file structure, is that going to make an improvement?

It depends what you mean by "private file structures". If you mean the user's "home directory" (or whatever you want to call it) on the server's hard drive, then it won't make any difference at all, because it doesn't reduce the load on the server, and it doesn't reduce network traffic.

But, if by "private file structures" you mean the hard drive physically installed on the user's computer, then that is exactly what I have been suggesting. You should definitely try that, before going much further.

I will make a couple of small single form applications, one that access the main program data base, and another that has its own. I will have the applications run a few simple tasks, and also have intensive operations that makes calls on the database(s)

I don't think you'll learn much from a single-form application. As I mentioned earlier, a VFP application needs to fetch bits of the executable each time it opens a form, runs a report, or references most other components of the program. Your test really needs to intensively open and close lots of forms, etc. if it is to tell you anything. That's more important than intensive database calls, as far as this discussion is concerned.

I can't see why there should be any difficulty in setting up a single workstation with a copy of your executable (and supporting files), keeping the database where it is at presenet, and seeing whether that solves the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AlastairP]

Hi Mike, That's a better idea
I will try that

Alastair

 

[JRB-Bldr]

Let me begin by saying that I am more familiar with using RDP to access either physical in-house workstations or virtual in-house workstations - not specifically using a Terminal Services.
And, as such, I have seen a noticeable difference in VFP application performance when the application itself is resident locally on the in-house workstation.

Currently the application and the database reside on the server in the C:\ drive

OK, but how do your user's in-house workstations 'see' the Server (i.e. as seen from within each user's environment)?
Regardless of where things physically 'live', does the Server appear as a mapped (non-C drive from each user's environment (what I am calling their 'in-house workstation')?

In other words, does each user's environment have its own C: drive and everything else, no matter where it physically 'lives' is on another drive?

If so, then I am suggesting that you install the VFP application on each individual's user's environment C: drive.
Or you can put an Application Launcher (faq184-4492) which will ensure that the most recent version of the application is resident on the individual user's environment C: drive.

Now, obviously, in order for the application to access data on the Server when its location is 'seen' as no longer the same as the application itself, then the application needs to 'know' where to find the data (i.e. code modifications may need to occur).

Good Luck,
JRB-Bldr

 

[wtotten]

I have quite a bit of experience with this. If it works fine with a couple of users and gets really slow as you add more users, it's a bandwidth or Terminal Server configuration issue. However, you said it is slow even with a couple of users so I don't think this is the problem.

As well, a RAID5 is a dog-slow RAID and if you are using something like 7200 RPM drives AND this server is doing other work besides just providing Remote Desktop services for this applications, then you have an under-powered server. You listed Exchange. If that's running on this same server, it's too much. You need to get Exchange on its own box.

FoxPro applications that use native FoxPro files (instead of a backend server) are by nature disk intensive. When you have a RAID5 system, which is 9essentially) the slowest RAID setup, and you add Exchange and the server OS, and who knows what else and you are asking for the disk subsystem to do too much. get a server expert to use the Monitoring tools and see if that's the case. You can see if it's the hard disks, or the CPU, too many processes, and so on.

As for storing EXE file on the workstations, that's not applicable for a RDP session. Everything happens on the server.

That server, configured correctly, should be able to handle 25 Remote Desktop users WITHOUT Exchange. Also, you are storing the application (files, EXE, etc.) on the same volume as the operating system and that's a big mistake. You should ALWAYS have the application stored on a different volume. That way if the OS volume became damaged, you could still get to the application and vice-versa. It's also a major performance hit to put it all on the same volume.

As a percentage how much of the volume space is free?

If you have some funds to do it the right way, reply and I'll give you my suggestions. Get me the server specs (which processor, RAM, applications that run on it, OS, hard disk configuration, etc.). Tell me if there is room to add disks to the RAID controller and if the RAID controller can handle multiple RAID types on the same controller/channel. You can get me the model/part # of the controller and I can find out for you (possibly). If it's Dell server, get me the Service Tag number and I can see how it was originally configured.

This is really important too; make sure the application was installed in the proper mode - you don't simply install it or copy it to the server and then provide RDP users a shortcut to it. Here are the two methods to properly install an application that is to be shared on a RDP server.

1) Install Application on Remote Desktop Session Host tool under Programs in Control Panel. This tool will run a wizard to help install the application.

2) "Change user /install" (without the quotes) command at a command prompt. Install the application using its SETUP or INSTALL program (or similar).
After the installation is complete, you enter "change user /execute" (without the quotes) at the command prompt.

To determine the current install mode of your RD Session Host server, use this command: "change user /query" (without the quotes). If you find it is INSTALL mode, that would be a problem. Just type in "change user /execute" (without the quotes) and see if that helps.

You want to be an Administrator of course to do this.

Good luck.

Bill

 

[AlastairP]

Thanks Bill,

We decided to install another server and run terminal services and my application on the new server, exchange and everything else on the original server
The new server is a Dell server, with 15,000rpm HDD and 15gigs of ram. Not sure which version of Raid is running, but I will find out
We did a test run today with 10 users flogging a copy of the application while connected with RDP. It ran very well

I would like to move the application off the C:\ drive, but this will require some work to make this happen.

 

[wtotten]

Good for you! That's exactly what you needed to do. If it's running well, the RAID isn't important at this point. I use RAID10 for situations like this, but again, if it's running well, which I expect it is with a new server that has 15K RPM drives, and 15GB of RAM, and only 10-15 users, and only running TS and the app; there's no reason to rebuild everything to change the array to RAID10.

Even with double the amount of users I expect it will run well.

Your users will love you for doing this!

Bill