Тест стоимости вызовов в php7.3-fpm

Темы, не касающиеся фреймворка, но относящиеся к программированию в целом.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

samdark писал(а): 2020.10.23, 23:33
Сколько будет в Yii3 загружаться классов?
Проверьте сами. Так он быстрее Yii 2. По крайней мере пока.
Чуть позже, обязательно потестирую, спасибо. Как-то потерял новость что он уже выпущен.

P.S. Подправил и дополнил предыдущие сообщение, завершающее тестирование.

P.P.S. Ради справедливости поднял сайт на Laravel и протестил главную страницу, "как есть". Внес корректировки в последний пост "итогов".

Вот теперь тему можно считать "исчерпанной" полностью.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

Как-то потерял новость что он уже выпущен.
Он ещё не выпущен. Но работает.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Тю.. а где взять чтобы потестить то что "работает"? ;)

P.S.
Поднял свой учебник на хостинге nic.ru, не понял почему там apache2 как-то неверно отдает css - они принимаются браузером, но отвергаются по причине "mime type принят как text/html, вместо ожидаемого text/css" .. дома nginx всю статику отдает корректно. Ну да ладно, разберусь как время будет.
Итог: время отдачи странички = 0.35мсек. Кмк, вполне для полноценной странички сайта - учебника. :)
Смотреть можно тут (вырезано самоцензурой)

P2.S.
Посмотрел процесс раскрутки Laravel .. как ни странно, но он практически совпадает с этим подходом. Кажется знаю, откуда берется 250+ классов, но это не точно. Надо будет покопать тщательней оба фреймворка "изнутри". :)
Последний раз редактировалось Arhat109 2020.10.29, 11:18, всего редактировалось 1 раз.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Посмотрел index.php, дальше не стал. Это "шустрым" быть не может :)

Всё, закрыл для себя тему. Можно и совсем закрыть.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
chungachguk
Сообщения: 435
Зарегистрирован: 2012.07.17, 11:52

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение chungachguk »

Интересно, как там дестроер поживает...
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

Это "шустрым" быть не может :)
Тем не менее, по замерам Yii 3 отрабатывает быстрее Yii 2.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

За 1000 запросов в сек на современном железе перевалили? Ну .. тоесть в вашем Отладчике время отклика на запрос уже меньше миллисекунды для примера выше? (у меня на core2duo отклик Yii2 пишет миниум около 7мсек что привел выше)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

За 1000 запросов в сек на современном железе перевалили?
При тестировании что Yii 2 что Yii 3 давали до 260 rps. Железо скромное было на сервере. На более мощном не проверяли.

https://github.com/yiisoft/yii-demo/issues/124

Абсолютные цифры интересны не сильно. А вот цифры относительно Yii 2 показывают рост производительности на 17%.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

А какое там железо? Не заметил .. не по глазам, что ли. :)

Это не удивительно, т.к. у Вас "ООП ради красоты, а не пользы для". :(
Сколько делается геттеров, магии, даже там, где код в целом условно "полезен"? Каков средний размер функции, метода .. каково КПД интерпретатора в "итого"?

А ведь даже для пустого приветсвия грузится 90+ классов 1.5-4.5 мегабайта памяти .. ради чего? .. ради КРАСОТЫ, в ущерб функциональности. :(
.. ну и чтобы начинающий студент меньше имел шансов [s]выстрелить себе в ногу[/s] накосячить. За всё надо платить. Вы платите скоростью отдачи результата за низкий порог вхождения (студентов). Зато имеете аудиторию почитателей. :)
Ну а Заказчик платит за соответствующее железо, стоимость его обслуживания, разного рода системы дублирования, балансировки нагрузки .. оркестровку в целом. Сколько там сейчас грамотный devops на рынке труда? (2 недели назад мне предлагали 160 кажется).. ну и это .. "продвижение и рост ИТ в целом" .. больше хороших, многоядерных серверов, больше рабочих мест .. :)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение ElisDN »

Arhat109 писал(а): 2020.11.03, 19:41 За всё надо платить. Вы платите скоростью отдачи результата...
Arhat109 писал(а): 2020.10.01, 14:33 Дошло, почему не пользовался автотестированием стока лет и никак меня это не печалило.
Ну уж надёжнее и приятнее доплатить программисту и опсу за ООП с тестами и оркестрацией, чем за голый PHP без автотестов и автодеплоя.
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

А какое там железо?
Какое-то слабенькое. Это без разницы. Замерьте ответ Yii 2 на своём и прибавьте 17%. Получите примерные цифры Yii 3.
Сколько делается геттеров, магии, даже там, где код в целом условно "полезен"?
Меньше, чем в Yii 2.
Ну а Заказчик платит за соответствующее железо, стоимость его обслуживания, разного рода системы дублирования, балансировки нагрузки .. оркестровку в целом.
Железо, как правило, дешевле ошибок разработчика. Час одного девопса, как правило, дешевле, часа команды разработчиков. Это не значит что на производительность можно наплевать, но и не значит что нужно писать портянку в index.php.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Согласен, ибо, как обычно - истина посередине.

В начале топика, показал что и сколько стоит в PHP. И как ни крутись, а интерпретатор так и останется интерпретатором. И, чтобы искать эту "золотую середину", кмк, стоит помнить о "цене вопроса", в т.ч. и с этой стороны - условного КПД интерпретатора.

Вы же "полистали учебник", верно? :)
Давайте по пунктам (прошу прощения за много букв):
1. Настройка фреймворка на Приложение.
Нам надо "внедрить зависимости". В Kohana, этом USSR, и др. простых решениях, разрабу предлагается по сути один способ и "самый простой" - включить нужные файлики в нужном месте до запуска роутера (диспетчера и т.д.) т.е. самого фреймворка. Отголосок этого, есть и у Вас в Yii2, а именно тот самый web.php, что возвращает массив настроек.

Все "настройки", так или иначе - глобальны, ибо действуют "на всё". Но, в варианте ООП, Вы создаете класс конфигуратора (нафига?). Далее, глобал - не моден (и только!), а поскольку оно все равно надо пробрасывать везде - значит создаем "хранилище" в виде Yii->app, Vault и т.д. (нафига?), и наворачиваем целую оркестровку из нескольких сущностей.
Вы что-то получаете взамен? Очень сомнительно, но вот КПД снижается качественно.

Да, существуют разные способы конфигурирования, от возвращения массива PHP, до разного рода Yml, Json, Xml описаний. Стремление угодить всем приводит к росту классов, хелперов, интерфейсов .. ради попытки "расширить аудиторию и снизить порог входа" и только. А стремление впихнуть невпихуемое, приводит к динамике и автоподгрузкам требуемого конфигуратора и в конечном виде выливается в большой объемный bootstrap с поведениями, событиями и пр. "наворотами".
Оплата таже самая - качественное снижение КПД интерпретатора в целом и гигантский рост потребления как времени так и памяти, и в конечном счете те самые 250+ классов (Laravel) выросли отсюда, не смотря на неплохую идею изначально. 2.5 мегабайта на настройку - типовая плата, практически ВЕЗДЕ, при требуемом объеме в реале в .. 0.05Мб. :)

Этим ещё Zend страдал, что и побудило меня написать эту пародию на него на чистом PHP, где-то в 2013-м и теперь оформилось в USSR

2. Базовая задача - разобрать запрос на составные элементы, защитить Приложение от инжекций чего не положено, оставить только полезное и найти кому передать формирование ответа. В самых модных(а не полезных!!!) фреймворках, каждый чих выделен в свой класс request, route, etc. Стремление сделать "все по науке ООП" привело к появлению под ними разных интерфейсов, абстракций, моделей и т.д. Что вынуждает интерпретатор .. грузить всё от самого низа, до самого верха, ибо оно указано в используемых фичах в use...

Это ли хотел условный "разработчик Приложения"? Боюсь что совсем нет. Ему нужен простой и вменяемый набор данных из запроса, пробрасываемый в его MVC решение.

3. Сборка ответа. И так много, не буду расписывать. Надеюсь в целом понятно и так: всё ровно тоже самое. В реальности требуется собрать в кучку отдельные части ответа и выдать их в заданной последовательности или вывалить грамотно оформленную ошибку. Что имеем? А тоже самое - избыточную гору всего и вся, разобраться в приколах которой стоит больших затрат разработчику.

4. Доступ к БД. Подход Yii2, кмк в целом продвинутей чем "у других", но имеет свои недостатки, связанные .. а все с тем же желанием делать все "по теории ООП". Всё таже избыточность классов, трейтов, ООП решение к формированию запроса и отдельно работающий "построитель", понять работу которого .. а туда вообще мало кто ныряет! О как.

В тоже самое время, типичному сайто-писателю требуется совсем ничего: получить сущность, отдать клиенту и поправить согласно ответу. Или выдрать из БД требуемый массив записей, связать с ними нужный комплект зависимых сущностей и отдать это все, часто списком, или вовсе в табличном виде (галерея товаров к примеру). Но .. модель заточена на "объекты" и начинается .. циклический перебор ключей записей в поштучной фильтрации найденного. Редко? Да сплошь и рядом! Полистайте этот форум: 150 запросов к БД на страничку - НОРМА!
Да, тут Yii2 позволяет вести себя грамотно. Но .. какой ценой?

Аналогично .. получили кучу барахла с запросом. Это всё надо запихать в БД .. какой фреймворк предоставляет "множественную запись одним запросом"? А ведь Скуль только так и заточен ..

DRY, KISS, YAGNI, SOLID .. нарушено ВЕЗДЕ, ибо извращен сам смысл абревиатур. :(

Вам есть куда двигаться, и как улучшить проект. Надо просто тщательно присмотреться и выкинуть из него всё лишнее. :)

Кстати, показанная скорость и требуемый объем в USSR, это вместе со встроенным профилировщиком и сбором отладочной статистики, то самое что Вы просили "отключить" для проверок. :)
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

P.S. И таки, 17% улучшения - это ни о чем. Речь идет за десятки раз, как миниум вдвое должно работать шустрее, тогда можно смотреть. А так .. это как мертвому припарка.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение ElisDN »

Arhat109 писал(а): 2020.11.04, 10:37Но .. какой ценой?
Если бы автомобилисты следовали такой логике экономии, то все бы ездили на Матизах. Так как стоит четыре зарплаты, лёгкий как шкаф, потребляет бензина как мопед и можно парковать поперёк обочины. Вроде бы идеальный экономный автомобиль!

Но почему-то в реальности все катаются на автомобилях более дорогих и прожорливых вплоть до Гелендвагенов. Видимо помимо экономии им более важна мощность, надёжность, комфорт и безопасность.

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

А у Матиза и экономного кода, кстати, есть общая проблема. И тот и другой быстро гниют.
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Это "все аргументы" за навороты ради наворотов в ущерб полезной работе?

Не впечатлило. Как показал практика 39-летней разработки, простые решения как правило умирают вместе с железом, для которого были созданы. И не только мои.
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
samdark
Администратор
Сообщения: 9489
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение samdark »

Понятно, что вам импонируют минималистичные фреймворки. Если для ваших задач их достаточно - замечательно.
Кстати, показанная скорость и требуемый объем в USSR, это вместе со встроенным профилировщиком и сбором отладочной статистики, то самое что Вы просили "отключить" для проверок. :)
Дадите ссылку на USSR?

Также хотелось бы указать на некоторые фактически ошибки.
1. Настройка фреймворка на Приложение.
Нам надо "внедрить зависимости". В Kohana, этом USSR, и др. простых решениях, разрабу предлагается по сути один способ и "самый простой" - включить нужные файлики в нужном месте до запуска роутера (диспетчера и т.д.) т.е. самого фреймворка. Отголосок этого, есть и у Вас в Yii2, а именно тот самый web.php, что возвращает массив настроек.
Внедрить зависимости - это не то же, что загрузить классы. Это совсем из другой оперы. Тут, я понял, речь про загрузить классы. Операция это дешёвая, особенно учитывая включенный OpCache. web.php - это не про загрузку классов (этим занимается Composer и довольно эффективно). web.php - это как раз про контейнер и внедрение зависимостей. Да, можно, конечно, без контейнера всё инстанциировать и руками инжектить, но получается очень уж многословно.
Стремление сделать "все по науке ООП" привело к появлению под ними разных интерфейсов, абстракций, моделей и т.д. Что вынуждает интерпретатор .. грузить всё от самого низа, до самого верха, ибо оно указано в используемых фичах в use...
Во-первых, use не триггерит автозагрузку сам по себе. Чтобы она триггернулась, класс надо реально использовать. Если у вас, конечно, не тупой loader, который делает require сразу всего. Отсюда получаем что из всех классов, которые есть в фреймворке на типичный реквест в Yii грузится не так уж и много. В Laravel это проблема, да. На то он и один из самых медленных.

Во-вторых, OpCache снимает проблему "медленного" чтения кода из файлов.

В-третьих, у PHP данный момент самый быстрый интерпретатор из всех. Быстрее Python, Ruby... всего. Да, инстанциирование прям гигантского количества объектов или вызов гигантского количества функций будет виден, но тут скорее надо искать такие места с циклами и оптимизировать по месту, а не топить за отстутствие абстракций вообще.
Но .. модель заточена на "объекты" и начинается .. циклический перебор ключей записей в поштучной фильтрации найденного. Редко? Да сплошь и рядом! Полистайте этот форум: 150 запросов к БД на страничку - НОРМА!
Да, тут Yii2 позволяет вести себя грамотно. Но .. какой ценой?
Обычной нормальной ценой. Имя ей - осознанность. Если разработчик косячит на тему N + 1 или вытаскивает тучу данных, а потом перебирает их чтобы выкинуть лишнее - он сделает так что с query builder, что с SQL.
P.S. И таки, 17% улучшения - это ни о чем. Речь идет за десятки раз, как миниум вдвое должно работать шустрее, тогда можно смотреть. А так .. это как мертвому припарка.
Пока у нас не было цели оптимизировать Yii 3. То есть эти 17% получились, по факту, сами собой. После оптимизаций, скорее всего, будет лучше.

Ну а так, хотите больше - запускайте в долгоживущем окружении: https://github.com/yiisoft/docs/blob/ma ... drunner.md. Так полностью срезается время на работу самого фреймворка и есть возможность пошарить некотрые ресурсы. Так будет очень существенное ускорение в десятки раз.
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение ElisDN »

Arhat109 писал(а): 2020.11.04, 18:26 Как показал практика 39-летней разработки...
И сколько за это время у вас было проектов с ~1000 rps?
Arhat109
Сообщения: 61
Зарегистрирован: 2016.11.23, 09:06
Откуда: из СССР

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение Arhat109 »

Понятно, что вам импонируют минималистичные фреймворки. Если для ваших задач их достаточно - замечательно.
Не совсем так. Мне импонируют продуктивные решения. В Yii2 достаточно много интересных решений, чтобы просто от него отмахнуться. ;)
Дадите ссылку на USSR?
Позже, и "в личку", как допишу учебник (к сожалению, сейчас мало времени снова). В общем-то исключительно в целях этого обсуждения. Вопрос распространения не решал, учебник больше пишу для себя, т.к. к этой пародии на Зенд возвращаюсь с регулярностью раз в 1.5 года.. надоело вспоминать "что к чему" сам же ваял. :)
Тут, я понял, речь про загрузить классы. Операция это дешёвая, особенно учитывая включенный OpCache. web.php - это не про загрузку классов (этим занимается Composer и довольно эффективно). web.php - это как раз про контейнер и внедрение зависимостей. Да, можно, конечно, без контейнера всё инстанциировать и руками инжектить, но получается очень уж многословно.
нет. Тут как раз речь за инжекцию зависимостей, "полезных" объектов и сущностей .. ну и попутно классов их создающих, родительских .. вплоть до интерфейсов. web.php возвращал все же банальный массив, а не контейнер, уже нет? :) Контейнер - ещё один класс с целью прикрыть приватностью то что внутри и только. (нафига?) :)
Во-первых, use не триггерит автозагрузку сам по себе. Чтобы она триггернулась, класс надо реально использовать. Если у вас, конечно, не тупой loader, который делает require сразу всего. Отсюда получаем что из всех классов, которые есть в фреймворке на типичный реквест в Yii грузится не так уж и много. В Laravel это проблема, да. На то он и один из самых медленных.
Ну .. про неиспользованный класс в use речь не идет. речь про избыточное дробление на классы, сущности которых на самом деле почти всегда оказываются тесно связаны промеж себя. Что лучше: один класс на 1000 строк кода или 10 классов по 100 тех же самых строк?
Во-вторых, OpCache снимает проблему "медленного" чтения кода из файлов.
Частично, но весьма эффективно.
При редком использовании класса, его код может вымываться из кеша. Ну или это ТРЕБУЕТ повышенных расходов ОЗУ особенно в варианте 100500 мелких классов (и да здравствуют дорогие сервера!). впрочем, отмечал это как способ улучшения ситуации.
В-третьих, у PHP данный момент самый быстрый интерпретатор из всех. Быстрее Python, Ruby... всего. Да, инстанциирование прям гигантского количества объектов или вызов гигантского количества функций будет виден, но тут скорее надо искать такие места с циклами и оптимизировать по месту, а не топить за отстутствие абстракций вообще.
Ну .. мало ли быстрее чего он. Мы же не рассматриваем здесь вариант рисования веб-приложения на визуал-бейсике, или вообще на чем-то отдельном от PHP :)
Это просто "нам повезло", что команда разработчиков языка взялась его "приводить в порядок" .. а сделают оптимизации, а то ещё внезапно сваяют компилятор .. (только потеряется прелесть интерпретатора в части создания самомодифицирующихся программ, но, кмк, эти технологии уже утеряны безвозвратно) :)
Обычной нормальной ценой. Имя ей - осознанность. Если разработчик косячит на тему N + 1 или вытаскивает тучу данных, а потом перебирает их чтобы выкинуть лишнее - он сделает так что с query builder, что с SQL.
Я бы не был столь категоричен. Да, Yii2 предлагает интересный подход по вопросу эффективного сбора и вытаскивания зависимых сущностей из БД, сбором идентов и де факто можно (и обходился) всего парой запросов. Но .. это работает только на "первом уровне" зависимости. Глыбже, все становится грустней и таки приходится бегать циклами. :(
Вроде как в третьей версии от ActiveRecord отказались .. а как дела со множественной вставкой?
Пока у нас не было цели оптимизировать Yii 3. То есть эти 17% получились, по факту, сами собой. После оптимизаций, скорее всего, будет лучше.
Ну так вот за неё и ратую ..
Ну а так, хотите больше - запускайте в долгоживущем окружении: https://github.com/yiisoft/docs/blob/ma ... drunner.md. Так полностью срезается время на работу самого фреймворка и есть возможность пошарить некоторые ресурсы. Так будет очень существенное ускорение в десятки раз.
А вот это надо будет посмотреть, интересно. Возможно не видел, спасибо.

P.S. Сорри, ссыль обрезана, не попасть...
Все чаще Историки находят следы древней и очень высокоразвитой Цивилизации, со странными буквами .. СССР
Аватара пользователя
ElisDN
Сообщения: 5845
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Тест стоимости вызовов в php7.3-fpm

Сообщение ElisDN »

Arhat109 писал(а): 2020.11.04, 22:18 Что лучше: один класс на 1000 строк кода или 10 классов по 100 тех же самых строк.
С точки зрения скорости лучше один файл простыни на 1000 строк вообще без классов и процедур.

С точки зрения удобства разработки лучше 50 классов по 20 строк.
Ответить