VFP9 on W2008 R2 running slow

[kgordijn]

Hi Everyone,

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?

TIA,
Keith

 

[Nigel Gomm]

How large a program? If your executable is over 9mb look at PROGCACHE in the config.fpw file.

This may also help :

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

To the best of my knowledge oplocks should be switched off on all machines. SMB2 as well.

This is the hotfix i think you are referring to :

http://support.microsoft.com/kb/2028965/en-us

The file command? Are you passing a full filename with path; is the mapped win2008 drive the default drive? Or in the PATH?


hth

nigel

 

[Dan Freeman]

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?

 

[GriffMG]

Morning

File() is 'bad' function as someone pointed out above, and can give variable results - misleading ones.

I always use my own version below:

FUNCTION MYFILE
	PARAMETER m.FILENAME
	PRIVATE m.FILENAME,m.FLG
	m.FLG = .F.
	IF !EMPTY(m.FILENAME)
		IF ADIR(TMPDIRFILES,m.FILENAME) > 0
			m.FLG = .T.
		ENDIF
	ENDIF
	RETURN(m.FLG)

You pass it the filename, complete with full path and it returns .t. if the file exists, .f. if it doesn't.

Op locks are critical, and do slow things down, and are actually not easy to turn off now, but you can do it.

Regards

Griff
Keep [Smile]ing

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

 

[Mike Lewis]

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.

For more information about the above points, see Trouble-shooting a Visual FoxPro application. This also has a link to a user-friendly utility that simplifies the process.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Mike Lewis]

Regarding the FILE() function ....

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.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[GriffMG]

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

Regards

Griff
Keep [Smile]ing

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

 

[Mike Lewis]

Griff,

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?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[GriffMG]

No Mike,

technically speaking you are right and that is the behaviour the documentation tells you to expect... it's
just that users from (say) a VB background, or perhaps elsewhere, would expect that if you gave a fully defined path and
filename to something that is supposed to tell you if a file is there or not... they might well miss that it's going to
tell 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 releasing
major 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

Griff
Keep [Smile]ing

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

 

[Olaf Doschke]

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.

 

[DSummZZZ]

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.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm