-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Caching
As caching is an essential technology in the development of high-performance web services, Service Stack has a number of different caching options available that each share the same common client interface (ICacheClient) for the following cache providers:
- Redis - A very fast key-value store that has non-volatile persistent storage and support for rich data structures such as lists and sets.
- Memcached - The tried and tested most widely used cache provider.
- In Memory Cache - Useful for single host web services and enabling unit tests to run without needing access to a cache server.
- Azure Cache Client - For using the Azure DataCache client when your application is hosted on Azure.
To configure which cache should be used, the particular client has to be registered in the IoC container:
container.Register<ICacheClient>(new MemoryCacheClient());
container.Register<IRedisClientsManager>(c => new PooledRedisClientManager("localhost:6379"));
container.Register<ICacheClient>(c => (ICacheClient)c.Resolve<IRedisClientsManager>().GetCacheClient());
container.Register<ICacheClient>(new MemcachedClientCache("127.0.0.0[:11211]"); //Add your Memcached hosts
container.Register<ICacheClient>(new AzureCacheClient("MyAppCache"); //Add your Azure CacheName if any
To cache a response you simply have to call ToOptimizedResultUsingCache
which is an extension method existing in ServiceStack.ServiceHost
.
In your service:
public class OrdersService : Service
{
public object Get(CachedOrders request)
{
var cacheKey = "unique_key_for_this_request";
return base.RequestContext.ToOptimizedResultUsingCache(base.Cache, cacheKey, () =>
{
//Delegate is executed if item doesn't exist in cache
//Any response DTO returned here will be cached automatically
});
}
}
Tip: There exists a class named UrnId which provides helper methods to create unique keys for an object.
ToOptimizedResultUsingCache
also has an overload which provides a parameter to set the timespan when the cache should be deleted (marked as expired). If now a client calls the same service method a second time and the cache expired, the provided delegate, which returns the response DTO, will be executed a second time.
var cacheKey = "some_unique_key";
//Cache should be deleted in 1h
var expireInTimespan = new TimeSpan(1, 0, 0);
return base.RequestContext.ToOptimizedResultUsingCache(this.CacheClient, cacheKey, expireInTimespan, ...)
If now for example an order gets updated and the order was cached before the update, the webservice will still return the same result, because the cache doesn't know that the order has been updated.
So there are two options:
- Use time based caching (and expire cache earlier)
- Cache on validility
When the cache is based on validility the caches are invalidated manually (e.g. when a user modified his profile, > clear his cache) which means you always get the latest version and you never need to hit the database again to rehydrate the cache if it hasn't changed, which will save resources.
So if the order gets updated, you should delete the cache manually:
public class CachedOrdersService : RestServiceBase<CachedOrders>
{
//Injected by the IoC container
public ICacheClient CacheClient { get; set; }
...
public override object OnPut(CachedOrders request)
{
//The order gets updated...
var cacheKey = "some_unique_key_for_order";
return base.RequestContext.RemoveFromCache(this.CacheClient, cacheKey);
}
}
If now the client calls the webservice to request the order, he'll get the latest version.
A live demo of the ICacheClient is available in The ServiceStack.Northwind's example project. Here are some requests to cached services:
Which are simply existing web services wrapped using ICacheClient that are contained in CachedServices.cs
- Why ServiceStack?
- Important role of DTOs
- What is a message based web service?
- Advantages of message based web services
- Why remote services should use separate DTOs
-
Getting Started
-
Designing APIs
-
Reference
-
Clients
-
Formats
-
View Engines 4. Razor & Markdown Razor
-
Hosts
-
Security
-
Advanced
- Configuration options
- Access HTTP specific features in services
- Logging
- Serialization/deserialization
- Request/response filters
- Filter attributes
- Concurrency Model
- Built-in profiling
- Form Hijacking Prevention
- Auto-Mapping
- HTTP Utils
- Dump Utils
- Virtual File System
- Config API
- Physical Project Structure
- Modularizing Services
- MVC Integration
- ServiceStack Integration
- Embedded Native Desktop Apps
- Auto Batched Requests
- Versioning
- Multitenancy
-
Caching
-
HTTP Caching 1. CacheResponse Attribute 2. Cache Aware Clients
-
Auto Query
-
AutoQuery Data 1. AutoQuery Memory 2. AutoQuery Service 3. AutoQuery DynamoDB
-
Server Events
-
Service Gateway
-
Encrypted Messaging
-
Plugins
-
Tests
-
ServiceStackVS
-
Other Languages
-
Amazon Web Services
-
Deployment
-
Install 3rd Party Products
-
Use Cases
-
Performance
-
Other Products
-
Future