Разумные значения тайм-аута HTTP POST для использования при программной выдаче запросов?
при программной выдаче запросов HTTP POST, какие значения тайм-аута были бы разумными?
в моем случае я хочу установить "разумные" значения таймаута при выполнении запросов POST в PHP, однако это относится к любому языку.
Мне нужно иметь возможность выдавать набор запросов, каждый на указанный пользователем URL. Если мне нужно обрабатывать запросы последовательно, а не одновременно, я хотел бы указать разумное время, по истечении которого запрос считается синхронизированным из.
PHP тайм-аут сокета по умолчанию 60 секунд. Это кажется излишне долгим временем ожидания, прежде чем решить, что запрос не будет завершен.
поскольку это запросы POST, они должны быть завершены быстро - нет данных, которые должны быть получены и возвращены, как с запросом GET.
мы должны быть в состоянии предположить,большую часть времени, что неспособность выдать ответ на запрос в течение X секунд означает, что хост вряд ли выдаст ответ в течение разумного времени для значений X значительно меньше, чем 60.
конечно хосты редко занимают больше 60 секунд, чтобы ответить на простой запрос POST. Они даже редко занимают больше 10 секунд? 5 секунд?
какие могут быть разумные значения для X на практике? Обоснования, сопровождающие предложения, были бы чрезвычайно полезными.
2 ответов
Я бы рекомендовал настроить тест, так как слишком много факторов участвуют, чтобы дать значение, которое всегда будет разумным.
запрос POST отправляет данные для обработки. Как долго с обработкой взять? Это будет специфично для приложения / данных.
где хозяин? Пользователь предоставляет URL-адрес, так что это будет неизвестно. Мы не можем знать, каков трафик между вашим приложением и хостом. Мы не можем знать нагрузку сервера хозяин.
по сути, нет универсального разумного таймаута. Вы должны использовать свое собственное лучшее суждение, основанное на ваших конкретных потребностях. Настройте тест и используйте его, чтобы определить свои пределы.
большинство библиотек имеют тайм-аут подключения и тайм-аут чтения. То есть таймаут между попыткой подключения к удаленному серверу и таймаутом после отправки запроса, что они должны ждать ответа.
Если это локальная веб-служба, я бы установил тайм-аут подключения низкий, 1 секунду или меньше, если ваша библиотека поддерживает его. Если удаленный сервис, к которому вы подключаетесь, недоступен, IMHO лучше сразу вернуть ответ пользователю, чем разрешить все ваши рабочие потоки для блокировки этой удаленной службы, вызывая другие ошибки восходящего потока.
Что касается тайм-аута чтения, это сложнее, вам нужно, чтобы он был низким, поэтому вы не исчерпываете свой пул работников, которые ждут возврата удаленной службы, но вы также не хотите, чтобы он был настолько низким, что он закрывает соединение перед чтением ответа. Это то, что вам нужно будет протестировать, а затем отслеживать как метрику, когда ваша система находится в производстве.