Our company network (which I believe is a windows domain run on server 2008) is painfully slow. A prime example of this is copying files over SMB - listings take minutes, and copying even modestly sized files takes even longer. When approached regarding the issue, the IT manager (who, in spite of whatever other merits he might have, is a very stubborn and not a very technical person) throws his hands up, becomes very defensive and gives excuses instead of listening and attempting to work out the root cause of the problem.

Now, recognizing that the human element of this problem will take some time and effort to solve, I am left not knowing quite how to technically rebut his excuses. In this instance, he claims that SMB is the problem, and that it is a "slow" protocol. Is there any evidence for this statement (I only have anecdotal counter evidence)? What is the best way to make headway in this argument?

  • What type of networking is in place? gigabit? 100megabit? Are you copying files across a LAN or a WAN/VPN? Do you have a Windows domain or a Windows workgroup? I've seen a Workgroup cause slowdowns like that. Can you FTP files faster than network share? SMB is typically regarded as a protocal that isn't very efficient over other protocols.
    – Nate
    Nov 16 '10 at 16:31
  • @Nate Bross - 100meg, LAN, domain.
    – Nate
    Nov 16 '10 at 16:32
  • 2
    All directory listings take minutes, or listings of directories containing thousands of files take minutes?
    – Skyhawk
    Nov 16 '10 at 16:36
  • @Miles Erickson - All listings can take minutes. Occasionally it'll be very brisk, but frequently trying to access network shares hangs explorer for minutes.
    – Nate
    Nov 16 '10 at 16:39
  • 3
    The IT manager is not very technical? Is it just me or does anyone else see a problem there ?
    – Alan B
    Mar 15 '12 at 10:23

SMB might well be slower than some other file sharing protocols, and it might well be faster than some others. But that's not the important part.

Instead of making that the question/argument, can you find a way to move on from that and ask whether SMB is as fast (or as slow!) as it is supposed to be. For example, can you transfer a file using FTP between the server and a workstation that suffers from the slowness and see a marked jump in performance?

The vendor might be able to point you to reviews for the hardware, with Windows installed, that talk about file server performance.

In my experience, SMB is more than "fast enough" on my network. We're running a 10Gb network between the servers and we're very happy with file server performance using SMB and we have measured good performance jumps on the same hardware depending on whether we use the 1Gb or 10Gb NIC. SMB isn't a problem for us.

I'd certainly be looking at other things on your network - is the infrastructure outdated, is it configured optimally (e.g. server network cards all configured correctly for latest drivers, working properly at the best possible speed), are things like DNS and so-on all configured properly, is there a lot of "junk" traffic on the network causing a slowdown, is the antivirus configured in an overly paranoid manner (I've seen this cause some shocking slowdowns).

There's a lot that can cause bad file server performance and very little of it is the protocol choice.

  • 4
    After talking with our sysadmin, he did a test where he took down the antivirus, and the speed was blazing. Good suggestion!
    – Nate
    Nov 16 '10 at 17:33
  • 2
    +1 for DNS. DNS misconfigurations that lead to timeouts will have a huge impact on performance. Nov 16 '10 at 17:48

Whilst there are faster protocols than SMB it's not by any means inherently slow.

It is however perhaps a little more susceptible to outside influences than other protocols, these being saturated servers, saturated segments etc.

If I were a gambling man I'd suspect that your network could do with either a redesign or some investment as many company's regular office networks haven't been upgraded to take into account the huge increase in internet and intranet traffic seen over recent years. Also there's a reasonable chance that the server/s may need replacing or rework to get the best from them.

Either way I wouldn't put too much emphasis on SMB being the direct culprit, it's more than likely to just the fall-guy for bad/old network and server kit.

  • 2
    +1 - The original SMB protocol (not SMBv2) sucks like a Hoover over high-latency links. With typical LAN latencies (single digit milliseconds or less) it does just fine. If the OP isn't tracking traffic and errors on switch ports this would be a good time to start. My gut says that a duplex mismatch is somewhere in this problem. Nov 16 '10 at 17:04
  • 1
    @evan, my gut says it's a seven-yearold single-disk dual-core 1GB server with a single 100Mb NIC ;)
    – Chopper3
    Nov 16 '10 at 17:07
  • Distinctly possible, though even a box like that shouldn't take minutes to return directory listings under most circumstances. Nov 16 '10 at 17:14
  • @evan, could be a corrupt file system I guess... @nate, could you test your network by sharing a directory on one machine browsing it from another?
    – Chopper3
    Nov 16 '10 at 17:22
  • It may be the port the server itself is plugged into. Watching that port's error rates (late collision errors being a great indicator of duplex mismatch) and testing other types of traffic to/from that server (the "WSTTCP" utility works well for measuring raw NIC / driver TCP throughput on Windows) are probably both goods idea. Basic perf monitoring on the affected server is also a good idea-- watching CPU, RAM, network, and I/O utilization. Nov 16 '10 at 17:44

It does have more overhead (for transfer) than things like NFS or FTP. File listing of large directories can take a while - some of this is due to SMB, some due to NTFS, some due to stupid things that the various versions of Explorer, and installed software, can do from the client end. Certain things like file-based databases (Access, PST files) should not be opened across slow (WAN) links because they don't deal well with latency.

Having said that, the operations that you describe shouldn't take a long time. Maybe the fileserver(s?) is/are underpowered. Maybe the company has some software as part of the standard install that slows things down. Maybe there's a misconfigured virus scanner. Maybe there's a virus. Maybe there's a WAN link you don't know about between you and the server.

  1. Is listing files faster if you do it from a command line instead of Explorer?
  2. How about copying?
  3. Ping the server in question from your desktop - what's the latency?
  4. Do a traceroute - how many hops are between you and the server?

Unfortunately Nate, we can't deal directly with PHBs. Your first line of defense here is actual metrics, as in, do comparisons between SMB transfer and NFS, for example.

Once you have actual numbers or statistics to back your arguments up, you won't need to deal with the human element as much. Statistics say "here is where the problem is, and here's the proof." That's your argument.

  • 1
    Well, that's what I'm asking - that are the statistics I need to be collecting? How do I go about collecting them?
    – Nate
    Nov 16 '10 at 16:34

Can you narrow it down at all? Does a server-to-server transfer on the same subnet have better results? How about transfer from one client to another (\\client\c$\\client\d$)?

You may find something as simple as duplex mismatch.


I know this is old, but a very important factor to take into consideration is disk I/O. If the disk write performance is incredibly slow due to software / motherboard RAID as opposed to a hardware-based RAID card with dedicated memory.

Network load is a factor, but the best thing to do as a sysadmin is look at Resource Monitor and inspect where the bottlenecks might be originating from - inspecting the Overview tab to show overall CPU, Network, Disk I/O, Memory, etc. From this vantage, you can see if there is a culprit process or set of processes eating away at Disk I/O, or a memory leak (SQLServer.exe - SBSMonitoring instance), etc. If there is a network process using a lot of bandwidth, check that process and inspect how many and what the hosts are that are tied to that process. It could be a lot of hack attempts to RDP in on 3389. I've seen that before as the case and our solution was to remove direct RDP access and shift end remote users to VPN in.

Hope this helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.