@hirthwork

Тег http в блоге hirthwork

hirthwork

перекопал весь rfc2616, но так и не нашёл точного указания, что должно быть в Host: при посылке proxy-запроса: хост прокси или хост таргета

hirthwork

Если в процессе отправки ответа клиенту, клиент отваливается, то в access-лог пишется хттп-статус 499. Какой статус следует писать, если в процессе отправки ответа отвалился сервер, с которого проксируем ответ?

hirthwork

Каждый раз когда вы собираетесь использовать chunked transfer encoding,
выставляйте tcp_nodelay = true.
Почему? А представьте, что стреляете вы, скажем, json'ом. И вот уходит у вас
такой небольшой чанк (после которого вы делаете flush):

14
{"hello":"world"}

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

А теперь представьте, что у принимающей стороны включён delayed-ack.
Например, у меня он включён, как оказалось.

Все данные вы отослали и теперь нужно бы послать нулевой чанк, чтобы сказать
что у вас данные закончились. Вот только ack на прошлый пакет ещё не пришёл, и
нулевой чанк, запихнутый в сокет-буфер вами, никуда не отсылается, ибо ack'а
ждёт. А принимающая сторона, в свою очередь, ждёт от вас этого нулевого чанка.
Вот и сидят две программы по разные стороны сокета и ждут неизвестно чего, пока
принимающая сторона таки не соблаговолит отложенный ack послать.

hirthwork

чем щас моднее всего менять пропускную способность HTTP-сервера? Хочется померять сколько мегабайт в секунду он может принять через один коннект (в т.ч. chunked) и сколько способен записать. Писать велосипед не хочется

hirthwork

вот есть HTTP-сервак. Спокойно десятки тысяч запросов в секунду может обрабатывать. Но нет, мой сумрачный гений, таки написал тест, когда при keep-alive соединениях, новые соединения не обрабатываются пока пачка старых не подохнет. Ок, пренебречь вальсируем, переписал сервак, тест стал проходить, говнокода количество резко увеличилось. Но нет, сейчас написал ещё один валящийся тест... а у меня уже запасы говнокода заканчиваются.

hirthwork

Посоны, дело в том, что есть один HTTP-сервер. Он без изъёбов и поллинга, т.е.
тупо один сокет и главный тред у этого сокета делает просто accept(), а затем
добавляет этот сокет в пул задач. В пуле крутятся потоки, которые из очереди
выбирают accept'нутые сокеты и покуда сокет не закрыт (или же не сделан
Connection: close) в цикле обрабатывают всё HTTP-шное на этом сокете. Чтобы
случайно не пришёл OOM, главный тред блокируется, если в очереди пула задач
лежит больше N сокетов, которые никто не обрабатывает. Оттормаживаемся, так
сказать.
Какие минусы у данного подхода — даже куркуме понятно: если воркер-треды
получат медленных клиентов с keep-alive, то остальные клиенты будут висеть
необработанными пока эти тормознутые не отвалятся. Вдобавок, нельзя
обслуживать одновременно keep-alive соединений больше чем есть воркер тредов.
Дык вот, посоны, как нынче модно решать подобные проблемы? Класть новую задачу
в пул после того как обработался очередной запрос непосредственно из
воркер-треда кажется мне изъёбом и чем-то противоестественным.

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.