реализация дискового aio до сих пор не во всех системах так хороша как
хотелось бы. Почитайте архив рассылки, там это было.
имеет или не имеет смысл это вопрос скорее к архитектуре вашего
приложения.
Наибольшая проблема которая может возникнуть это тормоза на машине
раздающей и статику и динамику одновременно.
В таком случае помогает разделение динамики и статики полностью.
например разнос на 2 IP с 2мя висящими на них нгинксами вполне себе
избавят от этой проблемы.
15.03.2009, в 17:19, Alex Koshelev написал(а):
2009/3/15 Daniel Podolsky <onokonem@xxxxxxxxx>:
А почему так сделано не подскажите?
Так сделано для того, чтобы много-много одновременных соединений,
по которым
медленно-медленно уходят к клиентам байты, кушали мало-мало
оперативной
памяти и процессора.
Байты эти можно забрать с диска - это будет статика. А можно
забрать с
backend-а, это будет динамика. Выигрыш на динамике достигается за
счет того,
что отдача с backend-а на nginx происходит быстро, и тяжелый
процесс не
должен висеть в памяти, пока клиент забирает результаты его работы.
только это азбука, и написано об этом на сайте sysoev.ru вполне
внятно.
Извините но я не это спрашивал.
Почему именно файловый I/O блокируется? В современных ОС вполне можно
сделать его не блокирующим, и отпускать воркер на то время пока ОС не
заполнит буфер и не просигнализирует об этом. В чем в данной ситуации
концептуальное различие между сетевым I/O?
Так же интересно, если рассматривать асинхронный же бекэнд, то имеет
ли он вообще смысл, если воркер может заблокироваться при обработке
запроса? Конечно не рассматривая ситуация когда воркеров несколько и
они все грузят бекэнд.
Спасибо.
---
Александр Кошелев
