15 марта 2009 г. 19:37 пользователь Alex Koshelev
>> Почему именно файловый I/O блокируется? В современных ОС вполне можно
>> сделать его не блокирующим, и отпускать воркер на то время пока ОС не
>> заполнит буфер и не просигнализирует об этом. В чем в данной ситуации
>> концептуальное различие между сетевым I/O?
> А. Тогда вопрос, действительно, к Игорю.
Игорь, если вы читаете этот тред, не могли вы прокомментировать
вопрос, если не трудно.
>
> Но, вообще-то, проблема довольно новая, и не для всех актуальная.
> Чтобы ее в нее упереться - надо раздавать большие файлы на очень
> высоких скоростях. Много разных и больших файлов, на скоростях,
> сравнимых со скоростями дисковых интерфейсов.
>
> А еще надо, чтобы подобная популярность не означала автоматически
> возможности поставить второй, третий, десятый сервер в кластер. Это я
> вообще не понимаю, как получается.
>
>
>> Так же интересно, если рассматривать асинхронный же бекэнд, то имеет
>> ли он вообще смысл, если воркер может заблокироваться при обработке
>> запроса? Конечно не рассматривая ситуация когда воркеров несколько и
>> они все грузят бекэнд.
> Если вы в это упретесь - придется статику с динамикой разнести по
> разным процессам.
>
У меня пока сугубо теоретический интерес. Я пытаюсь понять как
работает nginx и как я могу оптимально наладить инфраструктуру его
взаимодействия с моим приложением.
Интересен теперь такой момент. Если у меня есть выделенные инстансы
nginx для статики и для проксирования на бекэнд. Бекэнд может быть как
просто неким http сервером так и неким конечным приложением в виде
FastCGI демона. Насколько я с вашей помощью понял, если http
сервер-бекэнд будет не очень шустро отдавать ответы на запросы, то это
не вызовет блокировку воркера. А если это будет FasCGI? То тоже не
стоит опасаться блокировок? Рассматриваем ситуацию, когда пост данные
не велики и не надо их прогонять через диск.
---
Александр Кошелев
