Some time ago I wrote a comparison of lua-nginx-module’s per-request context table and per-worker shared memory dictionaries. Silly me- our examination of the usage of hitting ngx.ctx is pretty naive. Of course, constantly doing the magic lookup to get to the table will be expensive. What happens when we localize the table, do our work, and shove it back into the ngx API at the end of our handler?
|
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 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 |
-- FFI call to get microsecond timing precision ffi = require("ffi") ffi.cdef[[ typedef long time_t; typedef struct timeval { time_t tv_sec; time_t tv_usec; } timeval; int gettimeofday(struct timeval* t, void* tzp); ]] gettimeofday_struct = ffi.new("timeval") local function gettimeofday() ffi.C.gettimeofday(gettimeofday_struct, nil) return tonumber(gettimeofday_struct.tv_sec) * 1000000 + tonumber(gettimeofday_struct.tv_usec) end local start = gettimeofday() local _ for i = 1,1000000 do ngx.ctx.foo = "bar" _ = ngx.ctx.foo end local ctx_fin = gettimeofday() local stats = ngx.shared.stats local __ for i = 1,1000000 do stats:set("foo", 1) __ = stats:get("foo") end local shm_fin = gettimeofday() local ___ for i = 1,1000000 do ___ = 1 end local baseline_fin = gettimeofday() local ctx = ngx.ctx local ____ for i = 1,1000000 do ctx.bat = "baz" ____ = ctx.bat end ngx.ctx = ctx local ctx_local_fin = gettimeofday() ngx.say("ngx.ctx runtime: " .. ctx_fin - start) ngx.say("ngx.dict runtime: " .. shm_fin - ctx_fin) ngx.say("baseline runtime: " .. baseline_fin - shm_fin) ngx.say("local ctx runtime: " .. ctx_local_fin - baseline_fin) |
We’ve added in an extra test to localize the ctx table, iterate in the same fashion, and save the results back. (We’ve also updated the test to use higher-resolution timing). There is a negligible performance impact from making just two calls to ngx.ctx:
|
1 2 3 4 5 |
poprocks@soter:~$ curl localhost/ctx-test ngx.ctx runtime: 442302 ngx.dict runtime: 290930 baseline runtime: 367 local ctx runtime: 360 |
So we can see that the functionality provided by ngx.ctx (arbitrary table nesting, per-request lifetime) is worth the minimal overhead when properly implement.
While digging through this, I had an opportunity to poke agentzh about the language in the documentation regarding dangerous using of scoping ngx.ctx. He quickly updated the docs with a clear use case. This type of responsive attitude and clear communication is why the OpenResty project is, in my opinion, one of the most well-maintained FOSS projects today.
Thanks for the benchmark!
If you add require “resty.core” to the top of the file, you will see a significant boost in all numbers, and ctx runs even faster than the shared memory. Maybe you can add a third post with those numbers 😉
Good call! I will re-run this when I have some free time (perhaps this weekend).
Good news! I touched on the use of lua-resty-core wrt. this benchmark (and the surrounding concepts) in a separate post: https://www.cryptobells.com/resty-core-the-good-the-bad-and-the-jit-y/