In-memory read-through cache for PhysicalFileSystemCache

[Piedone]

I'm investigating some static file-serving performance issues for an Orchard Core app running on Azure App Services. It seems that storage IO is being throttled for the app by Azure, due to too many storage operations. ImageSharp's PhysicalFileSystemCache is a primary consumer of storage IO, so I'm looking into lowering that.

One option would be to use AzureBlobStorageImageCache (since the source images are already stored), and another one I thought about is having an in-memory caching (with IMemoryCache) implementation wrapping PhysicalFileSystemCache. So, files would still be stored on the file system, but reads (when done repeatedly) would come from memory.

This would help because we have plenty of available RAM, but a very narrow IO budget (with about max 500 operations per second available for everything, including running the OS).

Has anybody done this before? I didn't find any sign of this. Or am I overlooking some aspect of why this is a bad idea?

[Piedone]

Anybody with some input, perhaps?

[deanmarcussen]

@Piedone why don't you put a cdn in front of the web host for your images?

That's been my general go to for improving performance, and has generally been successful.

[deanmarcussen]

cool, the thing to keep in mind when exploring this (I see from the Orchard Core issue you have done a lot of testing), is to be aware that the image metadata for ImageSharp.Web can be read a lot during HEAD requests from CDN's.

I think from memory it has around 5minute volatile caching on it, but if you're outside the window then you're back to system io.

[Piedone]

Thanks for the pointer. I was actually wondering why we have a lot of IO still happening for supposedly cached files.

Now that I think about it, actually I should try AzureBlobStorageImageCache too, since that would make the image cache persistent, as opposed to starting anew with every deployment. That should alleviate the general IO bottleneck somewhat too.

[Piedone]

I'm testing it. In OC this would help BTW: #351

[deanmarcussen]

Now that I think about it, actually I should try AzureBlobStorageImageCache too, since that would make the image cache persistent, as opposed to starting a new with every deployment. That should alleviate the general IO bottleneck somewhat too.

This suggests you are using containers?

Yes, my experiance is you want to make the cache persistant, or the CDN / browser will constantly be regenerating cache because the timestamps of the cached files will constantly be changing on each deployment.

[Piedone]

Not containers but non-container Azure App Services, but we do clean deployments. In the end, the local file cache just lives until the next deployment. But this would also be an issue for containers too, good point, so I added this info to OrchardCMS/OrchardCore#15016, thank you.