LINUX.ORG.RU

[python]Асинхронные фреймворки и мультипроцессорность

 


0

1

В последнее время стало модно писать приложения на асинхронных фрейморках ( взять тот же node.js ). Т е там заявляется что в одном процессе можно добиться довольно быстрой отдачи контента если он нигде блокируется ( больше одновременных соединений ). Для примера приводится «обычный» «синхронный» процесс.

А как обстоит дело в случае запуска нескольких процессов ( сообразно количеству ядер на сервере ) ? Целесообразно ли запускать асинхронные процессы в несколько процессов ? Просто данный вопрос в асинхронных фреймворках особо не затрагивается . А насколько в таком случае будет выигрыш при использовании нескольких асинхронных процессов напротив нескольких синхронных процессов и будет ли он вообще ?

Просто стал вопрос о выборе ПО для выдачи практически статистического контента с минимальной программной обработкой ( какой нить простенький шаблонизатор, даже без БД ). Приоритетом должно служить максимальное кол-во одновременно обслуживаемых клиентов. Что лучше использовать - например связку «python uwsgi» с несколькими workers или какой нить асинхронный фрейморк типа tornado или gevent в один или несколько процессов ?

★★☆☆

Последнее исправление: SI (всего исправлений: 1)

лучше использовать статику, которую кешировать, что взять за шаблонизатор — без разницы. отдавать nginx'ом, причем тут питон вообще? запускают в несколько процессов, по количеству ядер, да.

trashymichael ★★★
()

nginx + http cache

Зачем для статики wsgi не могу понять.

resurtm ★★★
()

Целесообразно ли запускать асинхронные процессы в несколько процессов ?

конечно целесообразно, иначе у тебя всё упирается в производительность одного процессора.

нескольких асинхронных процессов напротив нескольких синхронных процессов и будет ли он вообще ?

представь у тебя 10тыщ соединений (не так много, на самом деле). При асинхронной работе ты можешь хоть одним процессом обслуживать. А при синхронном тебе понадобится 10тыщ тредов, процессов, whatever. Ясен пень синхронная модель на таких задачах сосёт.

Приоритетом должно служить максимальное кол-во одновременно обслуживаемых клиентов.

ставить запросы в очередь и обслуживать синхронно. Асинхронность нужна когда всё упирается в кол-во соединений и io которого нужно ждать. А на cpu-bound задачах преимущества асинхронные модели не дают. Поэтому тебе нужна очередь и пул воркеров. А уже отдачу готового контента навесить на что-нить асинхронное что будет отдавать клиентам по мере готовности результата.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.