_locking performance drop switching from Windows NT server to Windows 2000 server

I have a Window application written in c which makes various record locking requests to a database located on on a Windows server.   The code uses _locking calls to do this and has been extremely reliable for over many years of operation.   Recently some customers who have upgraded servers from Windows NT to Windows 2000 have seen extreme performance drops.  If these customers access the database on an Wndows NT server _locking times are fine.  If they access the database on a Window 2000 server the locking times are 10 times slower or worse.  I have been unable to reproduce the problems on my own Windows 2000 servers.  
XerxxerxAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

SunBowCommented:
I dunno. Three things to check on from prior experience with similar problems:

 • HW Specific.  This is more often the specific CPU and it's specific rate (MHz). Faster and slower CPU may not show same problem, while oftener, some products that suffer from speed increase will continue to do so

 • S/W Combination(s): The mix of S/W of user may impact. For example, how many windows open, what is in them, have they little virtual space left (compared to you).

 • S/W that's old: many old ones, especially of 16-bit flavor, can go goofy with increased CPU speed, go figure. See if they've got any of that

------------------------------

Things to do separately:

Have your application incorporate its own decoders, give it a booster shot (capability). Through use of periodic logs, looks at timing situations (selective) and a debugging type of switch or mode (not a normal mode), you can have it collect and report some relevant critical data. The idea would be to have the customer reporting problems, to turn on the option via a switch, (which will likely slow it down), then remove it from that mode after sending you the report.

Alternatively, the NT family already has a means to collect/record the goings on of its tasks. Ask for one. Not familiar with your application (although I get the idea, I think), I am not sure where to focus your attention. But check out anything MS itself can do for you to identify what tasks (plural) may be slowing it down.

Check out all tasks they run that are non-windows. Maybe one tinkers with timer(s).

Try tinkering with timer on your own.  One thing we tried once was running some fancy screen savers, that redraw on the screen constantly. Like the pipes.  See if running more than one of those puts a chink in your armor.

This one should not apply. We've found there to be a subtle but important difference between users viewing their files through an Explorer or MyComputer. On one occasion, a member of support found that by having the computer run a sound file, such as playing music from a CD, actually eliminated one of the problems. I do not remember well, but I think it was a 9x box, (but might have been NT) and one particular distinguishing factor was blue screening and the ability to replicate problem when building our own machine with same HW/SW setup. As I say, probably nothing there, but simple enough to test.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DanRollinsCommented:
I've never encountered this, but here's what I'd do:

1) Take a look at the source code for the _locking() function.  It is in the ...\CRT\SRC directory.

2) Debug single-strp through the locking code to see where the delay is.

I see that _locking() uses old DOS-level semantics whick implicitly assumes that the file to be locked is on the local computer.  It calls LockFile() Win32 API, but first does an lseek to get the file length, etc.  When the file is on a remote server, each such call is going to involve a complex RPC operation across the network... with various security issues and network latency issues in play.

3) I'd try writing code that did not use _locking(), but instead used the LockFile() API directly to see if that provided an improvement.

4) Examine the code used to Open the file.

5) Ask an Expert (done!) but also post the relevant code so the Expert can see the parameters you are using.

-- Dan
0
DanRollinsCommented:
Also:  
if lmode == _LK_LOCK || lmode == _LK_RLCK
Then _locking() sits in a loop that calls Sleep(1000) and retries 9 times.  During a Sleep(), no messages are being pumped and the APp will seem dead.

To most Windows users, waiting 9 seconds for *anything* will trigger a tech support call.

-- Dan
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.