朝着同一服务器的CURLOPT_CONNECTTIMEOUT和CURLOPT_TIMEOUT的良好生产价值

Question

I hope my question is not too arbitrary: On my production server, I have a page sending an API call to another app on the same server with cURL.

I would like to set appropriate values on CURLOPT_CONNECTTIMEOUT then CURLOPT_TIMEOUT to leave enough time to make sure the request completes in case there are lots of requests, but at the same time I don't want the page to hang in case the API is down or takes too long to respond, which would then result in major lag for all users as a huge line-up would be generated.

The API makes a really quick DB query that returns a small json structure, nothing complicated that takes much time.

Given these specifications, any people could comment on this? I currently have:

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 2);
curl_setopt($ch, CURLOPT_TIMEOUT, 4);

UPDATE :

• API is brand new and only used by me
• API is the key to get all the data. If the API doesn't work, nothing works and I display an error message
• API is run on each page to get the needed data

Answer 1

There are many factors that you need to consider when defining those values. However, 2 seconds is considered acceptable for an HTTP request (first byte). If you manage the server where the HTTP request originates then you also should consider the server resources eg, memory, CPU, IO, web server configuration. But generally speaking you should consider running traceroute to your end point to better understanding latency-- this will help you define a more accurate timeout values for CURL. And of course, finally you should consider the same resource constraints mentioned earlier for the server for the client if you are initiating many requests from there.

Hope this helps! See blog at: https://www.inmotionhosting.com/support/website/how-to/read-traceroute

Answer 2

You need to have information about the behaviour of that API in order to make an educated decision. It also depends on how that API is used in your code and what behaviour you desire in case of failure.

Consider:

• If you set the value too low, your code will fail if the API takes longer to respond for whatever reason.
• If the API takes longer to respond than ~4 seconds, what does that mean?
  • Is the API down entirely? Then indeed you do not need to wait longer.
  • Is it overloaded? Then would it have responded within 5 second? 6? 10? How long will this overloaded state last? Is it bad to compound it by overloading it more, or is it better to abort your code early and let the API recover?
  • Is there a temporary network hickup? Would that resolve if you made the timeout 5 seconds? 10? 20? How reliable is the network typically?
• Would you prefer your app to be slow or dead if the API responds slowly for any of the above reasons?
• Can you guarantee a certain response time of the API, and if it doesn't keep that guarantee that means it's down?

• What's the target response time for your user facing site?

  Network timeouts are typically between 30 and 120 seconds, which compensates for temporary network issues but is also still within the range of a human. A user's attention typically drifts after a few hundred milliseconds, so you'll want to keep your response time well under one second. However, it's not unusual to have to wait for a website to load for a few seconds.

If you need to tweak such a critical parameter to find the best setting, the pragmatic way to do that is to set it to some initial value, get some measurement tools in place to monitor throughput and response rates, and initiate a stress test that simulates expected production level load. Then you'll see your error and response rates go up or down and can tweak the setting until you have found a value that satisfies your desired constraints.