четверг, 23 июня 2011 г.

Запускаем Mojolicious/PSGI приложение: мини-тест производительности.

Решил провести небольшое тестирование производительности Mojolicious  в разных режимах:
  1. Mojo::Server::Daemon (Epoll/Poll)
  2. Mojo::Server::Hypnotoad (Epoll/Poll)
  3. Mojo::Server::PSGI + Corona
  4. Mojo::Server::PSGI + Starman
  5. Mojo::Server::PSGI + Starlet
  6. Mojo::Server::PSGI + Plack::FCGI::Handler
Хотелось еще протестировать nginx+uwsgi, но не сложилось. Возможно в следующий раз.


Как проводилось тестирование 
Тестировалось приложение, которое просто возвращает строку "OK". Также, в тех же условиях, тестировалось минимальное PSGI приложение. Основной задачей было узнать наиболее производительный режим запуска. 
Все запросы к приложению проксировались через nginx - 4 воркера по 1024 конекшенов максимум. Тестировалось при помощи утилиты "ab". Результат считался как среднее арифметическое по 3 запускам теста. 10000 запросов на тест.

Результаты
Победителем оказался Plack::FCGI::Handler, что в общем-то очень предсказуемо. Plack::FCGI::Handler -  это обвязка  вокруг FCGI.pm и FCGI::ProcManager предназначенная для запуска PSGI приложений.

Результаты смотрим в таблицах:
"W" - количество воркеров
"C" - количество конкурентных запросов(параметр "-c" утилиты "ab")

Mojolicious::Lite

W=1 C=1
W=1 C=50
W=15 C=1
W=15 C=50
Mojo Daemon(Epoll)
611
686
-
-
Mojo Daemon(Poll)
618
709
-
-
Corona
715
806
-
-
Starman
700
733
503
1357
Starlet
591
639
510
1305
Plack::FCGI::Handler
811
857
595
1729
Hypnotoad(Epoll)
547
628
402
892
Hypnotoad(Poll)
563
647
409
1083


Minimalistic PSGI

W=1 C=1 W=1 C=50 W=15 C=1 W=15 C=50
Corona 2106 3128 - -
Starman 2823 3223 2596 5667
Starlet 1796 2183 1540 4852
Plack::FCGI::Handler 3282 3950 2596 7194


Естественно тест синтетический и не претендует на истину в последней инстанции(особенно это касается Poll/Epoll, Hypnotoad). Кто хочет, тот проведет для себя индивидуальное тестирования в соответствии с собственными задачами. По правильному нужно делать так - On HTTP Load Testing.
Лично я рекомендую использовать либо Plack::Handler::FCGI, либо Starman. В обоих случаях вы получите хорошую производительность и Copy-On-Write(в Linux). 

Исходники
Приложение на Mojolicious::Lite:
use Mojolicious::Lite;

get '/' => sub {
  $_[0]->render_text('OK');
};

app->start;

Минимальное PSGI приложение:
sub { [200, ['Content-Type'=>'text/html'], ['OK']] }

Скрипт для запуска приложения в режиме FCGI:
use Plack::Handler::FCGI;
use Plack::Util;

my $server = Plack::Handler::FCGI->new(
      nproc  => 15,
      listen => [ '127.0.0.1:5000' ],
      detach => 0,
);

$server->run( Plack::Util::load_psgi "app.pl");

Конфигурация системы
mojo version
CORE
  Perl        (5.012003, linux)
  Mojolicious (1.44, Smiling Face With Sunglasses)

OPTIONAL
  IO::Epoll                (0.02)

uname -a
Linux koorchik 2.6.38-gentoo-r1 #1 SMP PREEMPT 
Wed Mar 30 00:10:06 EEST 2011 
x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

29 коммент.:

sugar комментирует...

Да, интересно, спасибо, хоть и предсказуемо.

Вот тут я делал похожее тестирование на ответ от такого же минимального приложения между Twiggy(веб-сервер на AnyEvent), HTTP::Server::Simple::PSGI и node.js. Результаты отсортированы по убыванию.

koorchik комментирует...

>Результаты отсортированы по убыванию.
Да, AnyEvent хорош. Меня иногда удивляет, когда говорят, что node.js в сотни раз быстрее Perl :)

sugar комментирует...

Меня это тоже удивило, не поверил, решил проверить. Вот и итог. =)
Кстати интересно, что, в "node.js" используется "libev", как event-loop, которую написал автор "AnyEvent", в котором она и используется (не всегда правда).

Если честно, хотел побольше тестирование провести, да никак не соберусь. =((

koorchik комментирует...

Про libev в node.js знал, но то, что Marc Lehmann автор libev - реально неожиданно :)

Анонимный комментирует...

koorchik спасибо за статью, интересно

sugar судя по твоим тестам twiggy уделывает ноду, хотя все твердят наоборот ...

Анонимный комментирует...

Негусто как-то у всех: макс всего 7000 запросов в секунду. На Си нужно писать, тогда будет 140000 з/c на том же "hello world"
http://forum.gwan.com/index.php?p=/discussion/217/g-wan-vs-varnish-apache-traffic-server-nginx-lighttpd

koorchik комментирует...

>Негусто как-то у всех: макс всего 7000 запросов в секунду. На Си нужно писать, тогда будет 140000 з/c на том же "hello world"
Возможно Вы пишете веб-приложения на C, но я больше склоняюсь к динамическим языкам. Кроме того, в реальной жизни приложения немного сложнее чем "hello world". Скорее всего, упремся в базу данных уже на нескольких тысячах запросах в секунду.
Более того, во всех тестах используется nginx как reverse proxy. И статика будет отдаваться через него с намного большей скоростью.

Анонимный комментирует...

В базу конечно упретесь, если пишете не на Си:
вот например человек выжал 750000 з/c из MySQL
http://l-o-n-g.livejournal.com/153756.html
В общем все что сэкономите на разработке про..те
потом на дорогом хостинге, так как вместо одного сервера вам их потребуется 20.

Анонимный комментирует...

20 серверов - это я конечно загнул - оно же наверное линейно не масштабируется, т.е. и 100 серверов не помогут

Анонимный комментирует...

"В общем все что сэкономите на разработке про..те
потом на дорогом хостинге, так как вместо одного сервера вам их потребуется 20" - а вы всё, что сэкономите на серверах потеряете на оплате разработки и на сроках разработки. И в итоге ваше долгоиграющее ПО никому не нужно будет через сто лет. Удачи с архаичным CTPP во времена передового и универсального XSLT. (Кстати кто у вас шаблоны верстает? Прогеры?)

koorchik комментирует...

Не хочу Вас обидеть, но ваши рассуждения на уровне школьника, в лучшем случає студента, который не имел практического опыта создания более менее сложных проектов. Про написание высоконагруженных приложений я вообще молчу.
Я не спорю, что HandlerSoсket достаточно интересная вещь, но инструмент выбирается в зависимости от задач. И поставить 20 серверов вместо 2-х может быть значительно выгоднее чем писать веб приложиние на C.

Анонимный комментирует...

Версия 1 (прототип) был сделан на рельсах и даже какое-то время поработал в Production, но требовалось его ускорить примерно в ... 100 раз.
Естественно про 100 серверов не могло быть и речи :) Ничего лучше не придумали как изобрести велосипед, т.е. полностью всю архитектуру.

Application Server на С++, кеши на C++ (локально держат 5 миллионов запросов в секунду) - все написали сами.

"Морду" естественно рисует WEB программист, ему на выбор есть xslt+xml или js+json: сервер выплевывает данные в любом формате. Отрендерить их можно как на клиенте, так и на отдельном сервере.

С базой работает программист БД. Ему тоже C++ знать не нужно, достаточно положить все в нужное место и оно подхватится AS. В итоге получилось что-то типа MVC и 4х звенная архитектура.

Любой из узлов, включая БД, линейно масштабируется. Срок разработки 2 версии составил всего 3 месяца. Теперь с клиентом очень долгосрочные отношения и конкурентам просто не подступиться.

А все почему-то боятся изобретать велосипеды, а может быть просто не умеют.

koorchik комментирует...

Как я вижу, Вы и сами понимаете, что инструмент выбирается в соответствии с задачами, возможно в вашем случає С++/XSLT оправдан. Озвучиваете задачу и обосновуете выбор C++. А то что было до этого - чистой воды троллинг. Это как прийти на форум автомобилистов и сказать, что покупать автомобиль - это полный бред, он даже не может лететь со скоростью 700 км/час, покупайте МиГ-29 на нем вы и на дачу и за грибами сможет летать.

С велосипедами полностью аналогично, их изобретать никто не боится, просто в этом должен быть смысл.

Анонимный комментирует...

Согласен, извиняюсь, погорячился. Но это позволило нам в свое время выйти с мелких проектов на enterprise уровень, где уже платят миллионы долларов, при этом очень скромно в это вложив. Сейчас конечно наши внутренние технологии стали еще проще в освоении (главное не бояться их изобретать), например, структуры данных и WEB интерфейс генерируются автоматически по описанию, которое может составить сам заказчик,
для сего изобретен свой удобный метаязык. И многое другое. Возможности интеграции таковы, что мы легко объединяем свои и чужие интерфейсы.
В кризис удалось удалось подхватить несколько крупных заказчиков (к сожалению из назвать не позволяет NDA) благодаря следующей стратегии (опишу лишь в общих чертах) - приходишь условно говоря к CIO (а у него конечно в кризис стоит задача снизить издержки) и говоришь: ваш cost of ownership ваших бизнес приложений составляет, например, 8 mln $, мы можем заменить его часть своим софтом и cost снизится за первый год на $2 mln $ и так далее в течении 4-х лет, при этом ничего не отвалится, а будет даже лучше, за это мы хотим половину секономленной суммы, т.е. 1 mln $. Врядли это можно предложить не имея такого козыря в кармане, как большой запас по производительности (+ конечно технологии интеграции).
Был даже случай, когда заказчик в результате заменил милионный суперсервер на сервер уровня моего домашнего ПК, а тот сервер поставил в ЦОД в аренду для других.

Сейчас подумываем поделиться некоторыми наработками с сообществом - отдать их в opensource. Ведь там куда не плюнь - почти все сделано тяп-ляп, чего не перепишешь - сразу начинает на порядок быстрее работать. Возможно это заговор больших компаний ? :)

Анонимный комментирует...

Shit, нужно перечитывать что пишешь, конечно "2х лет". Иногда даже удается снизить TCO в 4 раза, при этом заменив только 5-20% софта, тут главное хороший анализ в поиске узких мест.

koorchik комментирует...

Всегда рассматривал кризис, как время возможностей :)
Интересно было бы почитать про ваш продукт и компанию. Можете дать ссылку?

Анонимный комментирует...

Очень хочется рассказать но сейчас нельзя: идут переговоры с настоящими монстрами "о сотрудничестве", чтобы под этим не подразумевалось.
А когда нельзя, то хочется рассказать еще больше. Поэтому наверное я что-то (лишнее) и написал в этот блог :)
P.S. Готовится нечто грандиозное, почти революция в технологии, когда падут мировые гранды :) Тогда уже все о нас узнают. Эх амбиции..., но пока что все получалось. Все... ухожу пока еще цел и не почти не проболтался.
P.P.S. Sorry, я немного пьянъ.

Анонимный комментирует...

P.P.P.S. Забудьте про меня, а еще лучше потрите мои сообщения из блога, все слишком серьезно
Спасибо!

Анонимный комментирует...

Кстати это француский товарисч, который пишет GWAN - он же его в одиночку пишет и скоро прикрутит туда scgi, тогда будет у вас счастье с Perl. Но один конечно в поле не воин, вот и нам приходится примкнуть к паровозу - нужны очень большие деньги для реализации задуманого.

P.S. Подыщал свежим воздухом, перечитал, вроде ничего лишнего не сболтнул, так что можете не стирать... или стирайте, так как это уже пошло что-то личное не на тему блога. Вобщем сами решайте. А я завтра проверю :)

koorchik комментирует...

Могу Вам пожелать только удачи.

Это блог, а не научная работа, тут не обязательно все должно соответствовать предмету исследования. :)

Анонимный комментирует...

Переговоры прошли, немного разочарован: договорились пока на небольшой проект, выпускаем его под чужим брендом, денег не горы, обнадеживает только, что десятки миллионов пользователей начнут это активно использовать уже через 3..6 месяцев. Проект по прежнему засекречен, но когда он заработает, об этом, думаю, напишут почти все издания, так как такого сервиса в России (а может даже и в мире) еще никто не предлагал. Тогда и посмотрим...

Анонимный комментирует...

Смешной момент - нашей оценке требований к оборудованию не очень поверили, будет заказано оборудование с 8-кратным запасом (притом мы уже туда 3-кратный заложили) - вот насколько сильны традиции php и прочего slowстроения.

Анонимный комментирует...

Если кто за нас уже переживает - не переживайте, мы основные козыри еще не выкладывали, это не та революция, о которой я говорил, хотя тоже хорошая и главное простая, даже очевидная идея, но пропробовал сейчас нарыть аналоги - нет, не нашел, даже странно все это как-то. Друзья, мыслите шире, смешивайте и взбалтывайте, пробуйте на вкус - может получиться отличный рецепт.

Stanislav комментирует...

Здравствуйте, Виктор.
Я немного не по теме. Не могли бы вы поделиться скрипт для запуска Mojolicious-приложения под psgi?

Если использовать команду типа: plackup --server Starman --workers 2 --port 3000 -R templates script/simple_c_m_s

То сервер отключается после выхода из терминала.

С уважением.

Stanislav комментирует...

Разобрался, надо было запускать с ключом -D.

TheAthlete комментирует...

Здравствуйте!
Не подскажите, как Вы применяли IO::Epoll в своей программе? И для чего нужен этот модуль (в контексте данной задачи)?

koorchik комментирует...

В контексте данной задачи этот модуль нужен для сравнения его с другими модулями. То есть задача была - посмотреть на производительность разных решений.

IO::Epoll использовался в Mojolicious. Mojo::Server::Daemon - неблокирующий сервер и ему нужен какой-то механизм уведомления о том, что с сокетами можно работать (например, когда появились данные). Для этого сервер использовал select/Epoll/Poll. Последние версии используют либо IO::Poll, либо EV.

Алексей комментирует...

Ау! Аноним с мегасофтом, как там революция? Интересно же.

Анонимный комментирует...

ага) тоже кричу АУ!

Отправить комментарий

Не забудьте добавить себя в постоянные читатели и включить уведомления о новых комментариях, либо воспользуйтесь RSS каналом ;)