DonationCoder.com Software > Find And Run Robot

Slow performance on network shortcuts

(1/1)

pstoffel:
Using FARR at home, I can always count on its speed to give me what I want: it's a wonderfully reliable tool! At work however, it blocked sometimes for more than 20 seconds(!) while typing, making its use rather limited.

After an investigation with the unequalled Sysinternals Process Monitor, I could track the slow response to the following situations:

* shortcuts to files/folders on mapped network drives, but where the server itself changed name. When you open up the shortcut's properties, you just see something like "S:\shared\...", but when you look at the shortcut file itself, it contains a reference to the actual server, e.g. "\\jupiter". If that machine doesn't exist anymore (or is renamed to "\\fileserver"), you can get a delay of 20 seconds, even if it's a local LAN shortcut
* every shortcut results in disk access not just to the shortcut itself, but also to the file or folder it points to (together with all intermediate paths to that file/folder). If your shortcut points to a LAN file, you might get a delay of 0.5 seconds for each of those shortcuts. If your shortcut points to a file on the WAN, e.g. to a shared folder in another continent,... your luck has ended (couple of seconds delay).
The delay with network shortcuts was already mentioned in older threads (e.g. "Stalls for 3-4 sec" dating december 2005), but doesn't appear to be fixed yet. I resolved the slow performance with the following techniques:

* updated all shortcuts containing old server references
* excluded as much network shortcuts from the FARR search folders as I could (excluded 300 network shortcuts to different machines/logfiles/...), limiting FARR's use however
* replaced any remaining shortcuts to network tools with "cmd /c ...", making it a local reference starting the actual application
Now I'm finally back to responses under one second :Thmbsup:, but this work took quite some time, and limited FARR's use. I'll probably need to redo the analysis within a couple of months if I create too much network shortcuts again.

Wouldn't it be possible to just investigate the shortcut file (*.lnk) in the search path, rather than the file and/or path it actually points to? That would really be a major performance boost in a networked environment!

mouser:
Thank you for the thoughtful post.

Are you using version 2 of FARR?
FARR version 2 is not supposed to be trying to follow shortcuts for network links, which as you say cause this slowdown -- but it may be that you've found something that may be confusing FARR -- that the shortcut may look to FARR like its on a local drive while really being a network drive.  If you are using version 2, can I ask you to email me so we can stay in touch for testing when i try to fix this? ([email protected])

pstoffel:
Will do!

Navigation

[0] Message Index