VFP Client (file sharing) Limitation? 3

[wsjames]

Our [VFP 9.0 ] application runs within a company that operates 24/7. During normal work hours, well over 100 users interface with our app. The number of users decline during weekend and night hours; management/engineering/admin staff work normal hours. The application’s responsiveness comes to a screeching halt [seemingly] once a certain number of clients are running the application ???. The responsiveness of the application does not degrade over time, it literally ‘drops of a cliff’. The sudden responsiveness drop occurs during normal work hours.

We are able to back users out of the application by changing the value of a field within one of the app tables. As a number of users back-out, the app’s normal performance is again realized – not gradual; literally all of a sudden. I’ve not yet determined specific user count.

The application and data tables reside on a server. The tables are not large; all less than 1Meg in size, most are under 50K. All [tables] have less than 7K records. User’s are running XP and Windows 7/32 & 64 bit.

The application has been running for about 6 months. This problem started last week. There has been a constant [yet] slow increase in number of users.

 

[JRB-Bldr]

"The application has been running for about 6 months. This problem started last week."

There is a point to investigate extensively.

What occurred/changed last week?

Over and over we hear about things that used to work and now they don't and people wonder why.

The place to always start is what changed?
Sometimes it might seem totally disassociated, but the key to sudden changes in application behaviour generally comes from those changes.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

I agree with JRB: what changed?

It sounds like a bottleneck issue. Ask your network folks what changed as well. Is there a 10/100 hub or NIC that's suddenly throttled at 10? Did someone install a CPU or RAM intensive process on the file server? Did a network admin implement software shadowing on the shared disk?

Applications don't suddenly "go bad" like old sour cream in the back of the refrigerator. SOMETHING changed. Find it.

 

[wsjames]

Nothing on the application side changed. I am working with the IS (server/network) folk in hopes to find the cause. But, was not sure if VFP had a client limitation.

I very much appreciate your comments/instruction.

 

[Dan Freeman]

There are no physical limits on VFP as a client, on paper, not in number of users anyway.

The server (which has nothing to do with VFP) has limits. It can run out of memory, disk space, file handles, etc. The network also has limits.

It may be that in the last week you just hit one of your network's physical limits and your IS guys need to throw more juice at it. It happens. (They'll be ROCKSTARS all over the enterprise if they add more resources because suddenly *everything* will be faster!)

It may also be that they made a subtle change that SHOULDN'T have been noticed but really really was.

Good luck!

 

[TamarGranor]

Just one app-related thing to check. Since you didn't say, I assume the app is using VFP tables. But if you happen to be using SQL Server and you're on the free version, there are throttles.

Tamar

 

[JRB-Bldr]

What changed - "Nothing on the application side changed."

As I mentioned above, do not limit your investigation of "what changed" to only on the application side.

What changed ANYWHERE?

Generally when things worked and then stopped working, it is quite OFTEN not on the application side.

As suggested above changes could have occurred to your network, to your workstations, to your virus protection software, to your database backend (if you are not using VFP data tables), etc. and any number of those things COULD impact application operation.

Please broaden your check for "what changed" and let us know.

Good Luck,
JRB-Bldr

 

[wsjames]

Thanks again, for all the support. I will provide a response upon attaining root cause.

 

[MrDataGuy]

Clues to a possible answer:

“The responsiveness of the application does not degrade over time, it literally 'drops of a cliff'. “

“The sudden responsiveness drop occurs during normal work hours.”

“The application and data tables reside on a server”

Can I assume that the users are logged into this server via Citrix or something like it, e.g the local machines are not doing the processing, no copy of the exe resides on a local disk or even in local memory?

Might there be a limit to the # of concurrent users?

Can I also assume that the CPU on the server is at 100% (could you check that to see if it true. If the CPU is not 100% you know that the issue is most likely not with VFP but someplace else.)

Years ago (~1999) I saw what you are describing at a large client of the firm I was working at. They had a beefy app server (Well what was considered beefy in 1999 that is <smile>) anyhow every so often the CPU would spike to 100% and stay there for mins at a time, other times just for a few seconds. ~100 users would start going nuts! What the issue was, drum roll please……. was one form under the right situation (First Tue of the month, under a blue moon etc.) had no active controls, e.g. everything was read only , enabled = .f. etc. The text cursor was bouncing like mad from one control, textbox etc. trying to find a home and could not, hence the 100% CPU. Trouble was if one tried to do a STEP ON to trace the issue the cursor would be happy blinking in the trace code and therefore no issue to be found. A devil of an issue to track down. Solution was putting a 1 by 1 pixel textbox at screen location 10,000 x 10,000 cursor had a place to blink and be happy, and users were happy.

Point being yes look for what has changed but be aware sometimes the change is that a user starts running a report or using a screen that has not been used in months. E.g. new users ‘discovers’ an old function of the app and starts using it, not something ‘new’ but something old but not been used.


Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[Olaf Doschke]

To come back to your initial thought:

If there is a file sharing limit, it's at the server. VFP had a file limitation back in the DOS days, but there is no limit. If there would be, it would be a limit for each single user and so you would only expect single users to have a problem.

SMB protocol has a maximum number of file handles the file server can manage, SMB2 has highered that limit, but if you turned off SMB2 last week to solve oplock problems, that would perhaps cause you to have too less file handles available at the server side.

I've had an application with well over 200 concurrent users and never had that problem with SMB1 on Win2000 and later Win2003 servers, but of course tha application design and how many files are open at the same time plays a role. I tended towards cursors and kept tables closed as soon as I had queried my data.

There is a hotfix available to SMB2 that is not turning off SMB2, so you could solve both the oplock problem and have the better scalable active SMB2 protocol.

If you google for "number of concurrent open file handles" you find this has been raised for SMB2.

To see how many files are opened remotely on the server, an Admin can start the Management Console from the Control Panel and look into Shared Folders and see remotely opened Files. You can export a list from there.

In a case of the app slowing down check how many files are open, all files count, not only DBFs of your database.

There is a hotfix for SMB2 in regard to oplocks, if your server is 2008 or 2008 R2:

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

This would help if the system has SMB2 turned off due to the oplock problem and therefore has a lower limit of concurrent file shares. This could turn back the highered file handle limit and nevertheless prevent oplock problems.

Bye, Olaf.

 

[craigber]

I've seen performance issues with sharing the DBC. Moving it to local drives solved the problem.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[MrDataGuy]

I've seen performance issues with sharing the DBC"

That is reason #57 that I like making systems with free tables only.

I have worked with applications with and with out DBC IMO the Cons of using a DBC vastly outweight the Pros. But in the end it may come down to the same situation of "do you use Spaces or Tabs when indenting code?" While both work, my preference is of course the right one <wink>

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[GriffMG]

I'll second that.

It is the same argument as Scan...EndScan and Do While.. EndDo, and possibly using a nicely hand crafted seek and a Select...

Me, I quite like dbc, but why? I have no idea!

But I really, really, like the native VFP files. I like them, as I do VFP itself - because I can create apps with no ongoing costs.

My customers like that too

Regards

Griff
Keep [Smile]ing

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

 

[MrDataGuy]

So back to the real issue.

wsjames, any closer to finding the real issue? I know I am wondering what the issue/solution is, it is like a murder mystery and I want to know the real killer's name. <grin>

Lion Crest Software Services
Anthony L. Testi
President

http://www.LionCrestSoftwareServices.com

 

[wsjames]

Finally!!!

The IS folk identified the 'Network Threat Protection' service was running even though Symantec Endpoint Protection (SEP). Apparently, the firewall protection was thottling the network traffic.

It seems SEP was inadvertantly enabled on our server - last week. Once the Network Threat Protection was removed, our performance issues disappeared.

Thank you again for all your support!

 

[Dan Freeman]

OUTSTANDING!

Watch for it again, though. That's exactly the sort of thing that Windows Update sometimes turns on without asking.