Hi, On Fri, Nov 27, 2020 at 7:56 AM Patrick Schlangen <patr...@schlangen.me> wrote:
> On Fri, 27 Nov 2020, James Read wrote: > > Has anybody ever actually succeeded in making a high performance > application > > with epoll/libcurl as the back end. > > Yes. Some things I've learned (for my usecase): > What's your usecase? What kind of throughput were you able to achieve. > > * If using SSL hosts, set CURLOPT_CAINFO to a small list of accepted CAs > or, if not interested in validation, to NULL. In my case, the default list > of trusted CAs which came with my OS (Ubuntu) was loaded all the time for > every connection, and it was huge and that caused a significant (!) > performance drop for the whole application. > > * Don't try to built your own c-ares integration or so (I think I've seen > something like this when briefly looking at your code). Just build libcurl > with c-ares support. Don't use any other resolver for high performance > async applications. > > * Disable IPv6 if not needed. (CURLOPT_IPRESOLVE = CURL_IPRESOLVE_V4) > > * Disable following of redirections if not needed. > > * Use libev. All other event libraries didn't work reliably for me. > > * Build libcurl, c-ares, openssl etc from source using latest stable > versions. Ensure you really build/link against the versions you built > yourself. Stuff coming with your OS often is outdated or not configured for > your usecase (in libcurl case e.g. using a different ssl lib and/or > resolver). > > * Profile your application. Depending on the bottleneck, on multi core > systems, it might make sense to spawn multiple threads with their own curl > multi instances. > > Thanks for the tips. Have implemented some of them already with some limited success. Will keep working through the list. James Read > Maybe this helps. > > Patrick > > >
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html