Re: Архитектура Nginx

[Alexandr Kutuzov]

реализация дискового aio до сих пор не во всех системах так хороша как  
хотелось бы. Почитайте архив рассылки, там это было.

имеет или не имеет смысл это вопрос скорее к архитектуре вашего  
приложения.

Наибольшая проблема которая может возникнуть это тормоза на машине  
раздающей и статику и динамику одновременно.
В таком случае помогает разделение динамики и статики полностью.  
например разнос на  2 IP с 2мя висящими на них нгинксами вполне себе  
избавят от этой проблемы.

15.03.2009, в 17:19, Alex Koshelev написал(а):

> 2009/3/15 Daniel Podolsky <onokonem at gmail.com>:
>>
>>> А почему так сделано не подскажите?
>>>
>>
>> Так сделано для того, чтобы много-много одновременных соединений,  
>> по которым
>> медленно-медленно уходят к клиентам байты, кушали мало-мало  
>> оперативной
>> памяти и процессора.
>>
>> Байты эти можно забрать с диска - это будет статика. А можно  
>> забрать с
>> backend-а, это будет динамика. Выигрыш на динамике достигается за  
>> счет того,
>> что отдача с backend-а на nginx происходит быстро, и тяжелый  
>> процесс не
>> должен висеть в памяти, пока клиент забирает результаты его работы.
>>
>> только это азбука, и написано об этом на сайте sysoev.ru вполне  
>> внятно.
>>
>>
>
> Извините но я не это спрашивал.
>
> Почему именно файловый I/O блокируется? В современных ОС вполне можно
> сделать его не блокирующим, и отпускать воркер на то время пока ОС не
> заполнит буфер и не просигнализирует об этом. В чем в данной ситуации
> концептуальное различие между сетевым I/O?
>
> Так же интересно, если рассматривать асинхронный же бекэнд, то имеет
> ли он вообще смысл, если воркер может заблокироваться при обработке
> запроса? Конечно не рассматривая ситуация когда воркеров несколько и
> они все грузят бекэнд.
>
> Спасибо.
> ---
> Александр Кошелев