MultiProcessing vs Multithreading: A Closer Look at Pingora's Approach 🚀

Pingora, Cloudflare's rewrite of Nginx, has sparked discussions lately for its open-source debut. They have had multiple reasons to move away from Nginx and build their own solution. One intriguing aspect of this shift is the deterioration of connection reusability in Nginx with more processes. Let's delve into the underlying cause:

To understand the issue better, we need to first understand how nginx works:

💎 Nginx employs multiple worker processes that share connections among themselves.
💎 Unlike threads, processes don't share memory with each other.
💎 This lack of memory sharing extends to the connection pool held by each worker process.
💎 Requests to downstream servers are distributed among different workers, necessitating new connections for each worker process.

Does connection reusability matter a lot?

💎 Enhanced connection reuse can significantly improve the Time-To-First-Byte (TTFB) by utilizing previously established connections from a connection pool, bypassing the need for TCP and TLS handshakes on new connections.

To address this issue, Cloudflare opted for multithreading over multiprocessing during the rewrite. Threads allow for memory sharing among threads, offering a potential solution to the connection reusability problem.

They have also had multiple other reasons to move away from Nginx and write one on their own, you can find all of them here: https://lnkd.in/gQB84ubH

P.S.: It's worth noting that Cloudflare chose Rust, one of my favourite languages, for this project. Rust for the win! Hurray.