<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=1005900&amp;fmt=gif">

Insights

Your workload type can impact the performance of the Azure file services!

08th September 2023 by 
Jason Cross

Azure Files is a fully managed file sharing service that provides a familiar file sharing experience similar to Network File System (NFS) and Server Message Block (SMB) file shares. It offers secure, scalable, and highly available file shares accessible from anywhere, eliminating the need for deploying file servers to grant access to files. For a particular client, adopting this solution allowed them to reduce their server count by 400 VMs.

However, during simple application tests, the client noticed that the performance of Azure Files was significantly slower compared to their original on-premises file server solution. To investigate the cause of this poor performance, I delved into the matter and discovered the existence of additional IO types beyond standard read and write IOs. These are known as 'Other IO' requests, which are essential for supporting various file operations.

On a Windows server, it is possible to measure Other IO requests using Perfmon, specifically by examining the \Process\Other IO Operations metric. In the case of Azure Files, all IO requests, including Read, Writes, and Other IOs, are converted into API requests before being serviced by the Azure platform.

The performance issue stems from a combination of two factors: the high response times of the Other IO requests and the sheer volume of these requests. In the example I encountered, there were three Other IO requests for every single read or write request, resulting in a significant increase in response time for a single read request from 3ms to 55ms.

However, despite this performance challenge, it does not render Azure Files an inviable solution. There are two effective ways to address this issue:

  1. Tune the application to reduce the number of "Other IO" requests it generates.
  2. On Windows, incorporate a Virtual Hard Disk (VHD) and map it to the Azure File network location. This allows the local server to handle these requests with much faster response times, avoiding the need for the Azure platform to service them.

 JC Azure files 1

Both options can lead to significant improvements in Azure Files' performance, particularly if your workload involves a substantial number of metadata or "Other IO" requests compared to Read/Write IOs.

JC Azure files 2

If you have any questions regarding the performance of your Azure files, please do reach out and I will be happy to support. You can reach me at jasoncross@capacitas.co.uk