[Last Call] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 167
  • Last Modified:

_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.  
  • 2
2 Solutions
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.
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
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

Featured Post

[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now