Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: roadmap 2022 thoughts?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: James Read via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 6 Jan 2022 23:51:24 +0000
On Thu, Jan 6, 2022 at 10:55 PM Daniel Stenberg <daniel_at_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
>
Date: Thu, 6 Jan 2022 23:51:24 +0000
On Thu, Jan 6, 2022 at 10:55 PM Daniel Stenberg <daniel_at_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.htmlReceived on 2022-01-07