Fastsocket – A highly scalable socket for Linux

https://github.com/fastos/fastsocket#nginx

>on Linux 2.6.32 achieves 470K connection per second and 83% efficiency up to 24 cores, while performance of base 2.6.32 kernel increases non-linearly up to 12 cores and drops dramatically to 159K with 24 cores. The latest 3.13 kernel doubles the throughput to 283K when using 24 cores compared with 2.6.32. However, it has not completely solve the scalability bottlenecks, preventing performance from growing when more than 12 cores are used.

In any case, it doesn't matter if it's a 50 year old kernel. If it speeds up connections per second, someone will put up a box on the frontend with it as the load balancer.

I'm new to kernel programming. Is this submission suggesting that you downgrade your kernel to a 2010-era release in order to take advantage of the performance improvements, or is the submission showing some kind of modular component which you can integrate into your current kernel?

If it's the former, then wouldn't you be pinning yourself to the old version of the kernel, so you'll have to integrate all updates by hand rather than receive them automatically during the normal update process?

This would be a tremendous boon for those environments!

As an example of how this kernel is not the 2.6 tree: On April 14, 2014, in RedHat's 2.6.32-431.23.3.el6 kernel tree [1] , there was recently a patch included [2] that affects the ipv4 subsystem. You can find that same patch [3] was originally applied to the Linux kernel on April 14, 2014. This is common practice, and so RedHat kernels more closely resemble modern kernels like 3.12 than anything else.

[1] https://oss.oracle.com/git/?p=redpatch.git;a=shortlog;h=rhel... [2] https://oss.oracle.com/git/?p=redpatch.git;a=commitdiff;h=c0... [3] http://www.serverphorums.com/read.php?12,912195

Fastsocket creates one local listen socket table for each CPU core. With this feature, application process can decide to process new connections from a specific CPU core. It is done by copying the original listen socket and inserting the copy into the local listen socket table. When there is a new connection on one CPU core, kernel tries to match a listen socket in the local listen table of that CPU core and inserts the connection into the accept queue of the local listen socket if there is match. Later, the process can accept the connection from the local listen socket exclusively. This way each network softirq has its own local socket to queue new connection and each process has its own local listen socket to pull new connection out. When the process is bound with the CPU core specified, then connections delivered to that CPU core by NIC are entirely processed by the same CPU core with in all stages, including hardirp, softirq, syscall and user process. As a result, connections are processed without contension across all CPU cores, which achieves passive connection locality.

The kernel in its normal configuration will try to spread the IRQs evenly across CPUs. So for their use case, where you have one worker thread per CPU handling zillions of short lived TCP connections, they can eliminate a bunch of locking and cache thrashing that would otherwise happen when handling new connections and dispatching the related epoll events within the kernel.

This is the OSI model, from the top down:

7) Application 6) Presentation 5) Session 4) Transport 3) Network 2) Data link 1) Physical

ZeroMQ fits in neatly at the top, layer 7 (arguably it is the presentation layer too because it uses its own protocol).

What this is talking about relates to network sockets which is around layers 4 and 5 (you can find lots of debate around the subject). Any speed improvements at lower levels in the stack would be seen by stuff on layers above it.