我曾尝试将Azure文件服务作为networking文件系统的一种forms，可以同时由多个虚拟机进行安装 – 这是常规的Azure虚拟硬盘所不具备的function。 Azure VHD一次只能连接到一个虚拟机。
但是，通过SMB协议安装Azure文件共享时，我观察到一些非常差的写入性能。
设置如下，我已经在Standard_DS2虚拟机上启动了Canonical:UbuntuServer:16.04-LTS:latest虚拟机。
启动过程完成后，请按照官方说明通过SMB安装Azure文件共享。
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
然后我运行这个简单的写性能testing：
time for i in $(seq 1 500); do echo "hello!" > /mnt/azure/hello.txt; done real 0m20.673s user 0m0.032s sys 0m0.124s
可以看出，完成需要20多秒。 作为比较，在我的本地机器（使用SSD驱动器）上运行相同的testing，我看到以下数字：
time for i in $(seq 1 500); do echo "hello!" > hello.txt; done real 0m0.031s user 0m0.004s sys 0m0.024s
那是在30 毫秒左右完成。 因此，在针对Azure文件共享运行时，几乎有一个性能损失因子1000。
这样的performance数字是预期还是我错过了什么？
是。
请记住，尽pipe本地磁盘和Azure文件基本上是networking存储，但后者使用I / O API而不是直接硬件访问。 延迟会更高。 说，让我们试试一个简单的math：
您正在发出500个请求，每次打开并closures一个连接：
500个请求/ 20.673.sec = 24.18 Req / sec
24.18 / 1000 = 0.02418s来完成每个请求，这很好。
如果您需要针对小文件和/或大量文件的性能，则Azure文件存储不适合您的使用情况。 理论上，它可以达到1000 IOPS和60MB /秒。
另外，让我们面对它，SMB / CIFS处理小文件的速度非常慢。
我不确定这是什么问题，因为这看起来有很大的不同，但请记住：