Hi Arnall, On Wed, Oct 22, 2014 at 09:35:04PM +0200, Arnall wrote: > Hi everyone, > > do you know this project : > https://github.com/fastos/fastsocket
I just got the link forwarded to me today. (...) > Willy have you tried it ? Not yet. But I've read the code :-) The patch is quite small. It integrates some features which were done in later kernels (eg: wake only one listening process) and a few such things. I'd be interested in knowing what performance can be achieved on a very recent kernel in the same conditions and checking what's the minimal part of the patches that provides the most benefit. I guess that their changes to epoll_ctl() to reduce locking significantly improve things. Also they bypassed some pseudo filesystems to avoid some inode lookups if I understood well, but it's also said in the commit message that the equivalent was done in 2.6.37 and 3.1. Note that given the form of the graph in the performance evaluation, I think they ran the test with multiple processes all listening to the same socket, which is suboptimal prior to kernel 3.9. That could explain why 3.13 is so much better than 2.6.32 there. That said, this test is perfectly valid for some use cases. > And if yes do you recommend it ? It still seems very young and some parts were massively commented out in #if 0/#endif, including inside their own code, so I think they're still experimenting and fixing one bottleneck at a time. It might be worth trying it and sending them some feedback though! At first I thought they'd implement an alternate stack but no, they "only" improved the existing one, which is much better and less risky. They enable fastsocket by linking dynamically with their lib which basically redefines a few syscalls. We could very well have a "sock_fastsocket.c" file in haproxy to directly implement these syscalls natively without having to go through the dynamic linker. BTW I like the idea of using ioctls to replace some syscalls. I'd like to see a multi-accept and multi-epoll-ctl there as well. I think the project needs to be observed. However I'd like to see it ported to something more recent than 2.6.32, at least 3.10. I'm well placed to say that 2.6.32 is quite old now, especially when it comes to network processing :-) That would also help them get more contributors. Willy
