Сравнение производительности php: FreeBSD vs Gentoo Linux

Эпично.

Сейчас Изя расскажет.

Делаем правильно: sudo cast iZEN.

FreeBSD 10-STABLE

Их много. В каком месяце собрана хотя бы?

Сразу скажу, что на обеих ОСях php собран одной версией компилятора, одинаковыми модулями и с теми же CFLAGS.

Какой версией? И какого компилятора? Во FreeBSD дефолтный LLVM/Clang 3.3, вообще-то, а все другие, что не по дефолту, — это ваши руки и сексуальные фантазии.

А я, вот, в процессе тестинга php vs ruby, короче php сливает последней сборке ruby dev 2. Я не фанат руби, скорее наоборот, я за питон) Но. Интересно всё-таки было… Кто прав. Слив примерно 20-40% req/per sec. Unicorn / php-fpm + nginx. Вообще, обожаю тесты, но много времени уходит на их реализацию, я уже согнал в кучу за неделю около 7-8 различных платформ :D

Я знал!

Спасибо, интересно.

JRuby, значит, вообще летать будет.

Ну, смотря что считать «летать», JavaGrails работает в 4-5 раз быстрее нативного ruby, соответственно, JRuby примерно так же. Быстрее только NodeJS и Erlang :) Ну, и, конечно, же порвал всех vibe.d, который на libevent c++

Их много. В каком месяце собрана хотя бы?

Я его часто обновляю с иллюзорной надеждой что хоть что-то поменяется :)

# uname -a
FreeBSD node2 10.0-BETA3 FreeBSD 10.0-BETA3 #20 r258721: Thu Nov 28 23:29:13 EET 2013     root@node2:/usr/obj/usr/src/sys/TG_NODE_10  amd64

Какой версией?

php55-5.5.5

И какого компилятора?

gcc-4.7.4

Во FreeBSD дефолтный LLVM/Clang 3.3, вообще-то, а все другие, что не по дефолту, — это ваши руки и сексуальные фантазии.

При сборке с Clang 3.3 ситуация никак не меняется. Я изначально и собрал при помощи его. Потом думал что возможно причина в компиляторе и пересобрал той же версией gcc, что и на линуксе, с теми же флагами: -O2 -pipe -march=native -mmmx -msse4.2

Быстрее только NodeJS и Erlang

Да ладно! Памяти меньше уходит, да, а вот про то что быстрее как-то сомнительно. Или вы сравниваете руби как рельсу?

это война

Вообще, обожаю тесты, но много времени уходит на их реализацию, я уже согнал в кучу за неделю около 7-8 различных платформ :D

Могу дать доступ к https://github.com/Balancer/benchmarks-fib-obj

Там можно и другие тесты замутить :)

Я сравниваю сколько запросов в секунду выдаёт приложение по HTTP. Erlang и Node.JS быстрее Java Grails и Java Jetty в 2 раза. Если вы о Ruby то да, руки дошли только до RoR, но и Grails Java - это тоже клон RoR на Groovy. Т.ч. сравнение вполне честное. В понедельник-вторник буду тестить Sinatra.

Сразу скажу, что на обеих ОСях php собран одной версией компилятора

Между тем, все знают, что ГНУтый компилятор подыгрывает Линуксу, выполняя больше оптимизаций. Иначе чем можно объяснить тот факт, что один и тот же код выполняется за разное время? Очевидно, код не один и тот же, а разный.

Спасибо. Там на гит тесты производительности мат аппарата, я же тестирую фактическую выдачу отрендеренного HTML из БД, прошедший через шаблонизаторы фреймвёрков, либо внешних шаблонных движков типа Mako для Python и Jade для Node.JS. Плюс задействуется ORM, там, где она втроенна в фреймворк. Либо беру самую популярную ORM для данной платформы, например, для Flask - Alchemy.

Там на гит тесты производительности мат аппарата

Фактически тестируется именно работа с объектами (то, на что сегодня уходит львиная доля загрузки в моих Web-задачах. Считая, что БД тормозит примерно одинаково).

я же тестирую фактическую выдачу отрендеренного HTML из БД, прошедший через шаблонизаторы фреймвёрков, либо внешних шаблонных движков типа Mako для Python и Jade для Node.JS. Плюс задействуется ORM, там, где она втроенна в фреймворк.

Ну так отлично же. Я когда-то хотел такое затеять, да руки не дошли, в отличие от упомянутого выше, тут требуется серьёзно ковыряться с фреймворками: https://bitbucket.org/Balancer/frameworksbench

Что плохого в Django? (комментарий)

Лол, так логично что нода обработает больше запросов.

А с каким libc собиралось? Во фре, по-моему, какой-то свой, оттуда и разница. Пересобери с glibc - скорее всего разница исчезнет.

З.Ы. А как поменяется картина, если включить SELinux?

Конечно, но хотелось точно померить на сколько! =) К тому же, на ноде не только запросы обрабатываются, но и роутинги и т.п.

Интересно, если с настройками JVM поиграться в сторону фиксации максимально возможного размера кучи (-Xms4096m -Xmx4096m) и выбора сборщика мусора G1 (-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:GCPauseIntervalMillis=500), насколько улучшатся результаты?

Кстати, замена старого рантайма C/C++ во FreeBSD на новый GNUтый описана тут: http://www.freebsd.org/doc/en/articles/custom-gcc/article.html

Я как-то проделывал подобную операцию, чтобы проверить, насколько ускорится работа десктопных приложений (после перекомпиляции всего установленного ПО с новыми рантайм-либами), но разницы не почувствовал.

libc то разные!
собери eglibc под фрю иди uclibc под обоих
и заюзай гцц вместо шланга

nginx+uwsgi_php55

А почему не php-fpm? В чем профит uwsgi?

А с каким libc собиралось? Во фре, по-моему, какой-то свой, оттуда и разница.

Собиралось с дефолтным.

# ldd `which php`
/usr/local/bin/php:
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x800b6a000)
	libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x800d8a000)
	libm.so.5 => /lib/libm.so.5 (0x800ff1000)
	libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x801216000)
	liblzma.so.5 => /usr/lib/liblzma.so.5 (0x801575000)
	libz.so.6 => /lib/libz.so.6 (0x801798000)
	libthr.so.3 => /lib/libthr.so.3 (0x8019ad000)
	libc.so.7 => /lib/libc.so.7 (0x801bd2000)
	libgcc_s.so.1 => /usr/local/lib/gcc47/libgcc_s.so.1 (0x801f6d000)

Пересобери с glibc - скорее всего разница исчезнет.

А разве можно под фрей собрать линуксовый glibc? Именно собрать а не юзать древнее бинарное Г от федоры.

З.Ы. А как поменяется картина, если включить SELinux?

На линуксе, я так понимаю? Подобной дрянью не хочу засорять систему. Цель ОСи в кластере - выдавить максимум из железа. По сему там вся система собрана с:

CFLAGS="-O2 -pipe -march=native -mtune=core-avx-i -msse4.2 -mmmx -mfpmath=sse,387 -g0 -Wno-all -flto=8 -fuse-linker-plugin -fopenmp -floop-parallelize-all -ftree-parallelize-loops=8 -funroll-loops -funroll-all-loops -ftree-vectorize -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -fgraphite-identity"

З.Ы. Просьба не разводить срач по поводу source-based дистрибутивов, оптимизаций и прочего. В любом случае каждый останется при своим мнении. Каждый выбирает инструмент под себя. Каждый из нас верит в то, во что верит... :)

А почему не php-fpm? В чем профит uwsgi?

Вы почитайте какие фичи есть у uwsgi и fpm, проведите тесты. Прежде чем приступать к решению задачи, я тестирую все доступные инструменты. Тот, который оказывается быстрее всех - тот и юзаю. Лично для моих задач, uwsgi оказался 1) чуток быстрее чем fpm (конечно, если его правильно «приготовить») 2) имеет кучу полезных фич, которых fpm лишен. Самое существенное для меня это возможность задавать нужное количество тредов и воркеров + автоматический спавнинг их по алгоритму busyness, слежение воркеров за потреблением памяти процессов и автоперезапуск при утечках, авто релод воркеров после определенного количества выполненных процессов, слежение за состоянием процессов (если кто-нить завис - прибивает и спавнит новый), emperor который заменяет дополнительную сущность в виде HeartBeat. Помимо всего этого есть множество плюшек.

Спасибо, пропишу и отпишусь на след. неделе.

А что за модуль uwsgi вы юзаете на стороне веб сервера? 100% nginx. Наверное, и модуль там стандартный есть для uwsgi.

Да хватит здесь жабу обсуждать. Лучше подскажите как фрю ускорить. А то тимлид у меня на работе всю жизнь свято верит что лучше фри нету ничего. Он же повесится когда я ему покажу график аббикса по количеству потребления CPU фри-ным серверов в соотношении к количеству обработанных запросов нашего приложения :)

А разве можно под фрей собрать линуксовый glibc?

Выше iZEN писал ссылку: http://www.freebsd.org/doc/en/articles/custom-gcc/article.html. Вобщем, топик можно озаглавить «glibc vs bsd libc»

Подобной дрянью не хочу засорять систему.

Просто интереса ради. Понятно, что если цель - максимальная производительноть, SELinux там не будет

Просьба не разводить срач по поводу source-based дистрибутивов

Как можно? Мы же на ЛОРе! Настоящему джентельмену такое даже в голову прийти не может!
*поправил монокль

А что за модуль uwsgi вы юзаете на стороне веб сервера? 100% nginx. Наверное, и модуль там стандартный есть для uwsgi.

Весь удар на себя принимает nginx, у него саме быстрые веврайты (по моим личным тестам). Правда у uwsgi есть возможность и реврайты писать (точнее роуты). Если урл ведет к динамике, по TCP коннектится в haproxy, который балансирует нагрузку между парком бекендов с запущенными uwsgi. Сессии находятся в редисе на фронтенде. emperor будет висеть отдельным процессом на фронтенде и всех бекендах, один из которых, в зависимости от веса, станет фронтендом в случае падения последнего. Но всю эту структуру я еще не до конца внедрил, все еще на стадии тестирования.

а если линуксовые бинарники на фре через линуксулятор запустить?

замена старого рантайма C/C++ во FreeBSD на новый GNUтый

А какой смысл вообще использовать фрю, если всё равно придётся менять libc на столлмана-поделку?

Выше iZEN писал ссылку: http://www.freebsd.org/doc/en/articles/custom-gcc/article.html. Вобщем, топик можно озаглавить «glibc vs bsd libc»

Где там *libc по ссылке? Там стандартная процедура установки gcc и binutils которая выполняется перед установкой портов. У меня все порты именно так и собраны. Что касается libgcc_s.so.1 и прочего, оно автоматом добавляется в /etc/libmap.conf после установки gcc. По сему, я до сих пор не могу понять о каком glibc под фрей идет речь.

Просто интереса ради. Понятно, что если цель - максимальная производительноть, SELinux там не будет

SELinux это редхатовская приблуда, которую почти все сразу же выключает когда начинает что-то глючить. :) Для Gentoo оно есть, но прилеплено скотчем. По сему, не так хорошо интегрировано в систему как в шапке. Да, взяв напильник в твердую админскую руку его можно прилепить. :) Но смысла в этом 0.

А какой смысл вообще использовать фрю, если всё равно придётся менять libc на столлмана-поделку?

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

Ты тестируешь производительность phpinfo()? Самому не смешно?

А я хотел фряшеньку поставить =\

Ты тестируешь производительность phpinfo()? Самому не смешно?

Не смешно, так как производительность php под фрей на тяжелом движке по отношению в линуксу примерно эквивалентна скорости выполнения phpinfo. Трейс именно phpinfp я и привел как пример. Я же не буду здесь выкладывать трейс движка на десятки а то и сотни страниц текста.

А я хотел фряшеньку поставить =\

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

И тут еще один вопросик:

А как фряха ведет себя при своппинге? Лялекс вымораживает своими лагами при своппинге. Жутко раздражает.

Не смешно

Я зря. Покажи оба вывода phpinfo().

Трейс именно phpinfp я и привел как пример.

Я не вижу в трейсе линукса, где читается сам info.php, наверное стар стал. :( Трейсы не одного и того же приведены, сравнивать их глупо.

Лялекс вымораживает своими лагами при своппинге
Лялекс

к логопеду! А лаги при своппинге будут всегда если раздел со свопом на каком-то убогом диске.

А как фряха ведет себя при своппинге? Лялекс вымораживает своими лагами при своппинге. Жутко раздражает.

ИМХО, если сервер свопится - это значит то, что существующие ресурсы системы распределены неправильно по отношению к требованию, выдвигаемым к производительности сервера - как вычислительной единицы всей системы серверов. Следовательно, я не допускал чтоб сервак залазил в своп. По сему, я не знаю как фря себя ведет в таких ситуациях. Пускай лучше кто-то другой ответит.

имеет кучу полезных фич, которых fpm лишен. Самое существенное для меня это возможность задавать нужное количество тредов и воркеров + автоматический спавнинг

Это же есть в php-fpm. А ля:

pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

их по алгоритму busyness

Разве что про алгоритм ничего не знаю.

слежение воркеров за потреблением памяти процессов и автоперезапуск при утечках

Зачем оно при авторелоадах?

авто релод воркеров после определенного количества выполненных процессов

pm.max_requests = 500

слежение за состоянием процессов

Аналогично не нужно при авторелоадах.

Угу, все три диска убогие. Очень убедительненько.

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c628

Читай коммент. И да, отключение свопа - это костыль.

Я зря. Покажи оба вывода phpinfo().

FreeBSD
Gentoo
По началу думал что разница в производительности из за того, что во фре пых собирается модульно. В генте вродь идет только монолит с возможностью вкл/выкл при помощи USE. Собрал во фре пых ручками и теми же флагами компиляции, но ситуация не изменилась. Плюнул, и собрал обратно с портов. Единственное, пришлось во фре увеличить количество памяти, так как по не ведомой для меня причине, php процессы во фре жрали больше памяти чем в линуксе на нашем движке. Профилировать и искать причину лень. Еще во фре добавил три модуля: sysvmsg, sysvsem, sysvshm. Правда они какой погоды не сделали.

Сильная сторона Gentoo - ядро Linux, слабая - ресурсоёмкое DE. Сильная сторона FreeBSD - ZFS.

Разве что про алгоритм ничего не знаю.

http://uwsgi-docs.readthedocs.org/en/latest/Cheaper.html?highlight=busyness

Зачем оно при авторелоадах?
Аналогично не нужно при авторелоадах.

Если воркер завис, то он находится в состоянии busy и не принимает новые коннекшины. И следовательно, он никогда не достигнет точки авторелода.

И следовательно, он никогда не достигнет точки авторелода.

Хм. Логично. Тогда странно, что я за несколько машинолет с php-fpm на нагруженных проектах с этим никогда не столкнулся. То ли повезло и мой фреймворк никогда не зависает, то ли php-fpm, всё же, с этим как-то борется.

слабая - ресурсоёмкое DE.

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

Сильная сторона FreeBSD - ZFS.

Не только. К примеру, тестил при помощи sysbench и оказалось, что с mutex-ами работает в 2 раза быстрее чем линукс, с тредами почти на ровне, по скорости памяти проигрывает. Понятное дело, что один лишь sysbench не является объективным показателем. Но устраивать зоопарк тестов лень. И так много времени на все это дело убил.
TCP стек - просто сказка. Правда параметры по дефолту низкие, без напильника никак. Пришлось помучиться чтоб завести на полную 10Gbe карточку. Кстати, линукс искаробки эту карточку пригрузил. С дровами на экзотическое железо хреново. Возможности дебага и мониторинга ресурсов, работа с оперативкой, выделение/разделение ресурсов, контроль прерываний и прочее мне показалось продвинутее чем в линуксе. К примеру, «systat -vmstat», «top -aSCHIPz» и «vmstat -z» показываю практически все что нужно знать о производительности системы. Как для роутера без сложной приоретизации трафика и файлопомойки подходит идеально. Еще бы решить проблему со скоростью php и можно загонять в кластер :)

То ли повезло и мой фреймворк никогда не зависает, то ли php-fpm, всё же, с этим как-то борется.

Такое бывает не часто. Но если идет активная разработка движка, то не всегда получается отловить все глюки при тестировании. Порой этот функционал очень спасает на продакшине.