Openresty Time Resolution With FFI – A More Accurate Approach

In looking for ways to further optimize my poorly-written Lua WAF (don’t worry, we’ll get there eventually), I’ve recently found that Openresty’s timing API is a bit lacking. Specifically, the time calls used within each transaction seems to only have millisecond granularity. This is fine for more complex applications which run over tens or hundreds of milliseconds, but in analyzing small sections of framework code, I wanted to have a more clear picture of how long each phase handler was taking (and the patronizingly PR-esque phrase “sub-millisecond processing time” was getting really annoying to hear in my head). A quick bounce to the Openresty mailing list got me on the right track:

Continue reading

OpenResty Performance – ngx.ctx vs ngx.shared.dict

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:

Continue reading

Efficient Bulk Search in High Level Languages

Certainly an oxymoronic subject, and not without justification- any decent high-level language developer will leverage existing libraries that have been designed for optimal performance (at least among the majority of use cases). Optimization and high performance in these environments often focuses on architectural and engineering disciplines, not a science of algorithm optimization and memory management. Certainly, any developer worth their weight should understand the basic concepts in computer science, but you’re not likely to find a vast array of efficient search algorithms implemented in Javascript or Ruby. Development platforms (and in turn, high-level languages) are built with the best possible performance in mind to enable developers to create and build without focusing on plumbing code. This does not, however, limit a language or environment’s ability to provide efficient methods of data management, nor should it preclude a developer from leveraging the most efficient (and safest, and sanest) solution possible.

Continue reading