picohttpparser VS epoll-server

Yea, it is definitely a fake HTTP server which I acknowledge in the article [1]. However based on the size of the requests, and my observation of the number of packets per second being symmetrical at the network interface level, I didn't have a concern about doubled responses.

Skipping the parsing of the HTTP requests definitely gives a performance boost, but for this comparison both sides got the same boost, so I didn't mind being less strict. Seastar's HTTP parser was being finicky, so I chose the easy route and just removed it from the equation.

For reference though, in my previous post[2] libreactor was able to hit 1.2M req/s while fully parsing the HTTP requests using picohttpparser[3]. But that is still a very simple and highly optimized implementation. From what I recall when I played with disabling HTTP parsing in libreactor I got a performance boost of about 5%.

1. https://talawah.io/blog/linux-kernel-vs-dpdk-http-performanc...

2. https://talawah.io/blog/extreme-http-performance-tuning-one-...

3. https://github.com/h2o/picohttpparser

Just-js is not nodejs framework. It's sperate runtime and most of the http code is written using c/c++ (for example headers parsing logic is written using c and is using https://github.com/h2o/picohttpparser which is c library)

I also have some epoll server code at https://github.com/samsquire/epoll-server

You might find my epollserver interesting.

It multiplexes multiple clients (sockets) over a thread, so you can write an event loop in each thread and serve far more requests per thread than you could if it was one thread per client or one process per client.

https://github.com/samsquire/epoll-server

I wrote an epoll echo server that multiplexes multiple network connections over threads (multiple users per thread)

https://github.com/samsquire/epoll-server

I also have a 1:M:N (1 scheduler thread, M kernel threads and N lightweight green threads) multithreaded userspace scheduler which multiplexes lightweight threads onto kernel threads and can preempt hot loops with minimal overhead. I rely on the fact that you can change the looping variable from another thread if you use a structure. Preemptive interruption is very useful for the illusion of multitasking. That's why I call it a userspace scheduler.

I think the epoll-server which is kind of similar to what libuv does and the userspace scheduler could be combined into an application server.

I also wrote a multithreaded actor implementation in Java. Threads can communicate with each other between 60 million - 100 million messages a second. The epoll-server uses a multiconsumer multiproducer lockless RingBuffer.

https://GitHub.com/samsquire/multicersion-concurrency-contro...

I think the core fundamentals of building a performant application server should be done once and reused for each application.

I want to also split the threading used by recv and send of a socket so that we have a 1:R/S per socket:N scheduling (1 scheduler thread, 1 Recv thread, 1 send thread per socket). So you can send while you receive and receive while you send. True multiplexing!