With the same 208 security rules enabled on one CPU core, OpenResty Edge sustains roughly 5,300 requests per second—3.7x ModSecurity for Nginx’s ~1,400, a gap that widens past 10x as requests grow more complex. The reason: rules are compiled into a single-pass scan instead of being interpreted one by one.

This article walks through the full WAF performance benchmark data, the compiler techniques behind it (regex rules merged into one DFA, global rule optimization via EdgeLang), and how to implement a WAF at the edge in four steps.

Request to try out OpenResty Edge

The Benchmark: 208 WAF Rules on One CPU Core

RPS benchmark of OpenResty Edge WAF vs ModSecurity for Nginx: throughput with 208 rules on one CPU core as URI arguments increase

Test setup:

  • 1 worker process, utilizing 1 CPU core
  • The same rule set of 208 WAF rules loaded and fully enabled on every system
  • Compared: OpenResty Edge WAF vs. ModSecurity for Nginx, with ModSecurity on Apache and lua-resty-waf on OpenResty also measured
  • Measured: requests per second (RPS, y-axis) as the number of URI arguments per request (URI Args, x-axis) increases—more arguments mean more request data for the WAF to inspect

ModSecurity for Nginx is the primary comparison here because it remains the de facto baseline for a self-hosted WAF on Nginx.

Results:

  • At 1 URI parameter: OpenResty Edge’s throughput (~5300 RPS) is already 3.7 times that of ModSecurity for Nginx (~1400 RPS).
  • At 20 parameters: ModSecurity’s performance degrades sharply—its throughput drops to roughly 150 RPS, with server resources exhausted.
  • At 100 parameters: Even under this extreme load, OpenResty Edge still maintains around 1500 RPS—a figure that surpasses ModSecurity’s performance even under its lightest load.

What this means in practice:

User experience: With equivalent hardware and all 208 rules enabled, you no longer have to compromise between security and speed—users get full WAF protection without a slow-loading site.

Cost: OpenResty Edge achieves with 1 CPU core the throughput that competitors need several, or even a dozen, cores to match. Handling more traffic with fewer cores directly reduces cluster size and monthly AWS/GCP/Azure spend.

Why Rule Count Doesn’t Have to Hurt WAF Performance

Traditional WAFs are constrained by static configuration files or inefficient scripts that evaluate rules sequentially: every added rule is another pass over the request data, so latency grows with the size of the rule set. The benchmark above shows the alternative—compiling the entire rule set ahead of time so that request data is scanned only once, regardless of how many rules are loaded.

Compiling Rules into Native Gateway Code with EdgeLang

OpenResty Edge introduces EdgeLang, our proprietary domain-specific language (DSL) designed for high-performance gateways. It is significantly more concise than manually written Lua code—and faster:

  • Optimized code generation: The EdgeLang compiler transforms your rules into highly optimized Lua code for execution on the gateway server. Leveraging algorithmic optimizations and sophisticated code generation strategies, it typically runs faster than hand-written Lua code.
  • Global rule optimization: Instead of executing rules sequentially, the compiler comprehensively integrates and optimizes all rules together, simplifying complex interactions across the whole rule set.

One Scan of the Request, No Matter How Many Rules

Two matching techniques decouple rule count from scanning cost:

  • Regex merging: The compiler consolidates all regular expression rules into a single, comprehensive Deterministic Finite Automaton (DFA). Regardless of the number of rules, the system scans request data once to identify all matching rules and their positions.
  • String trees: All constant string prefix and suffix patterns are combined into a unified, highly efficient tree-based data structure to accelerate lookups.

This is why the rule set’s scale no longer presents a performance bottleneck.

Extensibility Without a Performance Penalty

EdgeLang is not a siloed solution. It can directly call custom Lua modules and code, letting you reuse existing business logic, and it ships with an extensive suite of pre-compiled libraries covering common security protection, data processing, and network operations. You can orchestrate complex, business-aware security policies without giving back the performance the compiler earned.

Controlling WAF False Positives Without Disabling Rules

Addressing the pervasive industry challenge of WAF false positives, we offer a multi-tiered sensitivity adjustment mechanism, so operations teams can adapt to the current situation instead of turning rules off:

  • Security drill / penetration testing phase: Elevate sensitivity to strict mode, prioritizing security even if it means increased blocking.
  • Business peak period: Lower sensitivity to balanced mode, minimizing disruption to legitimate users.
  • Routine operations: Use standard mode, striking the balance between security and availability.

Adjusting sensitivity in real time minimizes the business impact of false positives. While not a perfect solution, it stands as the most practical strategy available today.

How to Implement a WAF at the Edge: Four Steps

Step 1: Establish a Global Security Foundation

Before configuring protection for specific applications, first establish a set of unified global WAF rules. This provides a foundational security baseline for all your services, capable of efficiently intercepting common, widespread attacks.

How to Set Global WAF Rules

Step 2: Enable Dedicated Protection for Core Applications

Once global rules are established, enable WAF functionality for your most important applications. Only after enabling it will the rules you set (whether global or application-specific) take effect. Enable WAF for Applications. For a full console walkthrough — from log-only trial run to blocking with a 403 — see the OpenResty Edge WAF tutorial.

Step 3: Whitelist Precisely to Prevent Business Disruption

After enabling WAF protection, legitimate business requests may sometimes be incorrectly blocked. To ensure business continuity, set up a whitelist to precisely exclude trusted requests from the blocking rules.

How to Set Application WAF Whitelist

Step 4: Write Custom Rules for Full Flexibility

For complex business scenarios or advanced security needs, standard WAF rules may not be flexible enough. With EdgeLang, you can write dynamic, fine-grained WAF rules based on any request parameter (Header, Cookie, URL, etc.), enabling highly customized protection logic.

Using Edgelang to Define WAF Rules

Following these steps gives you a defense system that is comprehensive (from global to local) and adaptable (from general to customized).

→ The WAF blocks application-layer attacks; against automated traffic, OpenResty Edge also ships a built-in CAPTCHA page, hCaptcha integration, and request rate limiting by custom keys — together they close the loop against bots and abusive clients.

CDN, WAF, and API Gateway in One: The Unified Architecture Advantage

Traditional architectures treat the WAF as an isolated perimeter appliance sitting between other boxes. OpenResty Edge instead builds a converged platform that integrates private CDN, WAF, and API gateway in one software stack, each layer doing what it does best:

  • CDN — the outer layer: Caches static resources close to users and, leveraging its distributed bandwidth, absorbs large-scale L3/L4 DDoS floods before they reach anything else. It is the WAF’s first line of defense.
  • WAF — the inspection layer: Positioned right after (or inside) the CDN nodes, it scrutinizes every request for threats—SQL injection, XSS, malicious cookies—regardless of which backend the request targets.
  • API gateway — the business layer: Authenticates requests (OAuth/JWT), routes them to the right microservice, and enforces per-user or per-API quotas.

Because all three layers run inside a single worker process, this architecture delivers two concrete wins:

  • No network hops between components: In a distributed setup, traffic bounces between CDN, WAF, and gateway devices, and every hop adds network I/O and latency. In the unified model, caching, security inspection, and routing complete within one worker process—the data never crosses a network boundary between layers, which matters most for latency-sensitive applications.
  • One platform to operate: Managing multiple heterogeneous systems means independent configuration, monitoring, upgrading, and troubleshooting for each. A unified stack means one platform covers the full lifecycle of edge traffic.

By building on this architecture, security stops being an external constraint bolted onto the delivery pipeline: rules compile to native code so protection logic never becomes the bottleneck, and security policies can be written with awareness of the business context they protect.

FAQ: WAF performance

How much does a WAF slow down a server?

It depends on how the WAF evaluates rules. Engines that interpret rules sequentially degrade as rule count and request complexity grow—in our benchmark, ModSecurity for Nginx fell from ~1400 RPS to ~150 RPS as URI parameters increased from 1 to 20. A compiled WAF that scans each request once, like OpenResty Edge, held ~1500 RPS even at 100 parameters with 208 rules enabled.

Does the number of WAF rules slow down requests?

With traditional sequential engines, yes—each rule is another pass over the request data. OpenResty Edge removes this coupling: the EdgeLang compiler merges all regex rules into a single DFA and all constant string patterns into one tree structure, so request data is scanned once regardless of how many rules are loaded.

How fast is OpenResty Edge compared to ModSecurity?

On identical hardware (1 CPU core, 208 rules enabled), OpenResty Edge sustained ~5300 RPS versus ModSecurity for Nginx’s ~1400 RPS—3.7x—in the simplest case. As request complexity grew, the gap widened past 10x: at 20 URI parameters ModSecurity approached 150 RPS, while OpenResty Edge still delivered ~1500 RPS at 100 parameters.

Why run a WAF at the edge instead of at the origin?

An edge WAF inspects traffic before it enters your origin infrastructure, so attacks are blocked close to where they originate and the origin never spends resources on malicious requests. In OpenResty Edge’s unified architecture, the CDN layer additionally absorbs volumetric L3/L4 DDoS floods first, and WAF inspection runs in the same worker process as caching and routing—no extra network hop for the security layer.

How do you reduce WAF false positives without disabling rules?

Two mechanisms work together in OpenResty Edge: multi-tiered sensitivity levels (strict for penetration-testing phases, balanced for business peaks, standard for routine operations) let you tune blocking aggressiveness in real time, and application-level whitelists precisely exclude trusted requests from blocking rules while keeping protection active for everything else.

What is OpenResty Edge

OpenResty Edge is our all-in-one gateway software for microservices and distributed traffic architectures. It combines traffic management, private CDN construction, API gateway, security, and more to help you easily build, manage, and protect modern applications. OpenResty Edge delivers industry-leading performance and scalability to meet the demanding needs of high concurrency, high load scenarios. It supports scheduling containerized application traffic such as K8s and manages massive domains, making it easy to meet the needs of large websites and complex applications.

→ The WAF is one layer of a unified gateway platform — read What Is OpenResty Edge for the complete picture, or jump straight to how OpenResty Edge differs from open-source OpenResty.

Request to try out OpenResty Edge

If you like this tutorial, please subscribe to this blog site and/or our YouTube channel. Thank you!

About The Author

Yichun Zhang (Github handle: agentzh), is the original creator of the OpenResty® open-source project and the CEO of OpenResty Inc..

Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty®, adopted by more than 40 million global website domains.

OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.

As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.