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.
curl_multi_socket_action takes longer when using HTTPS
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Richa Shah via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 1 Dec 2023 15:32:12 -0800
Hello!
I'm using libcurl in a C++ service for reaching out to a couple of other
services. My C++ service is a standard service - it listens for requests,
then uses libcurl to call a couple of other services, processes the
responses and returns something back to the caller.
I have been using HTTP so far with libcurl and have been able to scale up
to serve ~1000 incoming requests per second, per host for my service, with
an average latency of 10ms and a max latency of 80ms. When I switched to
HTTPS I was not able to even serve 500 requests per second, because of some
bottlenecks in my service implementation. I was able to figure out some of
these bottlenecks and fix them (one of these was not setting up proper
connection re-use with libcurl), and get up to 700 requests per second.
However, with 700 requests I'm still seeing worse latencies which average
at 10ms but sometimes go up to 1 second or more for the worst 1% of
requests. I did some profiling and noticed calls to the
curl_multi_socket_action method sometimes take 50 or 100 ms, which does not
happen when using HTTP. These long calls are adding up and causing a delay
in processing the requests that came in while we were processing pending
requests with curl.
I've read a few different messages on this forum as well as noticed that
the "mastering libcurl" videos reference that libcurl can scale up to serve
40k or 50k transfers at once. Can someone help me out with what could be
causing the curl_multi_socket_action method to take more time specifically
for HTTPS requests? Does the curl_multi_socket_action perform TLS
handshakes? And, are there some specific things I should configure to
ensure my integration with libcurl is able to scale well?
Here's some specifics about my setup:
- OS: Linux (kernel: 4.9)
- libcurl version: 7.72
- TLS backend: OpenSSL, version: 1.0.2
- I'm using the curl multi interface with epoll, my implementation matches
the ephiper example here: https://curl.se/libcurl/c/ephiperfifo.html
Here's a list of things I've tried/looked at:
- Increasing the connection pool size (by setting a hard count for
CURLMOPT_MAXCONNECTS, I'm currently using 2000 and I increased this to 4000
but observed no impact on my latencies)
- Measured the time it takes for my socket callback method (configured
using CURLMOPT_SOCKETFUNCTION), this is less than 50ms always
- Checked the time it takes for TLS handshakes using data from tcpdump -
this is around 8ms
- Logged the connect and app connect times. The connect time spikes up to
500 ms and the app connect time spikes up to 1.25 - 1.5 seconds. The spikes
in these two align with the spikes I'm observing for the service latencies
as well.
Thanks,
Richa
Date: Fri, 1 Dec 2023 15:32:12 -0800
Hello!
I'm using libcurl in a C++ service for reaching out to a couple of other
services. My C++ service is a standard service - it listens for requests,
then uses libcurl to call a couple of other services, processes the
responses and returns something back to the caller.
I have been using HTTP so far with libcurl and have been able to scale up
to serve ~1000 incoming requests per second, per host for my service, with
an average latency of 10ms and a max latency of 80ms. When I switched to
HTTPS I was not able to even serve 500 requests per second, because of some
bottlenecks in my service implementation. I was able to figure out some of
these bottlenecks and fix them (one of these was not setting up proper
connection re-use with libcurl), and get up to 700 requests per second.
However, with 700 requests I'm still seeing worse latencies which average
at 10ms but sometimes go up to 1 second or more for the worst 1% of
requests. I did some profiling and noticed calls to the
curl_multi_socket_action method sometimes take 50 or 100 ms, which does not
happen when using HTTP. These long calls are adding up and causing a delay
in processing the requests that came in while we were processing pending
requests with curl.
I've read a few different messages on this forum as well as noticed that
the "mastering libcurl" videos reference that libcurl can scale up to serve
40k or 50k transfers at once. Can someone help me out with what could be
causing the curl_multi_socket_action method to take more time specifically
for HTTPS requests? Does the curl_multi_socket_action perform TLS
handshakes? And, are there some specific things I should configure to
ensure my integration with libcurl is able to scale well?
Here's some specifics about my setup:
- OS: Linux (kernel: 4.9)
- libcurl version: 7.72
- TLS backend: OpenSSL, version: 1.0.2
- I'm using the curl multi interface with epoll, my implementation matches
the ephiper example here: https://curl.se/libcurl/c/ephiperfifo.html
Here's a list of things I've tried/looked at:
- Increasing the connection pool size (by setting a hard count for
CURLMOPT_MAXCONNECTS, I'm currently using 2000 and I increased this to 4000
but observed no impact on my latencies)
- Measured the time it takes for my socket callback method (configured
using CURLMOPT_SOCKETFUNCTION), this is less than 50ms always
- Checked the time it takes for TLS handshakes using data from tcpdump -
this is around 8ms
- Logged the connect and app connect times. The connect time spikes up to
500 ms and the app connect time spikes up to 1.25 - 1.5 seconds. The spikes
in these two align with the spikes I'm observing for the service latencies
as well.
Thanks,
Richa
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-12-02