CODEWITHSUNDEEP
.netf#smbazure-files
OrdinaryOrange
OrdinaryOrange

Reputation: 2712

SMB transactions against Azure Files vs Billing transaction count

According to the Azure Files Pricing Page

Write transactions are any operations which modify a file’s data stream. This category also includes file handle operations.

and

Read transactions are any operations which read from a file’s data stream

As an experiment I mounted an Azure Fileshare to Z:\ on my Windows machine. And ran the below silly bit of code whilst sniffing the SMB transactions with Wireshark

let a = FileStream(@"z:\foo.txt", FileMode.Open)
let _buf = Array.zeroCreate(1)
[0..50000] |> Seq.iter (fun i ->
    let bte = a.Read(_buf, 0, 1)
    printf "%s" (Encoding.ASCII.GetString(_buf))
)
a.Close()

There are 7 SMB request-response pairs for the FileStream constructor call

In the example above 5 request-response pairs for the iteration (I assume there are only 5 because of SMB caching ?)

And 1 request-response for the Close()

From an Azure billing point of view how many transactions does the above constitute ?

Is it 1 (as I'm only operating on 1 file), 5 (as there are 5 SMB reads), or 13 (for each SMB action)

Upvotes: 1

Views: 474

Answers (1)

OrdinaryOrange
OrdinaryOrange

Reputation: 2712

After some more testing it looks like each SMB action (as logged by Wireshark) constitutes a billable transaction.

I ran a test on a ~33mb file and changed the code to do a single read of the entire length

let bte = a.Read(_buf, 0, int a.Length)

Wireshare captured 46 SMB events. In the Azure portal, under the service metrics 46 transactions were logged.

Repeating the test. This time only reading 1 byte at a time for the full 33mb file. Wireshark logged 218 SMB events and the same was reported in the portal.

I did a further test and uploaded a ~60mb file which produced 92 wireshark logs and 92 transaction in the portal.

After reading Understanding Azure Files Billing and this excellent article I discovered the logic.

Files are typically read/written by SMB in 1 mb chunks. For my ~33mb and ~60mb files where I uploaded/downloaded the full file, the number of transactions roughly corresponds to the number of 1 mb chunks in the file + the overhead transactions of opening and closing the file.

For the contrived example where 1 byte reads were performed by my code, SMB (in my tests) downloaded roughly ~160 bytes at a time from Azure Files and then buffered that to my code.

What does all this mean for a SO audience ?

If you are using the standard System.IO classes against a mounted Azure Files drive. Don't read and write in < 1 mb chunks if you want to be budget friendly.

In my case I'm developing a VFS cache over Azure Files with Dokan dotnet and I wanted to understand the cost ramifications of blindly pushing every local file delta to Azure.

Upvotes: 2

Related Questions