> 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.html
