Comments 55
Что использовалось в качестве транспорта в phpd? HTTP или FastCGI? Что было спереди — nginx? Соединение через unix-socket?
У нас phpDaemon отдает до 2600 rps, и это не предел, это при работе с MongoDB и сложной логикой выполнения запроса. А у вас цифры несколько смешные…
У нас phpDaemon отдает до 2600 rps, и это не предел, это при работе с MongoDB и сложной логикой выполнения запроса. А у вас цифры несколько смешные…
Удивили более чем достойные результаты phpDaemon. Если учесть тот факт, что phpDaemon не компилируется, то его производительность очень хороша.
А на каком железе это тестировалось и что всякие *top показывали, где кто затыкался?
интересно было бы посмотреть результаты с APC
Node надо запускать по воркеру на каждое ядро проца. Дает +110% к производительности.
У вас только один процесс? В статье не указано.
У вас только один процесс? В статье не указано.
а как же тест на 5 и 10 тысяч потоков?
А к чему эта фотография Рэя Остина и Орландьера Солиса?
Ваш проект как то связан с боксом?
Ваш проект как то связан с боксом?
Ещё не хватает данных, через сколько минут (часов) phpdaemon загнётся из-за багов и утечек.
Это предположение или вы делали подобное тестирование?
мы этим пользовались к сожалению :)
Не используйте php в качестве демона. Все очень точно подмечено. php отваливается по неизвестным причинам. Уже более 2 лет работает чат на проекте и проблемы решить так и не удалось, при том что библиотеки были переписаны с нуля, 100% контроль, нет привязки к каким-либо сторонним библиотекам где непонятно кто и что писал.
Я видел ваши исходники, у вас просто кривые руки =) И это не связано с самим phpdaemon'ом.
Странные у Вас тесты.
Исходя из данных: чем больше соединений тем быстрее становится Node.js — то есть при повышении нагрузки Time per request стремится к нулю и растет Requests per second.
Мне так же не понятно как при повышении числа соединений до 1000, сохранении Min request (почти без изменений) и увеличении Max Request (почти в два раза) получилось обработать больше запросов чем при 10.
Либо у Вас ошибка в измерениях, либо я чего-то не пониманию.
Исходя из данных: чем больше соединений тем быстрее становится Node.js — то есть при повышении нагрузки Time per request стремится к нулю и растет Requests per second.
Мне так же не понятно как при повышении числа соединений до 1000, сохранении Min request (почти без изменений) и увеличении Max Request (почти в два раза) получилось обработать больше запросов чем при 10.
Либо у Вас ошибка в измерениях, либо я чего-то не пониманию.
Еще интересно какая версия NodeJS использовалась.
Погодите… 50-60 запросов в секунду??? по 15 мс на запрос? Из PHP в виде демона совершенно точно можно выжать намного больше, даже из простого Apache+mod_php можно выжать пару тысяч запросов в секунду при «легких» обработчиках. ИМХО, что-то вы делаете не так, или же цифры неверные приведены
Зачем городить огород с хттп-костылями для риалтаймовых сервисов? HTTP вряд ли годится для таких вещей, а комет — хак, нужный вообще непонятно для чего.
Нет ничего приятнее, чем сочинять подобного рода быстрые вещи на RTMP с его нормальным RPC. На сервере Red5, на клиенте — прокси флешка, из которой в сторону JS свисает пачка методов, все просто и логично, ня.
Нет ничего приятнее, чем сочинять подобного рода быстрые вещи на RTMP с его нормальным RPC. На сервере Red5, на клиенте — прокси флешка, из которой в сторону JS свисает пачка методов, все просто и логично, ня.
Насколько я понял, juggernaut использует те же транспорты, что и socket.io. Поэтому не вижу особого смысла связываться с первым, у которого реализована своя модель работы «каналы-подписки» завязанная на Redis, учитывая, что автор использует mongoDB.
Но за ссылку спасибо, добавил в закладки, возможно пригодится.
Но за ссылку спасибо, добавил в закладки, возможно пригодится.
Я к тому, что уже всё реализовано. И не надо было городить велосипед, писать свои js, свой комет итд. Если монго используется только для хранения сообщений — тогда тем более без разницы что использовать. Только в случае с джагернаутом не надо ничего придумывать. Всё уже готово и отточено. Да не совсем понятно зачем делать монго как буфер для отправки сообщений — можно сразу валить их на джагернаут(если его использовать).
Комет реализован и тут и там сразу. У MongoDB и Redis разные парадигмы — что может быть важно. Хотя в целом я с вами согласен, возможно автор как и я, просто не знал про jaggernaut.
Но ведь нет ничего плохого в том, что человек реализует этот функционал по-своему — вдруг потом выложит в opensource и будет альтернатива тому же jaggernaut'у, но уже под MongoDB + socket.io и с отличающимися от «каналы-подписки» принципами :)
Но ведь нет ничего плохого в том, что человек реализует этот функционал по-своему — вдруг потом выложит в opensource и будет альтернатива тому же jaggernaut'у, но уже под MongoDB + socket.io и с отличающимися от «каналы-подписки» принципами :)
Не понятно почему такие результаты. Почему сперва выигрывает первый, потом второй, потом опять первый?
меня впечатляют ваши цифры.
вероятно, тестирование проводилось на компьютере Intel Pentium 166 MMX, 32MB RAM, 1.6 GB HDD, я угадал?
вероятно, тестирование проводилось на компьютере Intel Pentium 166 MMX, 32MB RAM, 1.6 GB HDD, я угадал?
Да, на простом ноуте. Но тесты, которые ставят перед собой цель получить абсолютные цифры, мне всегда были немного странны. Они делаются именно для сравнения различных технологий — для этого важно обеспечить одинаковость условий, а не идеальные условия.
абсолютных цифр и не надо. просто, на мой взгляд, для тестирование серверного ПО нужно использовать серверное аппаратное обеспечение, ну т.е. какой-нибудь типичный серверный процессор (ксеон или коре2квад), типичное количество памяти.
на моём домашнем сервере на Atom 330 (который ну никак нельзя назвать серверным процессором) я получаю те же 50-70 rps в самом обычном php-fpm + mysql, поэтому ваши цифры кажутся мне немного странными. ведь у вас они должны быть на порядок выше.
кроме того, нельзя просто взять и сравнить. то есть можно, но нужно ещё показать, что результат получился объективным, а не зависит от каких-то случайных факторов. т.е. монго вынести на отдельную машину и убедиться, что вы меряете производительность именно ноды и пхпдемона, а не монго, отключить везде логи, ну и т.д. убедиться, что время, которое вы меряете, это время работы ноды и пхпдаемона, а не время работы чего-то ещё.
на моём домашнем сервере на Atom 330 (который ну никак нельзя назвать серверным процессором) я получаю те же 50-70 rps в самом обычном php-fpm + mysql, поэтому ваши цифры кажутся мне немного странными. ведь у вас они должны быть на порядок выше.
кроме того, нельзя просто взять и сравнить. то есть можно, но нужно ещё показать, что результат получился объективным, а не зависит от каких-то случайных факторов. т.е. монго вынести на отдельную машину и убедиться, что вы меряете производительность именно ноды и пхпдемона, а не монго, отключить везде логи, ну и т.д. убедиться, что время, которое вы меряете, это время работы ноды и пхпдаемона, а не время работы чего-то ещё.
Мне бы интересно было посмотреть результаты продолжительных тестов. Кто из подопытных первым загнется с протечкой или с дедлоком после суток нагруженной работы.
Talk is cheap. Show me the code. © Хотелось бы ваш чятик у себя попробовать — потестировать. Ну и код поразбирать на предмет косяков. Вдруг вы там на запросах к БД блокируетесь?
Еще интересно сколько каждый процесс занимал памяти при разных нагрузках.
И в завершении — не понял из статьи нафига вам MongoDB тут вообще? Типа если юзер заново подключился — ему кусок переписки за последние сутки прилетает? Или оффлайн сообщения (т.е. оффлайн-сообщения после суток удаляются)?
У меня пока что осталось только ощущение «сферического теста в вакууме».
Еще интересно сколько каждый процесс занимал памяти при разных нагрузках.
И в завершении — не понял из статьи нафига вам MongoDB тут вообще? Типа если юзер заново подключился — ему кусок переписки за последние сутки прилетает? Или оффлайн сообщения (т.е. оффлайн-сообщения после суток удаляются)?
У меня пока что осталось только ощущение «сферического теста в вакууме».
Почему запусаются одновременно оба демона?
Вы пробовали тестировать их поотдельности?
Вы пробовали тестировать их поотдельности?
хм, и почему не на erlang?
попробовали б модифицировать ejabbered, всетаки к задаче он имеет более близкое отношение
попробовали б модифицировать ejabbered, всетаки к задаче он имеет более близкое отношение
а почему среднее время на запрос оказалось меньше минимального времени на запрос?
Демон Time per request, ms Min request, ms
phpDaemon 18.440 21
Node.JS 15.618 16
…
Демон Time per request, ms Min request, ms
phpDaemon 18.440 21
Node.JS 15.618 16
…
Проверил свои старые наработки
Числа примерно в 20 раз лучше получились для обычного php+MySQL и не демона, и примерно в 100 раз круче если демона(phpDaemon)
Возможно смысл в более правильной архитектуре, заточенной именно под чат, а не просто так.
Не забываем что если вы шлете сообщение клиенту вы можете просто послать это сообщение клиенту(что нода что phpDaemon — event based. Сгенерите этот ивент и получите нулевой латенси реакции)
Числа примерно в 20 раз лучше получились для обычного php+MySQL и не демона, и примерно в 100 раз круче если демона(phpDaemon)
Возможно смысл в более правильной архитектуре, заточенной именно под чат, а не просто так.
Не забываем что если вы шлете сообщение клиенту вы можете просто послать это сообщение клиенту(что нода что phpDaemon — event based. Сгенерите этот ивент и получите нулевой латенси реакции)
Вы выжали 5500 реквестов в секунду к phpDaemon? ;)
чо-то мне подсказывает что у вас всё тестирование упёрлось в винт с MongoDB :)
Попробуйте сравнить с Beseda (более стабильный и быстрый аналог Socket.IO) на стороне nodejs
github.com/geometria-lab/Beseda
github.com/geometria-lab/Beseda
Sign up to leave a comment.
Нагрузочное тестирование: Node.JS vs phpDaemon