Re: оптимизация модуля: переполнения и блокировки

[minya]

Valery Kholodkov Wrote:
-------------------------------------------------------

> > Ответ
> > может быть достаточно
> большим. Если он
> > целиком живет в памяти и
> запросов
> > много, то можно пережрать
> память и
> > загнать процесс в своп. С
> другой
> > стороны, то запрос может
> выполняться
> > достаточно долго.
> Количество запросов,
> > обрабатываемых
> одновременно - не такое
> > большое. Это количество
> ядер. Если
> > количество подключений
> достаточно
> > велико, и мы используем
> блокирующее
> > чтение, то с хорошей
> вероятностью все
> > ядра будут заняты
> ожиданием
> > ввода-вывода, и
> большинство запросов
> > будут ждать, пока они
> освободятся.
> > Таким образом, мы сильно
> деградируем по
> > времени ответа.
> 
> Было бы неплохо, если бы Вы
> объясняли более конкретно.
> Я опять ничего не понял. 

Я имел в виду ситуацию, когда
формируемый ответ большой. И его
формирование занимает какое-то время.
Если он втечение всего этого времени
живет в памяти, то можно исчерпать всю
память, т.к. сервер обслуживает большое
количество запросов одновременно. Для
того, чтоб этого избежать, надо не
буферизовать ответ, а сразу отсылать в
сокет то, что доступно и читать дальше.
Maxim Dounin говорит, что можно это сделать
повешав свой обработчик на событие
записи клиенту и там освобождать
буффера, которые уже отправлены. Буду
ковырять в этом направлении.

Что касается моих предположений по
поводу блокировки при чтении из бд - тут
я погорячился. Здесь ничего не поделать
- ибо интерфейс работы с базой данных
такой возможности не предлоставляет.
Если в случае с файлом я могу сакзать
nginx'у "на тебе дескриптор, и читай от сих
до сих" и он закинет этот дескриптор в
очередь на poll/epoll (если сочтет нужным),
то в случае с каким-то другим "чтением" я
этого сделать не могу. 


Andrey Repin Wrote:
------------------------------------------------------- 
> А это уже зависит от
> размера буфера,
> отдаваемого клиенту в
> каждом случае.
> Даже не от самого размера, а
> от отношения его к общему
> размеру результата.

Все верно. Тут нужно гонять тесты и
подбирать параметры. Проблема лишь в
том, что ответы бывают разные по
размеру. И разброс достаточно большой.
Кажется, что в такой ситуации трудно
будет найти баланс.

Posted at Nginx Forum: http://forum.nginx.org/read.php?21,218226,218426#msg-218426