Я настраиваю систему, которая предъявляет жесткие требования к времени отклика. Как заставить Apache2 отбрасывать запросы в очереди через 200 мс, если они не были обработаны?
Задний план
Одна из наших внутренних служб должна взаимодействовать с другой службой. Другая услуга требует, чтобы мы отправляли все ответы в очень короткие сроки. Для небольшого количества запросов мы можем обслужить запрос в желаемые сроки. Однако, как только система загружается большим количеством запросов, время ответа действительно страдает.
Поскольку загрузка будет в значительной степени непрерывной, мы получаем ситуацию пробки, когда более старые запросы ставятся в очередь и затем обслуживаются, но к тому времени запрос уже истек. Как мне убедиться, что мы либо обслуживаем запрос в течение отведенного ограниченного времени, либо просто отбрасываем его?
Apache httpd имеет одну ручку тайм-аута, TimeOut который касается тайм-аута TCP-отправки и получения действий, если клиент не отправляет данные на сервер своевременно (и некоторые другие вещи). Это предоставляется со второй степенью детализации и по умолчанию составляет 300 секунд. Что это не будет do - это тайм-аут запроса, который занимает, скажем, 5 секунд для локальной обработки.
Единственная очередь в httpd это ListenBacklog для запросов, которые находятся на сокет слушать отставание, ожидающее обработки текущим занятым рабочим потоком / потомком httpd. Их «Время» согласно Apache не начинается, пока их не подберет рабочий. Вы можете использовать небольшой ListenBacklog настройка, чтобы новые запросы отклонялись, когда ваш сервер начинает работать медленно. На самом деле, если ваши клиенты завершают соединение через 200 мс, это, вероятно, не имеет значения, поскольку запросы невыполненной работы никогда не будут запускаться должным образом как HTTP-запросы.
Подключения попадают в очередь только тогда, когда у вас есть MaxClients или ServerLimit / ThreadLimit / TheadsPerChild соединения, которые используются в настоящее время. Возможно, вы сможете настроить их до уровня, на котором ваша служба сможет выжить лучше.
В противном случае запросы обрабатываются httpd рабочий дочерний элемент / поток и не создают HTTP-ответ в течение <200 мс, что, как я подозреваю, является тем, с чем вы работаете. Если все ответы рассматриваются как «в процессе» в httpd вы мало что можете сделать, кроме как исправить то, что вызывает проблему. Если у вас есть приложение, работающее поверх httpd производя ответы, как бы он отреагировал, если httpd обрывает связь? Как база данных, если она находится внизу, справляется с отключением соединения? Обычно они без ведома выполняют запрос, пока не попытаются записать данные обратно в сокет в конце. Работа с тайм-аутами - это то, что нужно обрабатывать в вашем стеке на каждом уровне, чтобы он работал от начала до конца.
На уровнях, о которых вы говорите, я думаю, вам понадобится что-то совершенно другое, чтобы httpd для достижения ваших требований. Может быть Дворняга2 с его распределением работы на основе очередей может справиться время ожидания переднего конца легче? Может обычай HTTP-сервер на основе событий может справиться с таймаутами ?. Как упоминает Дэвид, даже TCP может столкнуться с трудностями при доставке на требуемых вами уровнях. Компонент TCP запроса даже не учитывается в отношении тайм-аутов на уровне приложения на стороне сервера, которые вы реализуете, если у вас нет встроенных интеллектуальных средств, которые рассчитывают время приема-передачи (чего не делает http).
Извините, это просто неразумно. TCP просто не создавался для предоставления услуг с малой задержкой. Такие вещи, как отложенный ACK и алгоритм Нэгла взаимодействуют, что делает его непригодным для приложений, где задержка должна быть низкой.