VFP9 on W2008 R2 running slow

VFP9 on W2008 R2 running slow

VFP9 on W2008 R2 running slow

We have a large VFP9 app running on clients that are both W7 and XP with data stored on a W2008 R2 server. The tables in this app are all free tables.

Lately we have had reports of severe slowdown on about 10% of these configurations. I have turned off SMB2 and oplocks on the server which showed promise but things have slowed again.

In a coverage profile the slowness is related to the FILE() command from the client to the server and any fopen or fcreate commands.

A few questions:

1. do I need to turn off SMB2 on all W7 machines as well as the server?2. Do I need to turn off oplocks on all machines as well?3. There is some talk of a service pack and hotfix that has corrected SMB2 where it can be started and work ok, can anyone confirm this?4. Can anyone give me any other things to look at?

RE: VFP9 on W2008 R2 running slow

I'm not sure what workstation OPLOCKS or SMB might have to do with data stored on the server, but since you mentioned FILE() be aware it can have drastic overhead if any entry in the VFP search path includes a mapped drive that isn't currently mapped.

In some network configurations, drive mappings are "sort of" there, in that if you access them once then they're active. Otherwise, VFP sits waiting for the search on that resource to time out.

Are your FCREATE() etc. operating against the network drive as well? Is the network running out of file handles?

RE: VFP9 on W2008 R2 running slow

Regarding oplocks ... Yes, you need to disable it for all workstations (and servers). There's no point in doing it for some and not others. Also, you might need to disable it again if you apply a service pack, or even certain updates, to any of the workstations or servers.

Keep in mind that disabling oplocks can adversley affect performance of other applications. You should do it on a trial basis, and reverse it if necessary.

RE: VFP9 on W2008 R2 running slow

If you pass a plain filename (without a path), VFP will, at worst, have to search all the directories in the search path. If there are many of these, and if some or all of them are on the network, then the function will take longer than Griff's custom function.

However, Griff's function relies on you passing the fully-qualified filename (including the path). If you did that with the FILE() function, it should be just as fast.

Or is there some other reason that FILE() is a "bad function"? I'm not aware of any particular problem with it.

RE: VFP9 on W2008 R2 running slow

File() will ignore the path you supply if the file doesn't exist there and then go back and search throughit's own path and can find misleading positives, so if you ask for File("c:\apps\myproject\myfile.txt") and it's notthere - but there is a version in the current folder (say "c:\devfolder\myapp\myfile.txt") File() may well say itis there when it isn't.

Regards

GriffKeep ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

RE: VFP9 on W2008 R2 running slow

I agree with your description of what FILE() does, but I don't agree that this is bad behaviour. The spec says that FILE() will look in both the search path (as per SET PATH) and the default directory. If it finds the file in the default directory, then it is correct to report it as being found. I don't see why that should be a "misleading positive". Or am I missing something?

RE: VFP9 on W2008 R2 running slow

technically speaking you are right and that is the behaviour the documentation tells you to expect... it'sjust that users from (say) a VB background, or perhaps elsewhere, would expect that if you gave a fully defined path andfilename to something that is supposed to tell you if a file is there or not... they might well miss that it's going totell you it is, when it isn't.

It used to catch me out all the time - now I only use MyFile(), I even double check for File() sometimes before releasingmajor changes!

Also, my version of MyFile (not the one here) can return all the other file attributes (size, date, time etc.) which is pretty helpful from time to time.

Regards

GriffKeep ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

RE: VFP9 on W2008 R2 running slow

As the first thing: I have no positive feedback as of yet, the hotfixes would really fix the problem foxpro has with it. And I have no opportiunity to test on my own, as far as that would resemble real situations anyway, if you do it on one server with one client. It's a bit futile to test on a test setup.

One good news is: It seems the hotfixes are not needed anymore, once you do your windows updates, the SMB2 protocoll will have that fixes in the newest versions.

Still without any positive feedback on the changes to make foxpro dbf and cdx access stable, I'd still recommend truning oplocks off.

In regard of turning off oplocks, you first need to turn off SMB2. Turning it off at the server is sufficient. Clients can claim to want an oplock as often as they want, if the server doesn't support it the only overhead is the client request and it's denial.

Overall the oplock problem contributes to the performance of secondary users (who will break an oplock) and turning them off does not make all users experience the good performance a first user has with oplocks turned on.

The nature of File, as discussed by Griff and Mike, can contribute to long times for FILE() searches, but that and FOPEN/FCREATE performance unlikely has to do with oplocks. Especially with FCREATE you have write access, meaning exclusive access, and that means no oplock.

The common operation of finding files and creating files is addressing a destination share/folder and you may simply have problems with WINS or DNS or similar services, perhaps double IP adresses or anything else causing a bit of havoc in the location of source or destination for file read/write operations.

Bye, Olaf.

RE: VFP9 on W2008 R2 running slow

Quote:

Lately we have had reports of severe slowdown on about 10% of these configurations.

Have you narrowed down which 10%? Is it the W7's or the XP's or both?

As for the low-level functions like FOPEN(), FWRITE() and so on, those are bad performance hogs.I have an app where I query files on a networked computer using FOPEN(), FREAD() the FCLOSE(). The files are very small, maybe 300 bytes at most, and are constantly updated and overwritten by an app running on the host itself. There are up to 15 of those files on the host, and it takes anywhere from 30 seconds to 2 minutes to read the data on each of those files. The biggest time hog is the FOPEN() function.

That said, what are you doing that you need to use low-level file I/O? Maybe it would be better to try and come up with an alternative to that.