Link to home
Start Free TrialLog in
Avatar of Michael986
Michael986

asked on

Slow browsing of network folder

One of our departments (with 12 users, all running W7 Pro and patched with the latest updates)  have a DB application which opens a tif file related to the record they're using. For 2 of the users the file doesn't open - it just hangs. For the remainder, the file is opened instantaneously.

The folder that the tif files are stored in is on a network drive (on a W2K8 server), referenced by a mapped drive letter. There are about 30,000 tiff files in the folder.

If I copy a tif file to the desktop and open it from there, it opens straight away.

If I copy a tif file to another network location (ie where there are not a large number of files) it also opens straight away.

If I 'explore' the network folder holding the tif files, the explorer window takes a long time to populate, and the address bar at the top has the green 'progress' bar moving from left to right. Doing this on any of the other PCs, the explorer window populates within a couple of seconds

If I open a command prompt and run a 'dir', it will display a few files, then pause, then show a few more, then pause, then show more etc etc

I've updated the network drivers to the latest, but the 2 PCs are not the same make model, and there are other examples of both make/model in this department that do work OK.

Any ideas as to what might be causing this slow reading of the files?
Avatar of bbao
bbao
Flag of Australia image

> If I copy a tif file to another network location ... it also opens straight away

on the same file server or different one?
1] Exclude the DB from AntiVirus Scans
2] Check whether it is safe to exclude the TIFF location (Not clear if this is located inside DB or external in another share)
3] Is this a MS Access DB or SQL?
4] Use perhaps a test tool such as Lan Speed Test (Site link here) and see whether you have a different write & read result on these two workstations compared to others.
5] If different from others, check the port on your switch for issues if Layer 2, or check if they are on a completely different switch all together. You might need to reconfigure the port duplex on the switch, or move ports if its a "dumb" switch.
Avatar of Michael986
Michael986

ASKER

"on the same file server or different one?"

Same server

1] Exclude the DB from AntiVirus Scans
 2] Check whether it is safe to exclude the TIFF location (Not clear if this is located inside DB or external in another share)
 3] Is this a MS Access DB or SQL?


It's not the DB that's the issue - the problem occurs outside of the DB

4] Use perhaps a test tool such as Lan Speed Test (Site link here) and see whether you have a different write & read result on these two workstations compared to others.

At some point I might have to - but am hoping to get some ideas as to what might resolve the issue from other people's experience first.

5] If different from others, check the port on your switch for issues if Layer 2, or check if they are on a completely different switch all together. You might need to reconfigure the port duplex on the switch, or move ports if its a "dumb" switch.

They are all on the same switch. I've tried swapping the port between a 'working' and 'non-working' PC, changed the cabling etc. All points to a problem on the PCs themselves.
"on the same file server or different one?"

 Same server

1] Exclude the DB from AntiVirus Scans
  2] Check whether it is safe to exclude the TIFF location (Not clear if this is located inside DB or external in another share)
  3] Is this a MS Access DB or SQL?


 It's not the DB that's the issue - the problem occurs outside of the DB. And the AV settings are pushed out to all PCs from the server, so are the same on all of the PCs (ie the ones that work and the ones that don't)

4] Use perhaps a test tool such as Lan Speed Test (Site link here) and see whether you have a different write & read result on these two workstations compared to others.

 At some point I might have to - but am hoping to get some ideas as to what might resolve the issue from other people's experience first.

5] If different from others, check the port on your switch for issues if Layer 2, or check if they are on a completely different switch all together. You might need to reconfigure the port duplex on the switch, or move ports if its a "dumb" switch.

 They are all on the same switch. I've tried swapping the port between a 'working' and 'non-working' PC, changed the cabling etc. All points to a problem on the PCs themselves.
Point 4 was to see if there was a generic delay which could be noted on the systems.
Sometimes it is something as silly as an outdated NIC driver, or someone having disabled options on the NIC when playing around with the system to try and make it faster (Plenty of people try using optimizer tools if given the chance)

Have you tried to see if there would be a difference regardless with AV enabled or disabled just out of interest?
I have seen it before with Symantec where the policy on the client was not properly applying when digging through the event logs for Symantec.

other products could have a similar issue.

Another silly thing which I noticed is users being connected to Wireless & LAN same time, having the system using the slower path to connect to the shares rather than the wired solution.
Have tried disabling the (Trend) AV - no difference

There is no Wireless on these PCs - LAN only

Regarding NIC drivers, we have two completely different types of PC using different NICs. The problem occurs on both types of PC, but it also works OK for other users on both types of PC

I've tried logging the problem users onto different PCs, and they work OK - so it definitely seems to be something on the PCs. I'm wondering if it could be some sort of indexing setting - is there anything that might slow down the opening of a folder of 30,000 tiff files. The files are indexed as part of the server indexing, but as far as I'm aware, there aren't any local settings for indexing of network drives?
commonly, it is NOT a good practice to leave too many documents in a single folder on file sever as it may generally slow down the performance to access the contained files due to file system limit on hard disk, because the OS needs to seek and buffer more (likely non-continued for a busy file sever) sectors through the directory area for locating a file.

you may consider to distribute the files in the sub folders in a managed way such as by the first letter of file name, or document type, or department, or the author etc. depending on your business and users' actual activities.

however, back to the current issue rather suggesting for further changes, i would like to do the following tests.

1. after flushing DNS caches on the problem PC, ping the file server by IP (first) then name (second), and observe the difference in the delay for resolving the host name.

2. create a new sub-folder under the current folder holding more than 3K+ files, move a few files into the new folder, and try to access the files from the porblem PC. see any difference?
"Too many documents" - not sure I'd agree that 30,000 should be considered as "too many". And most PCs don't find it an issue - just these problem 2 or 3.

1. No difference in response.

2. Yes, it opens the files in the new folder fine, either by direct reference (ie start | run | entering the full path & filename) or browsing to the folder and double-clicking the file. The only issue here is the using the second method, it takes a few minutes to display the contents of the parent folder (ie where the 30k+ files are). Once into the new sub-folder, all is fine.
Just a curiosity. Is there a difference in speed browsing the share when viewing the files with thumbnails vs viewing just the content?

e.g. are users who have no issues viewing the contents with small to large icons, and other watching them as list/content/detail under the view options?

I am wondering if when browsing the different view option will be trying to read exif or metadata which under list would not be obtained. It could be that the user applied a setting to optimize all folder views for pictures or other.

I suggest that you try the below steps to fix this issue:

-Go to the parent folder, then click "Organize" (or right click).
-Click on "Properties",
-Then go to the "Customize" tab and under "Optimize this folder for:" set it to "General Items" and optionally check to apply to the subfolders.
-Click "Apply".
> I suggest that you try the below steps to fix this issue

wondering if this could actually help as the issue persists even the author doing manual DIR in a Command Prompt window. anyway, worth trying and keen to know the difference, too.
Changing the 'Optimize this folder for' setting has no affect - it's still painfully slow to display the contents of the folder. I've even tried restarting between changing the settings,

But as bbao pointed out - the fact that the issue shows itself at the command prompt does suggest it's not anything to do with the settings of a Windows folder.

Still at a loss as to what's causing the issue.
> not sure I'd agree that 30,000 should be considered as "too many".

the fact now tells you that 3K is already considered as "too many". :)
it's 30k, not 3k

But the fact that 10 out of 12 workstations that use this folder work OK tells me that 30k is NOT too many. What it does tell me is that something odd is happening on a couple of PCs.
that's a point showing something is different on the specific PC. let's check something sepcial.

1. does the PC have WebDAV enabled? also, is WebDAV enabled on the server?

2. what's the pathname does the client PC use to access the file server? via UNC (like \\servername\sharename\filename) or URL (http or file://server.name/sharename/filename)?
ASKER CERTIFIED SOLUTION
Avatar of Michael986
Michael986

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
No solution was found
if no solution is found, probably better delete this question as all the dicussions might be not relevant to the question itself.