Synopse Open Source

As Linus Said: It's All About Data Structures

After years of work on the asynchronous HTTP server in mORMot 2, I’m convinced that language choice is less decisive than people think — it’s the engineering decisions that matter.

This server regularly ranks near the top of TechEmpower (including #1 in cached ORM results in several rounds).

Here’s how we built it.

OS-Specific Networking: No One-Size-Fits-All

We deliberately use different strategies per platform:

• Linux: Straight epoll with edge-triggered notifications. Clean, mature, and extremely efficient for our event-driven model. I evaluated io_uring but concluded that for typical REST/JSON traffic over regular Ethernet, the added complexity wasn’t worth the marginal gains.
• Windows: IOCP with an asymmetric pattern. We receives normally via IOCP registration, but for small dynamic responses (the dominant case), we call plain send() directly on the socket instead of registering the write operation. Only large file transfers go through full overlapped I/O registration.
• BSD flavors (like MacOS or OpenBSD/FreeBSD): Regular poll API which gives good enough performance.

On those platforms, switching to an asynchronous pattern allowed serving thousands of concurrent connections from a few threads. This is the main benefit against our previous THttpServer class, which still shines behind a nginx proxy, for instance.

On Windows, the difference between http.sys and IOCP is significant. Microsoft has long promoted http.sys as the ultimate high-performance solution on Windows. It shines for static files thanks to kernel-mode caching and zero user-mode transitions. However, for dynamic content generated in userland (JSON, templated HTML, etc.), our raw IOCP implementation is faster in practice — my tests showed roughly 50% faster with IOCP than with http.sys for serving 4KB of JSON. Sometimes the general-purpose kernel abstraction adds more overhead than it saves.

For the TechEmpower benchmarks, we scaled by running multiple HTTP server instances inside the same process, spreading load across available cores, sharing as many memory as possible. Simple, but very effective. On modern hardware and OS, switching to a full asynchronous model in the code is sometimes not mandatory, and adds some overhead due to compiler magic - like an hidden state machine for no benefit.

Memory Discipline: The Real Secret Weapon

Modern performance is often limited by allocator pressure and cache misses more than raw CPU cycles.

In mormot.net.async we go to great lengths to avoid allocations on the hot path:

• A typical static GET request requires only one allocation — the URI string. All other buffers are static or reused.
• Response construction, header generation, and JSON serialization reuse pre-allocated structures aggressively - which is where the mormot.core.json library kernel shines.

We also rely on a highly tuned Radix Tree (compressed trie) for URI routing and parsing. It provides excellent lookup performance with low memory overhead and predictable cache behavior.

This allocation-avoidant design is one of the main reasons Pascal stays competitive: the language gives us excellent control over memory layout and lifetime without the usual safety/GC tax of higher-level languages.

Production Features Done Right

Performance without operability is useless. So we integrated several key capabilities with minimal impact on the critical path:

• IP threat mitigation via THttpAcceptBan — easy to load Spamhaus or custom CIDR blacklists
• Authentication — Basic, Digest, JWT and full enterprise-grade Kerberos via SSPI/GSSAPI
• Efficient logging with THttpLogger (Apache/Nginx compatible format, but designed for low overhead at high throughput)
• Global analytics & monitoring through THttpAnalyzer for consolidated response statistics e.g. per month/day/hour
• WebSockets ready via the mormot.net.ws.async unit.

And since mORMot 2 is used in several business-critical projects, we have immediate feedback from end users, in a vast variety of production environments.

Real-World Complexity: Progressive Caching

One unique feature set is our proxy/peer cache support.
When serving partially filled content (data still arriving from another backend connection), we use registered writes + a lightweight background thread to push new chunks as they become available. Once the resource is complete, we switch to the fast direct-send path.

This design prioritizes stable bandwidth sharing across concurrent clients rather than single-client peak throughput — exactly what you need in real cache/proxy scenarios.

Linux vs Windows: Facing the Facts

On identical hardware, the Linux version delivers more than twice more throughput for dynamic JSON workloads than the Windows IOCP version.
This is largely due to differences in kernel network stacks, scheduler behavior, and ecosystem tuning. Windows IOCP still performs very well (and beats nginx on the same OS), but the gap exists.

We accept this reality. In practice, Windows is more than fast enough for most deployments — especially when you value its authentication ecosystem or existing IT infrastructures. But Linux is the way to go if you want to leverage hardware and software to the next level of stability and production state.

Why Pascal Is Still in the Race in 2026

Modern Object Pascal (especially Free Pascal + mORMot 2) gives us a rare combination:

• Low-level control comparable to C/C++ (manual memory management, static buffers, direct OS API access)
• High-level productivity (clean syntax, powerful RTTI, excellent mORMot 2 standard library)
• Predictable performance without GC pauses or hidden costs

The result is a software solution that is fast where it counts, maintainable, and remarkably stable in production.
Your high-level service code could still be written with safe and clean high-level object pascal types (string, interface, generics, dynamic arrays, RTTI...) and let all the low-level plumbing be done at mORMot 2 level. A technical solution to consider for sure.

Closing Thoughts

TechEmpower is excellent for motivation and cross-framework comparison, but real success is measured in long-running production servers handling sustained traffic with monitoring, security, and reliability.
It is worth noting that the TFB challenge has been recently shut down, and their github repository archived since March 2026. They did not give any reason, but it may be because the main sponsor, Microsoft which gave the HW, was not able to reach the top level with C# as it is possible with our good old pascal code - only guessing, of course. It was a third-party benchmark, well known and with a lot of contenders, but only a micro-benchmark for sure.

Our mormot.net.async was built with production-ready-code in mind. It’s not trying to win every micro-benchmark — it’s trying to be an excellent, pragmatic choice for real REST services.

The code is open source. If you’re curious about high-performance networking, low-allocation design, or cross-platform systems programming in Pascal, I invite you to take a look.
As always, questions and contributions are always welcome on our forum.