Master High‑Performance Backend with Linux Sockets, epoll, and OpenResty

This guide explains how Linux socket I/O multiplexing (select, poll, epoll) powers high‑concurrency servers, why caching and asynchronous non‑blocking are crucial, and provides step‑by‑step instructions to install, configure, and develop with OpenResty, Nginx, and Lua for scalable backend applications.

Efficient Ops
Efficient Ops
Efficient Ops
Master High‑Performance Backend with Linux Sockets, epoll, and OpenResty

Socket

In Linux socket programming, handling massive connection requests requires non‑blocking I/O and multiplexing. The Linux APIs select, poll, and epoll provide I/O multiplexing; since epoll was added in Linux 2.6, high‑performance servers widely adopt it, e.g., Nginx uses epoll for high‑concurrency I/O.

For high‑performance backends, the focus is not language speed but caching and asynchronous non‑blocking support.

Cache hierarchy (fastest to slowest): memory > SSD > mechanical disk; local machine > network; intra‑process > inter‑process.

The goal of a cache system is to achieve the highest hit rate inside a process, maximizing overall efficiency.

Asynchronous non‑blocking I/O means that when accessing databases, networks, or slow devices, the server does not waste time waiting; instead, it uses event‑driven notifications so CPU cycles can serve other client connections.

OpenResty

OpenResty is a high‑performance web platform built on Nginx and Lua, integrating a rich Lua library, third‑party modules, and dependencies. It enables rapid development of highly concurrent, highly extensible dynamic web applications, services, and gateways, allowing Lua scripts to call C and Lua modules and achieve 10K‑1000K single‑machine concurrent connections.

OpenResty essentially combines Nginx with LuaJIT, reshaping the development model for high‑performance servers.

Nginx uses a master‑worker model: a master process manages multiple worker processes. Workers handle events; the master only performs initialization and worker management. In OpenResty, each worker runs a separate Lua VM; each request is assigned to a worker, creating a coroutine with isolated global variables.

Lua coroutines resemble threads: each has its own stack, local variables, and instruction pointer, but they share global state. Unlike true multithreading, coroutines switch execution via code and only run one at a time, pausing only when explicitly yielded.

Benchmarks show OpenResty performance approaching or surpassing Nginx's C module.

OpenResty Architecture

Load Balancing LVS + HAProxy forward traffic to core Nginx instances, achieving load distribution.

Single‑Machine Closed Loop All required data can be retrieved from the local server, minimizing network calls.

Distributed Closed Loop Two main challenges arise: data inconsistency (e.g., lack of master‑slave architecture) and storage bottlenecks (disk or memory limits).

Data inconsistency – solve with master‑slave or distributed centralized storage.

Storage bottlenecks – shard data by business key across multiple servers.

Access Gateway The entry point that receives traffic and performs tasks such as routing, security checks, and load balancing.

OpenResty Environment Setup

Prerequisites: install perl, libpcre, libssl.

# Check required libraries
$ sudo ldconfig -v
# Install required libraries
$ sudo apt install libpcre3-dev libssl-dev perl make build-essential curl libreadline-dev libncurses5-dev

Download and extract OpenResty:

$ wget https://openresty.org/download/ngx_openresty-1.13.6.1.tar.gz
$ tar -zxvf ngx_openresty-1.13.6.1.tar.gz
$ mv openresty-1.13.6.1 openresty
$ cd openresty
$ ./configure

Compile and install:

$ sudo make && make install
$ cd /usr/local/openresty

Start Nginx:

$ sudo /usr/local/openresty/nginx/sbin/nginx
$ ps -ef | grep nginx
$ service nginx status

If port 80 is already in use:

$ sudo netstat -ntlp | grep 80
$ sudo killall -9 nginx

Edit Nginx configuration:

$ sudo vim /etc/nginx/conf/nginx.conf
listen 80;
listen [::]:80 ipv6only=on default_server;

Test with curl or a browser: $ curl 127.0.0.1 Add Nginx to the user’s PATH:

$ sudo vim ~/.bashrc
export PATH=$PATH:/usr/local/openresty/nginx/sbin
$ source ~/.bashrc
$ nginx -s reload

Example Lua handler using content_by_lua:

location /test {
  default_type text/html;
  content_by_lua 'ngx.say("hello openresty")';
}
# Reload Nginx
/usr/local/openresty/nginx/sbin/nginx -s reload
# Access http://127.0.0.1/test

Using an external Lua file with content_by_lua_file:

location /test {
  content_by_lua_file 'html/test.lua';
}
# html/test.lua
ngx.say("hello lua")
# Reload and test
$ sudo /usr/local/nginx/sbin/nginx -s reload
$ curl 127.0.0.1/test

Disable Lua code cache during development (note: this hurts performance):

server {
  lua_code_cache off;
  location /test {
    content_by_lua_file 'html/test.lua';
  }
}
$ sudo /usr/local/openresty/nginx/sbin/nginx -s reload

OpenResty Quick Start

Create a working directory separate from the installation directory:

$ mkdir -p ~/openresty/test/logs ~/openresty/test/conf
$ vim ~/openresty/test/conf/nginx.conf
# Set worker processes (CPU cores)
worker_processes 1;
# Error log path
error_log logs/error.log;
# Event settings
events {
    worker_connections 10224;
}
http {
    server {
        listen 8001;
        location / {
            default_type text/html;
            content_by_lua_block {
                ngx.say("hello world");
            }
        }
    }
}
$ nginx -p ~/openresty/test
$ curl 127.0.0.1:8001
# hello world

Adding a Lua script file:

location /test {
  content_by_lua_file "lua/test.lua";
}
$ cd .. && mkdir lua && cd lua
$ vim test.lua
local args = ngx.req.get_uri_args()
local salt = args.salt
if not salt then
  ngx.exit(ngx.HTTP_BAD_REQUEST)
end
local md5str = ngx.md5(ngx.time()..salt)
ngx.say(md5str)
$ sudo /usr/local/openresty/nginx/sbin/nginx -s reload
$ curl -i 127.0.0.1/test?salt=lua
# Returns MD5 hash

On Windows, view Nginx processes with:

tasklist /fi "imagename eq nginx.exe"
# ... list of processes ...
# To stop Nginx:
 taskkill /im nginx.exe /f
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

LinuxNginxLuaepollSocketOpenResty
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.