Poor performance when mounting Azure File Share on Linux VM

Question

I have experimented with Azure File Service as a form of network file system that can be mounted by several VMs simultaneously -- something that regular Azure virtual hard disks are not capable of. An Azure VHD can only be attached to a single VM at a time.

However, when mounting an Azure File share via the SMB protocol, I observe some really poor write performance.

The set up is as follows, I've started a Canonical:UbuntuServer:16.04-LTS:latest VM on a Standard_DS2 VM.

When the boot process completes I follow the official instructions to mount the Azure File Share via SMB.

sudo apt-get install cifs-utils
sudo mkdir -p /mnt/azure
sudo mount -t cifs //<storageaccount>.file.core.windows.net/<file-share-name> /mnt/azure/ -o vers=3.0,username=<storageaccount>,password=<base64-encoded>,dir_mode=0777,file_mode=0777,serverino

Then I run this simple write performance test:

time for i in $(seq 1 500); do echo "hello!" > /mnt/azure/hello.txt; done

real    0m20.673s
user    0m0.032s
sys     0m0.124s

As can be seen, it takes over 20 seconds to complete. As a comparison, running the same test on my local machine (with SSD drive), I see the following numbers:

time for i in $(seq 1 500); do echo "hello!" > hello.txt; done

real    0m0.031s
user    0m0.004s
sys     0m0.024s

That is is completes in about 30 milli seconds. So there is almost a performance penalty factor of 1000 when running against the Azure File Share.

Are such performance numbers to be expected or am I missing something?

Answer 1

Yes.

Bear in mind that although the local disk and Azure Files are fundamentally network storages, the later uses an I/O API instead of direct hardware access. The latency will be a lot higher. Said that let's try a simple math:

You are making 500 requests and each time it opens and closes a connection:

500 requests / 20.673.sec = 24.18 Req/sec

24.18 / 1000 = 0,02418s to complete each request, which is great.

If you need performance against small and/or a large number of files, then Azure File Storage is not for your use case. In theory, it can achieve 1000 IOPS and 60MB/sec.

Additionally, let's face it, SMB/CIFS is very slow dealing with small files.

Answer 2

I'm not sure this is the entirety of the problem, as that does seem like a big difference, but bear in mind:

1. Azure File Storage is standard storage, not premium, so it's all spinning disk, no SSD, it will always be slower than your SSD.
2. Your running across the network now, that adds some time as well. Different size VM's have different limits, a D2 is going to be limited to about 1.5Gb/s