On Thu, Jan 6, 2022 at 10:55 PM Daniel Stenberg <dan...@haxx.se> wrote:
> On Thu, 6 Jan 2022, James Read via curl-library wrote: > > > Extensive testing with epoll has showed limitations in the speed up when > > using concurrent connections. > > Have you ruled out that these limitations aren't just the results of bugs > or > plain inefficiencies in the code? > I thought it might be a problem with curl so I made a version that doesn't use curl. I posted this question https://stackoverflow.com/questions/70584121/why-doesnt-my-epoll-based-program-improve-performance-by-increasing-the-number on stackoverflow and the resulting discussion led me to start experimenting with PACKET_MMAP which seems like a promising solution to get some more speed up. As described in the question I get speed up with low numbers of concurrent connections but after 1024 and greater no real performance gains. > > > Perhaps it would be useful to add support for PACKET_MMAP style > > communication to get more speed up out of it. > > In general I'm in favor of adventures to improve performance. Doing > PACKET_MMAP style networking sounds like the TLS layer would also need > some > serious adjustments, so quite a hefty effort probably. Optimized transfers > for > clear-text only would feel a tad bit too much like 2016 or so! :-) > > I agree it will be a lot of work. But I think it will be worth it. We should be able to saturate the available bandwidth with concurrent communications. James Read > -- > > / daniel.haxx.se > | Commercial curl support up to 24x7 is available! > | Private help, bug fixes, support, ports, new features > | https://curl.se/support.html >
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
