Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Pete Sass
  Where is Pete Sass?
 Marathon, Ontario
 Canada
 Pete Sass
 To: cliff head
  Where is cliff head?
 
 United Kingdom
 cliff head
 Tags
Subject: RE: Performance Issue with multi User
Thread ID: 364542 Message ID: 365230 # Views: 55 # Ratings: 1
Version: Visual FoxPro 9 Category: Windows 7 and VFP
Date: Saturday, December 22, 2012 3:16:41 PM         
   


> All
>
> Wondering whether anyone can help.
>
> We have an application that is heavily used in a multiuser environment. Over the last 18 months or so, we have had a large number of performance related issues in the product but only when operating in a multi user environment.
>
> For example, if one user is has changed the data in one particular table and another, or multiple users try a process that accesses that table, the user can experience a significant time delay.
>
> It only appears to be an issue with Server 2008 and Windows 7 onwards. We have reviewed SMB versions, Anti Virus, different network card settings which we have seen a slight increase in some cases but not acceptable.
>
> Are there issues with VFP running with SMB in a multi user environment which may cause performance issues. The code in these areas has not changed for years but more recently has become a problem.
>
> Can anyone help....is there a environment related solution out there


Hi,

Just my 2 cents worth... lol

1. I do not think this is related to Windows 7 32-bit or 64-bit. I have read
some threads about poor speed performance under Windows 7, however I have several
larger multi-user apps out there with the VFP exe running on the client workstations
"in some case 80 to 85 users", and the VFP database residing on a Windows 2003 server
share with the VFP application EXE residing at each workstation.
I would be more suspect of Windows 2008 server. I am assuming as you mentioned you
have taken some copy speed tests from workstation to the server just to 100% prove
you do not have a flaky server NIC or some switch issue.

2. Being an older VFP application I would take a bit of time just to ensure you are
using optimized query expressions throughout the application. Chances are this
older application is just using native VFP tables and indexes and probably all the
data is coming down across your network to each workstation. So over time as your
tables grow in size more and more data has to come down across the network to each
workstation. So if you can imagine as an example an invoice header table with
a child detailed table. The invoice table has grown from 100 to 200 to 1000 to
5000 to 10000 to 20000 records and the details table has grown form 100 to 200 to 20000
to 40000 to 60000 records. In the above scenario you can start to see what will happen
across your network if 2, 3, 4, 8, 10 users are all accessing these tables at the same time!
This will kill your speed within the application as the network maybe the bottle neck
issue causing your speed issues.
I only mention this as maybe the speed issue is not related to your new equipment,
but table record sizes.

3. I know this maybe a bit of work, but maybe worth your time. Setup a secondary
share on your server and copy the VFP database, tables indexes, etc. over into this
share. Now go in and delete records out of your larger tables and pack them and
reindex. Now test this test database with several users performing the tasks that
you mention are very, very slow. If things are fast on the stripped down database,
but slow on the production version, you have now proved what is the root cause of your
speed issue.

4. One way to correct this kind of issue also requires some recoding work.
You do have to go into your application and ensure all the records are not coming
down to each workstation. As an example, you could in the case of say a large POS or
accounting system, setup a select statement in your forms so that maybe only the last
30 days of records comes down, not all the records. I had to to this in some larger
POS systems where the daily orders in a large multi-user restaurant environment
were in the 1,000 orders per day with details records exceeding 8,000 records per day.

5. I am assuming you are using Buffering -5 with SET MULTILOCKS ON? If not take
a look at this within your application. I am hoping you are not using tables with
no buffering and not using manual record locking processes.

6. You need to also spend some analysis time to actually pin-point what tables
are causing you the slow down. As an example, again with a parent to child relationship
in a typical order and detailed table scenario, you may find with a very large order
system you do a couple of things. Select again only the orders for the past 30 days
out of the master orders table and then select only the child records for one order
at a time to populate say a grid display for the one order on your form. You click a
command button to move to the next order and this fires off a select statement to only
bring down the detail records for this order. You would modify your code to use the
"Safe Select" method for Grid population.

7. Is the VFP application EXE on the server or deployed at each workstation?
This has not been confirmed by you as yet, but Paul brings up a good point with
his message to you.

8. Is Windows 2008 Forefront Security enabled on server and on Windows 7 wrokstations?
I have heard that this can cause great slow downs running Windows 7 and Windows 2008
if running. To test this out:
Workstation locally exclusion is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Forefront\Client Security\1.0\AM\Exclusions\Processes
add valor reg_dword = 0
X:\FoxApp\myfoxapp.exe (Where X:\ is the share on the network)
This does open up malware security risks, but you could try this one one workstation
to see if any differences in speeds.

The other point you have not mentioned is the number of users that generally are
concurrently using your VFP application?
One other question is the network infastructure? Simple with one switch or a large network
with several switches? I do ask these questions for a reason. I have gone into some
customers with a large slow network environment and on a centralized server installed a
secondary 1 GB NIC hard. Then split the feed via 2 server NIC cards across a couple
of switches to effective split the network throughput to different workstations in
different switch locations in a larger network scenario. Well it does not double the
speed - lol, but will improve speed in a larger and very busy network.

Pete "the IceMan", from the Great White North of Canada.
www.marathongriffincomputers.com
Home of the Canadian and US download for Chen's VFP C++ Compiler
http://www.marathongriffincomputers.com/VFP-C++-Compiler.html

ENTIRE THREAD

Performance Issue with multi User Posted by cliff head @ 12/17/2012 5:16:59 PM
RE: Performance Issue with multi User Posted by Tom Saddul @ 12/17/2012 5:43:23 PM
RE: Performance Issue with multi User Posted by Rick Hodgin @ 12/17/2012 6:26:06 PM
RE: Performance Issue with multi User Posted by Tom Saddul @ 12/18/2012 1:43:13 AM
RE: Performance Issue with multi User Posted by Victor Espina @ 12/17/2012 6:15:43 PM
RE: Performance Issue with multi User Posted by Paul Gibson @ 12/17/2012 6:17:32 PM
RE: Performance Issue with multi User Posted by Rick Hodgin @ 12/17/2012 6:19:40 PM
RE: Performance Issue with multi User Posted by Paul Gibson @ 12/17/2012 11:22:32 PM
RE: Performance Issue with multi User Posted by Aaron 300z @ 12/17/2012 9:58:08 PM
RE: Performance Issue with multi User Posted by David Mustakim @ 12/18/2012 2:27:24 AM
RE: Performance Issue with multi User Posted by Pete Sass @ 12/22/2012 3:16:41 PM