2015-02-08 21:35 GMT+03:00 Daniel Podolsky <onoko...@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.
-- Moscow.pm mailing list moscow-pm@pm.org | http://moscow.pm.org