Christmas came a few days early from the Kong family. The first release candidate of the Kong 2.0 release was pushed out yesterday. The biggest highlight of this release is the shiny new “hybrid mode” deployment, which provides a more formal separation of control plane (e.g., management of the Kong cluster) behavior from data plane (e.g., proxying user-facing traffic). I had some time to play with this and wanted to share a few extra thoughts beyond what’s in the release notes.
Most people don’t like flying, I think. No one likes standing in long lines or sitting around, but I don’t mind the extra free hours. It gives me a chance to hack around on fun things I normally wouldn’t have the time for. I’m on my way back home from San Francisco, so I took advantage of the time to start hacking around with building a simple RPC protocol in OpenResty. It’s been a good chance to work with binary data and exercise the Nginx stream module. Tossing some notes and snippets in here as an outlet; I’m hoping to have a more formal follow-up in a few weekends as life starts to settle back to normal.
str1 == str2
No, really, it’s that easy.
What’s a fast way to insert a large number of elements into a Lua table? What’s the fastest way? And what’s faster than that? There’s a lot of discussion and advice floating around regarding such a primitive topic, so it’s time to dig into some implementation details. We’ll look briefly at a few idiomatic approaches, and discuss the compilation, results, and drawbacks of each.
OpenResty’s biggest selling point is its performance. Embedding Lua allows for some pretty cool new features to pop into a simple Nginx proxy, and the synchronous but non-blocking paradigm introduced by hooking into the event loop (thanks, epoll!) is awesome, but the OpenResty stack as a whole really shines when everything is tied together under the umbrella of approaching, crossing, and then shattering C10k. Out of the box, Lua code embedded into any number of phase handlers runs at an impressive speed, and with the flick of a switch, we can really kick things into high gear.
In recent weeks I’ve found the need to configure and deploy a proper load balancing solution for an authoritative DNS cluster. Now for most solutions (up to a certain scale, and you’d know if you were there) a single-purpose authoritative DNS resolver doesn’t really need a balancing frontend; you can reasonably expect a decent-sized box running a modern kernel to handle several hundred thousand UDP packets per second, with a minimal amount of complimentary TCP traffic. Putting a frontend load balancing tier in front of an authoritative DNS cluster is really only necessary when either hardware redundancy or significant traffic shaping is a requirement, or the generation of authoritative data is expensive and needs to be horizontally scalable. I found myself needing to satisfy a few of these conditions, and have had a wonderful time playing and poking at a purpose-built FOSS DNS load balancing solution in dnsdist.
Perhaps one of the most powerful primatives that lua-nginx-module provides out of the box is a sane, simple wrapper for regular expression operations (via PCRE). String matching, replacing (and now splitting!) via regex allows for much greater flexibility in string processing than Lua’s native string library. Recently while cleaning up an OpenResty InfluxDB client I needed to do some simple string comparison. My knee-jerk reaction was to use a simple expression in
ngx.re.find, but I had a hunch that the overhead of using the PCRE lib would be a waste, and that native Lua pattern searches would be quicker. Time for a benchmark to figure out the most sane solution!
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?
January tends to be a pretty quiet month in the admin/operations world. Most people are still coming back from holiday, new yearly plans are being made, meetings are held, and the server monkeys… sit and watch the graphs scroll by. The rest of the world’s gradual return to work means the start of a seasonal upswing, but we’re still in a relatively low point, so that generally means a light workload. That extra free time has given me a chance to put in a good chunk of work towards FreeWAF, cleaning up code, adding new features, and interacting with a total stranger (score!). I’ve just tagged a new release, v0.4, which provides a handful of new features that were sorely missing:
One of the advantages of having a rotating graveyard schedule (two weeks of 10 PM shifts, followed by two months of normal living) is that quiet nights allow for copious amounts of time to muck around on the Internet. One topic that’s piqued my interest over the last few days is tarpitting. Purposefully delaying responses seems a little more interesting than strictly rate limiting; it’s a little more of a retaliatory attitude, without causing any damage at the other end of the connection. Most of the writing I’ve found related to the idea is focused on lower-layer implementation (e.g. the TARPIT iptables module) or SMTP, so I decided to roll my own for HTTP services.