I am looking at caching some of my responses that are slightly expensive to retrieve and are also common requests.
As part of my stack includes async/await calls my HttpResult Any(Request signature returned an async Task.
Should ToOptimizedResultUsingCache be constructed as follows as there is no overload which takes a Task of T?
public object Any(SearchBlocksRequest request)
{
var cacheKey = # Key based on the Request
return Request.ToOptimizedResultUsingCache(Cache, cacheKey, () => SearchBlocks(request).Result);
}
private async Task<HttpResult> SearchBlocks(SearchBlocksRequest request)
# Previous 'Any' before Cache
Or is there a piece which I am missing?
Thank you kindly.
Edit: Bonus question: if I get all my responses to return ToOptimizedResult can I disable dynamicCompression in IIS, or does IIS provide better performance for this?
The ICacheClient API and all Caching Providers only provide Sync API’s, if you’re using the default Memory Cache Client returning a Task only adds unnecessary overhead. Also if you haven’t already I’d recommend checking out the new HTTP Caching features added in the last release, e.g. the new CacheResponse Attribute provides a nicer and less invasive way to cache responses that you can use for async Service Responses that also has the ability to enable HTTP Client caching features.
ServiceStack’s caching solutions already compress responses so dynamicCompression wont add any benefit, I’d recommend disabling it as it forces buffering of the response which impacts features like Server Events.
Results are not expensive to retrieve from the cache (Redis in my case), I meant that my service operations were complex and could be cached until I manually expire them from an Event Stream.
Understood thank you for the clarification, in this case is task.Result the recommended way of integrating async service operations with ICacheClient?
I did look at the new Cache attributes in the latest release last night, but my cache key is more complex than can be derived at compile time, but this is a nice addition I can use in other services I operate, thank you.
I will bear in mind the dynamicCompression stance for the future - thank you.
If you’re caching I don’t see the need for async as having a cache is going to be a lot more efficient than using async, so I’d personally wouldn’t bother and just use normal sync calls. Otherwise I’d avoid calling task.Result if possible, if you need a custom cache key you can still use [CacheResponse] attribute and configure your Service to use a custom cache key.