Хорошие производственные значения для CURLOPT_CONNECTTIMEOUT и CURLOPT_TIMEOUT для одного и того же сервера - PullRequest
Новая
       15

Хорошие производственные значения для CURLOPT_CONNECTTIMEOUT и CURLOPT_TIMEOUT для одного и того же сервера

0 голосов
/ 14 мая 2018

Надеюсь, мой вопрос не слишком произвольный: на моем рабочем сервере у меня есть страница, отправляющая вызов API другому приложению на том же сервере с cURL.

Я хотел бы установить соответствующие значения на CURLOPT_CONNECTTIMEOUT, а затем CURLOPT_TIMEOUT, чтобы оставить достаточно времени, чтобы убедиться, что запрос завершается в случае большого количества запросов, но в то же время я не хочу, чтобы страница зависала в случае, если API не работает или слишком много времени для ответа, что приведет к значительному отставанию для всех пользователей, так как будет создан огромный состав.

API делает очень быстрый запрос к БД, который возвращает небольшую структуру json, ничего сложного, что занимает много времени.

Учитывая эти спецификации, кто-нибудь может прокомментировать это? В настоящее время у меня есть: 

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

UPDATE

  • API совершенно новый и используется только мной
  • API - это ключ для получения всех данных. Если API не работает, ничего не работает, и я отображаю сообщение об ошибке
  • API запускается на каждой странице для получения необходимых данных

Ответы [ 2 ]

0 голосов
/ 14 мая 2018

Вам необходимо иметь информацию о поведении этого API, чтобы принять обоснованное решение. Это также зависит от того, как этот API используется в вашем коде и какое поведение вы хотите в случае сбоя.

Рассмотрим:

  • Если вы установите слишком низкое значение, ваш код потерпит неудачу, если API займет больше времени, чтобы ответить по любой причине.
  • Если для ответа API требуется больше времени, чем ~ 4 секунды, что это значит?
    • API полностью отключен? Тогда вам действительно не нужно ждать дольше.
    • Это перегружено? Тогда бы он ответил в течение 5 секунды? 6? 10? Как долго будет длиться это перегруженное состояние? Плохо ли смешивать его, перегружая его, или лучше прервать код на ранней стадии и позволить API восстановиться?
    • Есть ли временный сбой сети? Это решило бы, если бы вы сделали тайм-аут 5 секунд? 10? 20? Насколько надежна сеть обычно?
  • Вы бы предпочли, чтобы ваше приложение было медленным или мертвым , если API реагирует медленно по какой-либо из вышеуказанных причин?
  • Можете ли вы гарантировать определенное время отклика API, и если оно не сохраняет эту гарантию, значит, оно не работает?

  • Какое целевое время отклика для вашего пользовательского сайта?

    Тайм-ауты сети, как правило, составляют от 30 до 120 секунд, что компенсирует временные проблемы в сети, но также все еще находится в пределах досягаемости человека. Внимание пользователя, как правило, смещается через несколько сотен миллисекунд, поэтому вы захотите, чтобы время отклика не превышало одной секунды. Однако нередко приходится ждать загрузки сайта в течение нескольких секунд.

Если вам нужно настроить такой критический параметр, чтобы найти наилучшую настройку, прагматичный способ сделать это - установить для него какое-то начальное значение, установить некоторые инструменты измерения для мониторинга пропускной способности и скорости отклика, а также инициировать нагрузку. тест, имитирующий ожидаемый уровень нагрузки производства. Затем вы увидите, как ваши ошибки и частота откликов увеличиваются или уменьшаются, и вы можете изменять настройки, пока не найдете значение, удовлетворяющее вашим желаемым ограничениям.

0 голосов
/ 14 мая 2018

Есть много факторов, которые вы должны учитывать при определении этих значений. Однако 2 секунды считаются приемлемыми для HTTP-запроса (первый байт). Если вы управляете сервером, с которого отправляется HTTP-запрос, вам также следует учитывать ресурсы сервера, например, память, процессор, ввод-вывод, конфигурацию веб-сервера. Но, вообще говоря, вам следует рассмотреть возможность запуска traceroute до конечной точки для лучшего понимания задержки - это поможет вам определить более точные значения времени ожидания для CURL. И, конечно, наконец, вы должны учитывать те же ограничения ресурсов, упомянутые ранее для сервера для клиента, если вы инициируете много запросов оттуда.

Надеюсь, это поможет! Смотрите блог по адресу: https://www.inmotionhosting.com/support/website/how-to/read-traceroute

...