LINUX.ORG.RU

Golang в Revel и Gin-gonic почему-то работает медленнее PHP :-/

 , , , ,


0

1

Фигня какая-то. Делаю тут для изучения несложную задачку (взять html, подсунуть параметр из GET-запроса) на Golang. В результате, запросов в секунду:

* PHP (голый) — до 12000
* Golang/Revel — до 8700
* Golang/Gin-gonic — до 4800

Удивительно, во-первых, что Revel быстрее Gin'а, обычно считается наоборот. Но это ладно.

Вот каким макаром PHP получается быстрее — не понимаю. Т.е. цифра вообще какая-то нереальная в моём привычном мировоззрении... При чём не 7.0 какой-нибудь или hhvm, а обычный 5.4.45, fpm.

Может, фишка в том, что PHP используется классически, html-код со вставкой, который один раз компилируется и потом берётся из кеша, а golang-фреймворки так не умеют и производят чтение/парсинг на каждом запросе? Или вопрос в оптимизации многоядерности, т.к. у php-fpm уйма инстансов, грузящих все ядра, а у Revel/Gin собственный менеджер и фиг знает, как он там распределяет загрузку?

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Скорее измеряю, как PHP рождается и умирает. Это же одна из самых громких претензий к классическому PHP.

Потому что классический php - это модуль апача, со всеми отсюда вытекающими. А тут, насколько я понял, вполне себе php-fpm, который рождает php один раз на старте, ну и изредка убивает/запускает потоки потом. Про opcache уже написали. Так что пока всё логично.

Рекомендую попробовать потом писать демонов на PHP. Вот тут будет много удивительного.

WARNING ★★★★
()
Ответ на: комментарий от WARNING

Рекомендую попробовать потом писать демонов на PHP.

Этих-то я писал когда-то ещё во времена ~5.1 :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

на домашней машине с Gentoo
— php-fpm-5.6.17/hello world: 15 krps
— go-1.5.3/gin/hello world: 20 krps

Поставил вторым слотом php-7.0.3, получил 18.7 krps.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

На хелловордах можно и не такое увидеть. Например были тесты где Java рвет по производительности C++. В php же тут кэши решают я думаю.

Вы попробуйте тест сделать на реальной задаче. Например на запрос отдать число фибоначчи, или в базу там сходить селект дернуть. Понимаю тут будут издержки БД, но все равно. В среднем будет около.

abc
()
Ответ на: комментарий от abc

Вы попробуйте тест сделать на реальной задаче. Например на запрос отдать число фибоначчи

https://github.com/Balancer/benchmarks-fib-obj/wiki/Результат-теста:-i3-2.2ГГц

:)

Давно пора обновить версии, но в целом итак наглядно.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от WARNING

Ну это было больше похоже на мазохизм в те времена, имхо.

Мегапроизводительность не требовалась, а потенциальные проблемы утечек памяти старого сборщика мусора я решал тупо форками :) Каждый запрос просто форкался, по завершении память освобождалась. Так что мазохизма я тогда так и не увидел :) С другой стороны, это был единственный в те времена случай, когда мне требовался демон на PHP.

...

Недавно возвращался к демону-обработчику задач на PHP, но теперь ломать голову со сборкой мусора не пришлось, на штатном сборщике за месяцы работы утечек не было.

Правда, сейчас я снова от такого демона отказался, вместо мониторинга очереди в MySQL или Redis оказалось эффективнее сидеть на inotify, а задачи кидать файлами :)

KRoN73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.