Proxy cache key in Nginx - Time & Space Complexity
We want to understand how the time to find or store a cached response grows as more requests come in.
How does the proxy cache key affect the speed of caching operations?
Analyze the time complexity of this nginx proxy cache key configuration.
proxy_cache_key "$scheme://$host$request_uri";
proxy_cache my_cache;
proxy_cache_valid 200 10m;
proxy_pass http://backend;
This code sets the cache key to the full URL and uses it to store and retrieve cached responses.
Look at what repeats when handling many requests.
- Primary operation: Hashing the cache key and checking the corresponding cache entry.
- How many times: Once per incoming request.
As the number of cached items grows, finding the right cache entry takes constant work thanks to hashing.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 1 hash + check |
| 100 | About 1 hash + check |
| 1000 | About 1 hash + check |
Pattern observation: The number of operations stays roughly constant regardless of the number of cached items.
Time Complexity: O(1)
This means the time to find a cached response stays constant as the cache size grows.
[X] Wrong: "The cache lookup time grows linearly no matter what."
[OK] Correct: Nginx proxy cache hashes the key to compute a direct storage location (e.g., file path), enabling average O(1) lookups.
Understanding how cache keys affect lookup time helps you explain how caching impacts performance in real systems.
"What if the cache used a hash table for keys? How would the time complexity change?"
Practice
proxy_cache_key directive in nginx?Solution
Step 1: Understand the role of proxy_cache_key
Theproxy_cache_keytells nginx how to uniquely identify cached content by combining variables like scheme, host, and URI.Step 2: Differentiate from other cache settings
Other directives control cache size or expiration, butproxy_cache_keyspecifically defines the cache lookup key.Final Answer:
To define how nginx identifies and stores cached content -> Option AQuick Check:
proxy_cache_key = cache identifier [OK]
- Confusing cache key with cache size or expiration
- Thinking it enables SSL
- Assuming it controls cache storage location
Solution
Step 1: Check syntax for proxy_cache_key
The value must be a string, so it should be enclosed in double quotes if it contains special characters like ://.Step 2: Verify variable usage
Variables like$scheme,$host, and$request_urimust be concatenated properly inside quotes.Final Answer:
proxy_cache_key "$scheme://$host$request_uri"; -> Option DQuick Check:
Quotes needed for complex keys = proxy_cache_key "$scheme://$host$request_uri"; [OK]
- Omitting quotes around the key string
- Missing $ before variables
- Incorrect concatenation without quotes
proxy_cache_key "$scheme://$host$request_uri";
What will be the cache key for a request to
https://example.com/path/page?query=1?Solution
Step 1: Substitute variables with request values
$schemeis 'https',$hostis 'example.com', and$request_uriincludes path and query: '/path/page?query=1'.Step 2: Combine variables as per the key format
Joining them gives 'https://example.com/path/page?query=1'.Final Answer:
https://example.com/path/page?query=1 -> Option BQuick Check:
Variables combined exactly = https://example.com/path/page?query=1 [OK]
- Ignoring the query string in $request_uri
- Using http instead of https for scheme
- Leaving out the scheme or host
proxy_cache_key "$scheme://$host$uri"; but nginx caches different query strings as the same content. What is the likely cause?Solution
Step 1: Understand $uri vs $request_uri
$uricontains only the path (normalized), excluding the query string.$request_uriincludes the query.Step 2: Analyze the symptom
Different query strings yield the same $uri, hence same cache key, causing shared cache content.Final Answer:
You forgot to include $args in the cache key -> Option CQuick Check:
$uri excludes query; add $args [OK]
- Confusing cache key with cache size or expiration
- Thinking it enables SSL
- Assuming it controls cache storage location
Solution
Step 1: Understand the need for conditional cache key
We want to separate cache for mobile and desktop, so the key must include a variable indicating device type.Step 2: Use a map to set $is_mobile variable
nginx can usemapto set$is_mobileto 'mobile' or 'desktop' based on$http_user_agentmatching 'Mobile'. Including $is_mobile in cache key separates caches.Step 3: Evaluate options
proxy_cache_key "$scheme://$host$request_uri:$http_user_agent"; uses full user agent, which is too specific and causes cache fragmentation. proxy_cache_key "$scheme://$host$request_uri:$http_user_agent ~* Mobile"; is invalid syntax. proxy_cache_key "$scheme://$host$request_uri"; ignores device type. proxy_cache_key "$scheme://$host$request_uri:$is_mobile"; # where $is_mobile is set by map correctly uses $is_mobile set by map.Final Answer:
proxy_cache_key "$scheme://$host$request_uri:$is_mobile"; # where $is_mobile is set by map -> Option AQuick Check:
Use map variable for device type in cache key = proxy_cache_key "$scheme://$host$request_uri:$is_mobile"; # where $is_mobile is set by map [OK]
- Using full user agent causing too many cache entries
- Trying regex inside proxy_cache_key (invalid)
- Ignoring device type in cache key
Ready to prove it?
Pass the test and this pattern moves unknown
