Performance issues with getting CDN url

[alindgren]

Cool project - it really bugged me having the images always load via a redirect. We came across this project a while ago and incorporated the basic functionality of getting the CDN Url by doing an HTTP HEAD request and caching it with RuntimeCache. I noticed that until the cache got built up, the pages would load very slowly because it was taking a long time to get the URL from the redirect. This was exacerbated, to be sure, by the fact that our blob storage was in a different region, but even after moving it, it remained slow. I'm just curious if you have run into this as a performance issue. My current workaround has been to return the original URL (e.g. /media/1234/file.jpg) if the CDN URL is not in the runtime cache, but then fire off a delegate to load the CDN URL into cache for the next time it is used. I am also considering using Redis for caching the redirects. Any thoughts appreciated!

Thanks,

Alex

[Jeavon]

Interesting, how many images do you think you are resolving per page? HEAD requests are light so it shouldn't slow up even on first requests much. I have done a fair bit of load testing with the package but of course once urls are resolved its fast, also we have a output cache layer on top.

I do have a Redis addon/version planned for the package to persist the urls and share between servers also.

[alindgren]

It seems like it can take half a second or more for the HEAD to return. Some pages might have 10 - 20 images, so it adds up... I'm hosting with UaaS and have moved my cache Blob storage to the same region. I'm using Azure App Insights, so I can see all the dependency calls. When the HEAD request works, it in turn makes up to 6 HTTP requests (5 for my Blob storage, and 1 to the Azure CDN). Those add up to maybe 300ms. So maybe the bottleneck is in the Azure Blob Cache plugin. My technique of only rendering the CDN URL if it is cache and adding it to cache via a delegate seems to work fairly well. I just wanted to see if you or others had run into similar performance times.

Thanks,

Alex

[Jeavon]

Sounds like a reasonable number per page, I guess that's adding up to a few seconds for the first user. I wonder why you're seeing 6 requests to blob storage, seems too many off the top of my head...If ImageProcessor has already cached its output and saved to Blob storage, I would think it would make only one call to blob storage and then one call to CDN...

I like your idea of sending off to resolve async but with output caching it's likely that the full url wouldn't make it into output cache.

[alindgren]

BTW, I'm still investigating my perf issues. Do you know how long the runtime cache lives for? Good point about output cache.

[Jeavon]

Runtime cache will live until the application pool restarts. FYI, I do have a currently private branch with optional Redis for persistence and sharing, it's all working for core functionality, I just haven't hooked up the dashboard controls yet but I will hopefully make this branch public in the next few days.

[JimBobSquarePants]

Hey @alindgren @Jeavon

I think this might interest you. I got a great PR on the AzureBlobCache plugin the other day that much improves the performance of the plugin. This should vastly reduce your overheads calls once I get the release out which I hope to do this week.

https://github.com/JimBobSquarePants/ImageProcessor/pull/431#issuecomment-232978269

[alindgren]

Awesome! Thanks for the update @JimBobSquarePants !