How expensive is creation of CloudStorageAccount or CloudBlobClient instances from the point of performance?

Question

Should I create CloudStorageAccount and CloudBlobClient instances every time I want to get blob from storage? For example, I implemented custom Virtual Path Provider for working with a blob storage. What is the best design solution: creation CloudStorageAccount and CloudBlobClient instances once as private fields of my custom Virtual Path Provider, or using of an utility with static (shared) methods that creates CloudStorageAccount and CloudBlobClient instances every time I want to get a blob from a storage? How expensive it from the point of performance?

Answer 1

You can reuse the CloudStorageAccount and CloudBlobClient since they hold no state (see Steve Marx's reply in Simon's link). The SDK is open source and you can simply look at the source on GitHub.

If you take a look at the CloudStorageAccount class you can see that its main purpose is to make sure you end up with StorageCredentials with a Blob/Queue and TableEndpoint. Looking at the constructor of the CloudBlobClient you can see that it stores the storage credentials, the endpoint Uri and some default values.

There isn't anything complicated here and there isn't any network I/O meaning the processing is very cheap. But when you think about performance every little optimization can help, so you could safely store it in a static variable (this might impact your unit testing) or if you use a IoC container you could choose to use a single instance for the whole container.

Now you need to take something into account. Both your CloudStorageAccount and your CloudBlobClient will save the storage credentials and the endpoint Uri. But what if you change this information through the portal (you maybe changed the key of your storage account)? If you store a single instance of the CloudStorageAccount/CloudBlobClient you might need to handle the RoleEnvironment.Changing event to 'refresh' these objects with the new storage account information.