Does NGINX Plus/OSS hold the unhashed cache key or uri metadata in memory?

Projects NGINX Commercial Products
, , ,
1

What I’m trying to do:

I am trying to create a module that shows the original urls of the cached content in nginx.

An example would be /media/image.jpg is requested repeatedly and cached by nginx proxy. And lets say we have an endpoint that when requested dumps all the uri metadata of the active cache like.

{md5: SG...A32, uri: "/media/image.jpg"}
{md5: DF...AB4, uri: "/media/image2.jpg"}

For my purposes the original unhashed cache key would also work which has the default definition of

proxy_cache_key $scheme$proxy_host$request_uri;

Now I have done a preliminary exploration of the nginx source code and suspect this is not held in memory at all in nginx oss. However, as the nginx plus does support wildcard purgers, I figure it must hold this information in memory somewhere to do a regex search for a wildcard purge.

Where I’m stuck:

I can not find any documentation for if nginx plus (given up on oss for now I think) holds that information in memory and how could one reach it inside a dynamically loaded module.

What I’ve already tried:

I have created a module that dumps the cache shared memory with these fields


{"zone":"mycache","md5":"c510b260709c96464511de161764e0aa","mem":84,"disk":342992,"uses":5,"expire":1745848168}

Note: disk size is also not held and I do a stat call from the module to the file.

I am aware this information is held on disk but it is too costly for my circumstance do read that much seperate files from the disk on production.

I also did gcore dump the nginx processes and tried to find the string I am looking for in memory for which I succeeded. However I believe (or at least could not figure out a way to prove otherwise) it is just stale non-yet-zeroed memory from the actual request proccesing.

1 Like
4

Heya! There are no significant code differences between NGINX OSS and Plus when it comes to features that are included in both. Caching is one of those features (with the exception of the cache purge, like you mentioned) but that ultimately does mean that as you correctly deduced from the source code, the cache keys are not held in memory by either NGINX OSS and Plus. The only real solution as of today is to scan the whole on-disk cache, which as you correctly said comes with significant performance drawbacks.