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: Curl + OpenSSL 3.x is painfully slow on windows
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Zakrzewski, Jakub via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 17 Apr 2023 10:58:43 +0000
> This is not the only performance regression people have found and reported on
> OpenSSL 3.x. Luckily, we support lots of other libraries as well.
Yeah, I'm aware.
I maybe could live the other perf. regressions, even though they altogether cost me ~30% drop in rq/s,
but that one was huuuuge.
> Do you have any specific ideas how we even could do it apart from recommending
> library alternatives or downgrading?
For that specific one one could actually do what I did - let curl read the bundle by itself, and
provide it as blob to OpenSSL. I don't know if that's viable though.
> I'm not sure what you are referring to, but CURLOPT_CA_CACHE_TIMEOUT works for
> an easy handle used by the easy interface as well.
OK, I used the wrong words 😄
If I understand the code correctly, it'd work for the easy interface, if the easy handles are re-used.
Unfortunatelly, this is not the case in our codebase (again, there are architectural reasons why it
cannot be easily changed 🙁 ).
Do you think I could implement the caching by myslef by forcing OpenSSL to parse the bundle once
and then just injecting it into the SSL Context using CURLOPT_SSL_CTX_FUNCTION?
I kinda don't want to go back to 1.1.x, but if I cannot keep the performance on a manageble level,
I might be forced to.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcurl.se%2Fsupport.html&data=05%7C01%7C%7Cba4c7265a2de4b5bb9c008db3f2fdcf0%7C9a21e1abb7a74f828fd0170bb7e09f92%7C0%7C0%7C638173247034402626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=igQszwlbWtYpwnJey5Q5pRN6bCJnrd1SAUcEvActkm0%3D&reserved=0<https://curl.se/support.html>
Date: Mon, 17 Apr 2023 10:58:43 +0000
> This is not the only performance regression people have found and reported on
> OpenSSL 3.x. Luckily, we support lots of other libraries as well.
Yeah, I'm aware.
I maybe could live the other perf. regressions, even though they altogether cost me ~30% drop in rq/s,
but that one was huuuuge.
> Do you have any specific ideas how we even could do it apart from recommending
> library alternatives or downgrading?
For that specific one one could actually do what I did - let curl read the bundle by itself, and
provide it as blob to OpenSSL. I don't know if that's viable though.
> I'm not sure what you are referring to, but CURLOPT_CA_CACHE_TIMEOUT works for
> an easy handle used by the easy interface as well.
OK, I used the wrong words 😄
If I understand the code correctly, it'd work for the easy interface, if the easy handles are re-used.
Unfortunatelly, this is not the case in our codebase (again, there are architectural reasons why it
cannot be easily changed 🙁 ).
Do you think I could implement the caching by myslef by forcing OpenSSL to parse the bundle once
and then just injecting it into the SSL Context using CURLOPT_SSL_CTX_FUNCTION?
I kinda don't want to go back to 1.1.x, but if I cannot keep the performance on a manageble level,
I might be forced to.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcurl.se%2Fsupport.html&data=05%7C01%7C%7Cba4c7265a2de4b5bb9c008db3f2fdcf0%7C9a21e1abb7a74f828fd0170bb7e09f92%7C0%7C0%7C638173247034402626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=igQszwlbWtYpwnJey5Q5pRN6bCJnrd1SAUcEvActkm0%3D&reserved=0<https://curl.se/support.html>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-04-17