From my Azure web app service (ASP.NET MVC), I am serving up images via an anonymous controller method from Azure classic blob storage in two ways:
- one, as a redirect straight to the storage blob URI, and
- two, served up via a HttpClient fetch and then a FileContentResult from those retrieved bytes (advantage of hiding the storage URI).
Both controller methods involve several database select calls, but I'm using a P2-tier Azure database.
I'm still testing the performance differences between the two - obviously the second requires double the traffic overall: bytes from storage into web app, and then bytes from web app to client.
In both cases however, I'm seeing pretty unacceptable response times and errors from blob storage under load, using the Azure performance testing tool (250 concurrent simulated users over 5 mins).
When using the second approach (fetch on web app from storage and stream back) I'm getting lots of HTTP request errors when requesting from storage, so I have an instant retry mechanism (max 3 tries) to mitigate this. The end result is an avg response time of between 12 and 25 secs for an image, which isn't much good for displaying in an email these days.
Using the first approach (clean redirect to storage URI) this flies down to 3-6 secs on average in order to serve the redirect - but I have no control over whether the subsequent client redirect request to storage then fails (which it clearly must do - between 80% and 95% success rate according to the diagnostic logs). So I'm looking at a fourfold latency increase by 'guaranteeing' the image is definitely served to the client - which is effectively just as bad.
Is this an all-out stupid approach? I'm probably being quite the noob about all this. Surely there are architectures built on Azure storage that are far larger than mine and with fast response rates?
