4 ms·
Hi, thanks for the link! I just tried this on EFS but it doesn't give the expected answer. The program uses NFS NULL calls. I'm guessing we haven't optimized th
by geertj 5y ago
Hi, thanks for the link! I just tried this on EFS but it doesn't give the expected answer. The program uses NFS NULL calls. I'm guessing we haven't optimized those yet given that they are typically only used at mount time, but we'll have a look to see what's going on.
One of the most common operations on NFS are OPEN and GETATTR. The following example measures the latency of OPEN (GETATTR would be similar):
$ python3 -m timeit -s 'import os' 'os.open("/efs/test.bin", os.O_CREAT|os.O_RDONLY)'
500 loops, best of 5: 554 usec per loop
Results will vary a bit depending on network routing and the region.
- mprovost 5y agoYes the NULL RPC does nothing and should give a baseline for measuring the round trip time. I'm surprised that it doesn't give the expected results. Your test case is going through the kernel, not sending raw RPCs across the wire. There are a lot of moving parts in the filesystem layer. I implemented direct RPC calls for other RPCs like GETATTR but only for NFS version 3, and EFS uses version 4. Unfortunately the design of version 4 is a disaster from a protocol perspective. The designers wanted to enable multiple operations in a single RPC, but that's not supported by SUNRPC. So to maintain backwards compatibility they only implemented 2 procedures, NULL and COMPOUND. Everything inside a COMPOUND RPC is opaque. Well it's possible to construct but not with the standard RPC toolchain, so I never got around to it.