Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Sudden slow database access
Message
De
17/01/2015 16:51:53
 
 
À
17/01/2015 10:28:29
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows XP
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01613560
Message ID:
01613793
Vues:
51
>Hi All,
>
>Been continuing to test. Having a difficult time. Tests seem inconclusive due to multiple users, etc.
>
>Went back to this test:
>
>I am on the server. I see 3 users working in my app from their workstations.
>
>I have everyone exit my app.
>
>From the server, I can see all tables are closed. No users using my app.
>
>I am on the phone with one of my users.
>I have this ONE user (user1) log into my app.
>User1 performs a function that pulls a lot of records. Time to pull recs=15 seconds.
>I have them do this again.
>User1 performs a function that pulls a lot of records. Time to pull recs=15 seconds.
>I have user2 log into my app. They are not doing anything. Just sitting in my app doing nothing. The DBC would be open and several tables are open but user2 is doing nothing.
>User1 performs a function that pulls a lot of records. Time to pull recs=2 minutes.
>I have them do this again.
>User1 performs a function that pulls a lot of records. Time to pull recs=2 minutes.
>I have user2 exit my app. Now we are back to only 1 user (user1). I wait and ensure user2 has no open tables. The DBC is not open either. User2 is completely out.
>User1 performs a function that pulls a lot of records. Time to pull recs=2 minutes.
>I have the only user (user1) exit my app.
>I have user1 log into my app.
>User1 performs a function that pulls a lot of records. Time to pull recs=15 seconds.
>
>I feel confident the above can be repeated all day with the exact same results.
>
>Summary: As long as only 1 user has my app open everything is fast. If a 2nd user logs into my app, everything is slow.
>In addition, for user1 to see improvement after another user has logged in, user1 must exit and re-login to see the improvement.
>
>I should also mention, it is a bit harder to test but I have the new server installed and nothing seems to have changed. It is Server2008 R2 whereas the old server was XP.
>
>I should also mention, just in case it matters, when my app starts up, refresh is set to 0,0 so my app does not do any refreshing by itself.
>
>Hope this makes sense to someone.

I'm not sure if you've tried this but at any point did you reverse the test machines i.e.

Test 1:

- PC1 only (fast)
- PC1 + PC2 (slow)
- PC1 only (slow)
- PC1 logoff then logon (fast)

Then, Test 2:

- PC2 only
- PC2 + PC1
- PC2 only
- PC2 logoff then logon

The point is to see if the problem is specific to one PC or not (i.e. something else common to both).

***

Let's ignore the details for a moment and go back to the thread title. That says a lot, it implies a single event somewhere is the cause. Can you or the client think of ANYTHING that could possibly be related to IT that happened around that time?

The first source for this type of information should be the System and Application Event Logs on all computers. If you reasonably closely know the date/time things went wrong it won't take long to check them.

Anyone installing any new software on any computers? Any new computers or other hardware on the network (e.g. someone bringing their kid to work over the holidays, and letting them amuse themselves by plugging their virus-infected laptop into the company LAN)? Any new rogue wireless router/AP as a result of a Christmas present? BTW I hope your client isn't using a wireless LAN for your app (even for just one or a few machines).

Power outage or spike? I've seen them screw up routers and switches, requiring a power-off/power-on restart to reset them to normal performance. This includes small 4 or 5 port switches people may have installed under their desks to give more local ports.

Someone rolling over a network cable in a desk chair, or an office cleaner yanking one out of the wall by snagging it with a vacuum cleaner (then plugging the damaged cable back in)?

If it's an industrial or otherwise dirty environment, is equipment clogged with dust and is overheating? That could cause thermal throttling, intermittent operation or outright failure.

None of the above are products of my overactive imagination, I've seen them all over the years.

***

If you really, truly can't discover or think of any event that might have caused this, then as Walter suggests your next step is Process Monitor, WireShark etc. The trouble with that is in some cases, even if you see an obvious performance problem, the cause is not obvious. One way or another you usually still need to spend the effort to find the causing event.

Sometimes someone knows they did something that might have caused the problem, but they're afraid to speak up for fear of punishment. The more critical the IT system is, the more afraid they are. But because the IT system impairment is costing real money, that's exactly the wrong attitude. Basically, you want to solve the problem, ASAP; potential discipline is a separate (and later) issue.

If management supports it, one way to get around this impasse is to declare an amnesty. Something along the lines of:

- As you know, starting at around ( problem start date ) we have an ongoing IT system problem. So far we don't know the cause and we have been unable to resolve it.

- We are looking closely at possible hardware or software problems

- It's also possible it was caused by human factors such as ( examples above etc. )

- This is a serious problem that is impacting the business. Our focus is to fix the current problem and prevent a future occurrence. If you know of anything happening around ( problem start date ) that may have caused this problem or affected the IT system, we need to know. We understand that depending on exactly what happened you may fear repercussions. However, we also understand that accidents happen.

- If you know of anything that might have contributed to this problem, please let us know. If it turns out to be caused by human factors, the person(s) involved won't be punished. Instead we'll use this to improve our systems and prevent a future recurrence.
Regards. Al

"Violence is the last refuge of the incompetent." -- Isaac Asimov
"Never let your sense of morals prevent you from doing what is right." -- Isaac Asimov

Neither a despot, nor a doormat, be

Every app wants to be a database app when it grows up
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform