The Nginx Lua module provides two structures for maintaining Lua-land data: per-request context tables, and shared memory zones. Each has its pros and cons; ngx.ctx can store arbitrarily complex Lua structures, and only live within a single transaction’s lifecycle. Conversely, shared dictionaries are capable of storing key/value pairs as Lua primitives (complex Lua structures must be serialized to be stored in a shared dictionary); the lifetime of a shared dictionary’s contents is the lifetime of the master nginx process (dictionary contents survive HUP signals). Additionally, the Lua module documentation notes that ngx.ctx performance is slow:
The ngx.ctx lookup requires relatively expensive metamethod calls and it is much slower than explicitly passing per-request data along by your own function arguments. So do not abuse this API for saving your own function arguments because it usually has quite some performance impact.
A similar note appears in the documentation under the ngx.var API call; no such note lives in the shared dictionary documentation. Given that shared dictionaries can be leveraged to store per-request data in a manner similar to the context table (for primitive values), I wanted to see if there is a noticeable difference between the two methods:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
-- lives in the content_by_lua phase handler of a given test location -- we'll test this by setting and getting values out of a ctx and a shm -- values don't matter, we only want to flex the implementation muscles of each structure ngx.update_time() local start = ngx.now() -- 1 million iterations seems to be about the limit before we hit gc issues (see http://bit.ly/1vqHQaR) local _ for i = 1,1000000 do ngx.ctx.foo = "bar" _ = ngx.ctx.foo end ngx.update_time() local ctx_fin = ngx.now() local stats = ngx.shared.stats local __ for i = 1,1000000 do stats:set("foo", 1) __ = stats:get("foo") end ngx.update_time() local shm_fin = ngx.now() local ___ for i = 1,1000000 do ___ = 1 end ngx.update_time() local var_fin = ngx.now() ngx.say("ngx.ctx runtime: " .. ctx_fin - start) ngx.say("ngx.dict runtime: " .. shm_fin - ctx_fin) ngx.say("baseline runtime: " .. var_fin - shm_fin) |
We setup a simple test harness to run through getting and setting data from each structure independently, and compare the timing results. We also run the same number of iterations of setting a primitive, as a baseline control. The results are acutely noticeable:
|
1 2 3 4 |
poprocks@box:~$ curl cryptobells.com/test ngx.ctx runtime: 0.70300006866455 ngx.dict runtime: 0.37899994850159 baseline runtime: 0.00099992752075195 |
So we can see an obvious performance advantage in using shared dictionaries over per-request context tables (30-50% in this environment, which, granted, not realistic, but it’s a start). So why bother keeping ngx.ctx API in the module? Even Cloudflare developers stopped using ngx.ctx, and noticed significant performance improvements. It would make more sense to store multi-phase data in a shared dictionary (and asynchronously remove cache elements if space is an issue), or leverage the resty LRU cache if serialization is a concern, rather than continue to use an expensive API method that seems largely geared towards convenience.
Update: I’ve re-examined the proper usage of ngx.ctx here.
One thought on “OpenResty Performance – ngx.ctx vs ngx.shared.dict”