+1

I built a nginx+luajit RTB bidder that did 168k qps on 8 cores. It smashed the C eventlib version and of course it crushed the Java version. Golang came in a close second but at the time with 8 cores I had to do crazy things to get it to pin to CPU's since the golang thread scheduling didn't seem very scaleable beyond 4 cores.

168K/s? Did you actually decode the bid request (json) or just return no bid? That seems too good to be true.

I also would love to know details about this .. very impressive stats!

These bidding platforms typically don't provide you with JSON but with some headers or query parameters that are very quick to parse (especially for the native nginx code), so your Lua code can basically boil down to a few table lookups.

Uh, look up OpenRTB. Except for Doubleclick Adx almost all exchanges encode bid requests in JSON.

May be I got it the wrong. Are the time spent on the bid processing portion (CPU bounded) or the network messaging and connection handling portion (IO bounded)? When talking about eventlib and nginx, I assume the network messaging and connection handling are relevant. In that case 168K requests/sec doesn't sound too great.

This benchmark shows Ngix+Lua (openresty) is more than 5 times slower than the leading ones, which can do more than 6M requests/sec.

https://www.techempower.com/benchmarks/#section=data-r11&hw=...

The problem w/ engine's Lua support is that it doesn't go far enough. Apache's mod_lua allows you to create complete modules for Apache, with total access to Apache's API.