Forum Discussion
IIS app pool in-memory cache miss
Hi,
Our IIS server runs on windows 2016 servers, recently we are experiencing frequent miss from in-memory cache, and instead of connecting to NCache which is our cache solution, it is sending request to database. After lots of debug we still could not identify the issue here. But as a best practice we are going to change some setting. But, one suggestion is to change max worker count from 4 to 1. Will that impact our performance? How much will it be effective to bring that value to 1 from 4, in terms of single worker cache miss issue occurrences?
1 Reply
yes—bringing the app pool’s Maximum Worker Processes from 4 → 1 can reduce your “in-memory cache miss” symptoms on that server, but it won’t fix misses caused by multiple servers or recycles. Performance-wise, most IIS/ASP.NET apps run best at 1 worker anyway; you usually won’t lose throughput because a single w3wp is multi-threaded and uses all cores. You might see a hit only if you were relying on web-garden to isolate GC or contention issues.
Why it helps
- With 4 worker processes (web garden), each process has its own MemoryCache. Requests hop between processes and see cold caches, then fall back to DB when NCache isn’t hit or the local cache is empty. Setting it to 1 removes that intra-server inconsistency.
What it won’t solve
- Multi-server farms: each machine still has its own in-proc cache. Without load balancer affinity, you’ll still see misses.
- App pool recycles: every recycle nukes the in-proc cache and causes a spike of DB traffic.
What I’d do
- Set Maximum Worker Processes = 1 on the app pool and restart the site.
- Make NCache the first read/write path. Use local in-proc cache only as an optional read-through front (or disable it entirely to avoid split-brain).
- Check for connectivity/timeouts to NCache that cause fallbacks to DB. Review client logs and increase retries/connection pool if needed.
- Stabilize the app pool: disable the “Regular Time Interval” recycle, schedule a single off-peak recycle, enable overlapped recycle + warm-up, and preload the app.
- If you’re in a farm, enable load balancer affinity (sticky sessions) or rely solely on NCache (no in-proc), otherwise each server will see different cache state.
- Add a cache stampede guard (single-flight/locking) so a miss doesn’t trigger parallel DB hits.
Rule of thumb
- For IIS on Windows Server 2016, 1 worker is the default and recommended unless you have a very specific reason for a web garden. It simplifies caching and usually improves consistency. Use horizontal scale (more servers) plus distributed cache (NCache) for throughput, not multiple workers per app pool.
