[Moscow.pm] асинхронный код позволяет сильно сэкономить ресурсы серверов

[Ruslan Zakirov]

2015-02-08 21:35 GMT+03:00 Daniel Podolsky <onokonem на gmail.com>:

> о! собеседник!
>
> >> > Ага. В этом смысле асинхронный подход ближе к реальности.
> >> вам ближе к реальности или деньги зарабатывать?
> > Смотря чем зарабатывать. Есть много задач, где асинхронный код позволяет
> > сильно сэкономить ресурсы серверов.
> а вот давайте разберемся, какие именно ресурсы серверов позволяет
> сэкономить асинхронный код, и справедливо ли это утверждение для
> асинхронного кода на перле.
>
> изложите, пожалуйста, тезис об экономии подробнее. а то я так много об
> этом думал, что мгновенно начинаю с демонами в своей голове
> разговаривать, как об асинхронном перле речь заходит :(
>

Экономия по сравнению с prefork моделями в Perl. Если задач "io-bound", а
не cpu bound. Просто один процесс блокирующий может обрабатывать 1 заброс в
данный конкретный момент времени, а неблокирующий сколько вашей душе угодно
(пока не уперлись в лимиты). Так или иначе вес процесса в perl достаточно
высокий, а также после fork расшареные страницы клонируются может и не все,
но многие, то есть шарим не так много (были тесты еще в mod_perl1
сообществе).

Если у вас задача обрабатывать 10000 параллельных соединений с малой
нагрузкой на CPU, то в prefork модели вам понадобиться 10000 worker'ов, а в
событийной N CPU*1 (или 2, 4, 6 - не считал потери).

Если у вас задача CPU bound, то вам событийная модель мало чем поможет.
Единственное, что вы можете сделать, так это распараллелить один таск на
несколько ядер (тредами, горутинами, сторонней либой, Си+треды, ...). Не
важно как вы это сделаете, но если у вас 64 ядра и вы можете за разумное
время на них исполнять только 64 параллельные задачи одновременно, то какая
разница на какой это модели.

Если задача memory bound, то опять число обработчиков ограничено памятью
системы и как вы не старайтесь, но на N задача нужно O(k*N) памяти и размер
самого worker'а уже не имеет значения.

О thread'ах в perl говорить не будем.


> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20150210/90775aa1/attachment.html>