In-memory cache
Cache slow-changing data between C# module endpoints to speed up response times and reduce calls to other services.
阅读时间1 分钟最后更新于 2 个月前
You need a fast response time when a client makes a server call. While calling other UGS services in Cloud Code is fast, each request adds latency. For information that doesn't change often, you can introduce a cache to speed up response times. For example, you can cache game configurations stored in Remote Config or Cloud Save.
When a C# module runs on a worker, the worker shares memory between module endpoints. You can create an in-memory cache (Microsoft) to use between these endpoints. This allows your code to load some information from another service, such as Remote Config, into the in-memory cache and use that cache for the next request. This means your code doesn't have to call out to Remote Config again until the cache expires.
Limitations
There are some caveats to using an in-memory cache:
- There's no guarantee that the module state persists between calls. The deployment of a module, a cold-start after inactivity, or routine maintenance can cause the module to load onto a different worker.
- Workers can reload for multiple reasons, so don't depend on the data and don't store data that needs to persist long term.
- Requests from the same user might go to different workers, so don't use in-memory caching to cache player data. This includes caching Remote Config with Game Overrides, unless the Game Override targets all players.
- A worker has a 256 MB memory limit, so the cache can't hold large amounts of data.