NFS Tutorial :: Making it faster!!1!
NFS has several settings that can have an impact on the speed it provides.
Of course, the REAL improvements in speed will be made with faster networks, and crazy-fast servers with RAID-62 7th generation SSD's. But don't discount optimizing your NFS system in the settings alone.
What follows are the results of a small study done with various NFS settings. All tests done on 100MBs Ethernet systems. The numbers themselves don't mean anything, simply the fact that the numbers get bigger or smaller in a given test.
Sync vs. Async
Just like most filesystems, there is a distiction between synchronous mode and asynchronous mode. In the Synchronous mode, changes happen either all the way or not at all. No action can be taken until the change has been committed.
In the Asynchronous mode, the server can play fast and loose with files. Less care is taken to keep the filesystem in a consitent state. This reduced overhead can spell small perfomance gains if nothing goes wrong, and data loss if something does go wrong.
| MB/s | ||||
|---|---|---|---|---|
| rsize/wsize | async | sync | ||
| 1024 | 1.941 | 1.912 | ||
| 4096 | 2.996 | 2.768 | ||
| 8192 | 3.075 | 3.02 | ||
This is a small sample of some apples-apples settings, the only difference being async and sync. As you see, for any set of settings, async is slightly faster. This may or may not be reason to risk an inconsistent filesystem.
TCP vs. UDP
For some reason, NFS can use the connection-less protocol, UDP. The idea is that, with less overhead, it might be faster. Of course, all this did was shift the overhead to the application-level protocol. So lost packets still get detected and recent, and NFS reinvented some wheels.
UDP does result in faster file transfers in our tests, however these tests were done on a pretty nice packet-switched LAN, so dropped packets were less of a problem. If the network is lossy, may find that the overhead of the UDP+NFS_doing_TCPs_job will change the results some.
| MB/s (async) | ||||
|---|---|---|---|---|
| rsize/wsize | tcp | udp | ||
| 1024 | 1.941 | 1.955 | ||
| 4096 | 2.996 | 3.036 | ||
| 8192 | 3.075 | 3.28 | ||
So there you go, UDP is faster than TCP by a small margin. Again, if the network is lossy, this may or may not change the results.
rsize and wsize
NFS lets you specify the block size to send in the packets/frames for both reading (rsize)and writing (wsize). How awesome this may or may not be is well beyond the scope of this article.
Long story short, bigger is better. However, remember that packet size can be customized for this on your network. Also, you can have different sizes for both reading and writing. I don't know why. These numbers are in increments of 2^n.
| MB/s (async, UDP) | ||||
|---|---|---|---|---|
| rsize/wsize | speed | |||
| 1024 | 1.955 | |||
| 2048 | 2.339 | |||
| 4096 | 3.036 | |||
| 8192 | 3.28 | |||
The reduced overhead of packet headers may be the explanation here, as well as the ruduced packet reassembly.
Shits and Giggles, What about NFS Version 2
This article shows a difinite NFS Version 3 bias. Yes.
So what if we used NFS Version 2? Here's some stats:
| async, tcp, r/wsize 8192 | ||||
|---|---|---|---|---|
| version | MB/s | |||
| 3 | 3.075 | |||
| 2 | 2.3254 | |||
Break yourself.
