Azure blob storage as a website images source

1
votes

In my web application (MVC5, hosted at Azure Websites) users can upload their profile images. These images are than displayed publicly on the website. As the website is hosted on Azure I decided to give Azure Storage a try.

I created a public container and I upload the the images there as block blobs. It allowed me to access the images by a public url like that:

https://accountname.blob.core.windows.net/photos/photo1.jpg

Moreover I could wrap it with a HTML img tag and serve the images to the browser directly from Azure.

The problem is that the images seem to load slowly. 100kb image loads even a couple seconds.

What can be the problem? Does Azure Storage block blob require some startup time? Is that even a correct approach?

1
.netasp.net-mvcazureazure-storageazure-storage-blobs
You might want to look instead at Azure CDN (azure.microsoft.com/en-us/services/cdn). It uses table storage at the back-end, but your load times should be quicker. – Brendan Green
@BrendanGreen Can you share a link where it says that CDN uses table storage at the back-end? – Gaurav Mantri
@GauravMantri maybe that was a bit broad, but I used the following azure.microsoft.com/en-us/documentation/articles/cdn-how-to-use. My statement may need to be modified to say that you can point an Azure CDN endpoint to a Table Storage account? – Brendan Green
@BrendanGreen AFAIK Azure CDN is not for table storage. Blob Storage, most certainly and it should speed up serving content. – Gaurav Mantri
@BrendanGreen - that's incorrect. CDN has nothing to do with table storage. It's an independent service fed from blobs. And CDN is a red-herring here, talking about blob response time. – David Makogon

1 Answers

0
votes

Azure Storage blobs require no "startup" time - it's a massive-scale storage-as-a-service provider. And each blob, stored in its own partition, is capable of moving data at upwards of 60MB/s (see here for scalability target details).

I can't speak to what your bottleneck point is, as we simply do not have enough data to figure that out. It could be related to your geographic location vs the Azure region's location. It could be DNS. Or many other things....

As far as whether it's a "correct" approach? Well... that's a matter of opinion, so I'll stay away from that topic.