Экономится память, в первую очередь. Например фронтенд на каждый запрос ходит к медленному бэкенду и ждёт от него ответа. Вопрос, как организовать работу фронтенда. Если каждый запрос будет обрабатываться отдельным однопоточным не асинхронным процессом, то когда число одновременных запросов превысит число процессов, запросы начнут выстраиваться в очередь, что для пользователей означает тормоза. Решение в лоб - добавить число процессов. Но каждый из них потребляет память, которая не резиновая.
Альтернативы - потоки, асинхронный код, либо и то и другое вместе. Потоки лучше, чем асинхронный код, потому что они будут выполняться на разных ядрах. Асинхронный код лучше тем, что не надо сохранять состояние процессора при переключении. В многопоточном коде надо заботиться о блокировках общих ресурсов, сложно разделять данные между потоками (общие пулы соединений к базе, общие кэши и т.д.) Самое эффективное - это и то, и то вместе, если оно правильно реализовано в самом языке. Иначе - это кромешный ад, с которым лучше не связываться. В Perl - именно такой случай. Асинхронный код - это имхо лучшее, чего можно добиться от перла. On Sun Feb 08 2015 at 19:35:28 Daniel Podolsky <[email protected]> wrote: > о! собеседник! > > >> > Ага. В этом смысле асинхронный подход ближе к реальности. > >> вам ближе к реальности или деньги зарабатывать? > > Смотря чем зарабатывать. Есть много задач, где асинхронный код позволяет > > сильно сэкономить ресурсы серверов. > а вот давайте разберемся, какие именно ресурсы серверов позволяет > сэкономить асинхронный код, и справедливо ли это утверждение для > асинхронного кода на перле. > > изложите, пожалуйста, тезис об экономии подробнее. а то я так много об > этом думал, что мгновенно начинаю с демонами в своей голове > разговаривать, как об асинхронном перле речь заходит :( > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
