company_banner

Исчерпывающие бенчмарки PHP 5.6, 7.0, 7.1, 7.2 и HHVM (2018)

https://kinsta.com/blog/php-7-hhvm-benchmarks/
  • Перевод


Каждый год мы стараемся тщательно измерять производительность разных версий PHP и HHVM на различных платформах. В этом году мы измерили четыре версии PHP и HHVM на 20 платформах/конфигурациях, включая WordPress, Drupal, Joomla!, Laravel, Symfony и многие другие. Также мы протестировали популярные решения для электронной коммерции вроде WooCommerce, Easy Digital Downloads, Magento and PrestaShop.


Мы всегда рекомендовали пользователям WordPress не пренебрегать преимуществами свежайших поддерживаемых версий PHP. Не только ради безопасности, но и ради повышения производительности. Причём речь идёт не только о WordPress, это по большей части справедливо для всех платформ. И сегодня мы продемонстрируем, как PHP 7.2 одерживает сокрушительную победу!


В этом году результаты бенчмарков очень сильно отличаются от прошлогодних, когда победителем стал HHVM. Нас впечатлило, что PHP 7.2 вырвался в лидеры по скорости работы. Нужно отметить, что применительно к WordPress HHVM больше не поддерживается и будет постепенно сходить со сцены. Мы больше не рекомендуем своим клиентам переходить на HHVM и отмечаем, что его поддержка другими платформами также снизилась.


Это хорошие новости для разработчиков и конечных пользователей, поскольку теперь можно сосредоточиться на PHP и создавать более быстрые сайты и веб-сервисы.


Мы протестировали 20+ платформ/конфигураций с пятью разными движками, и PHP 7.2 завоевал золотую медаль с результатом 14/20!


Бенчмарки PHP и HHVM (2018)


Для каждого теста мы брали последнюю версию каждой платформы и в течение минуты измеряли работу главной страницы с 15 одновременными пользователями. Тестовый стенд:


  • Машина: 8x Intel® Xeon® CPU, 2,20 ГГц (работала в Google Cloud Platform и исполнялась в изолированном контейнере)
  • ОС: Ubuntu 16.04.3 LTS
  • Стек Docker: Debian 8, Nginx 1.13.8, MariaDB 10.1.31
  • Движки PHP: 5.6, 7.0, 7.1, 7.2
  • HHVM: 3.24.2
  • OPCache: для WordPress, Joomla и Drupal мы использовали официальный образ Docker. Для остальных — тот же образ с включённым OPCache и рекомендованными настройками php.ini.

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

Тесты выполнял Торик Фирдаус (Thoriq Firdaus), один из разработчиков WordPress и инженер поддержки в Kinsta. Торик участвовал в создании WordPress Core и редактора локализации WordPress для Индонезии.


Что такое PHP?


PHP — это гипертекстовый препроцессор. Сегодня это один из самых популярных скриптовых языков в сети. Согласно W3Techs, PHP применяется на 83 % сайтов, использующих языки программирования на стороне сервера.


Что такое HHVM?


Из-за проблем с производительностью PHP команда Facebook разработала HipHop Virtual Machine (HHVM). Это система, использующая JIT-компиляцию (just-in-time) для преобразования PHP-кода в машинный код ради синергии PHP и железа, на котором этот код исполняется.


Протестированные платформы и конфигурации


Мы протестировали 20 платформ/конфигураций. В некоторых случаях из-за отсутствия поддержки конкретной версии PHP пришлось протестировать по несколько версий. Все измерения — количество запросов в секунду. Чем больше значения, тем лучше.



WordPress 4.9.4


Первой протестированной платформой стал, конечно же, наш любимый WordPress (возможно, мы немного предвзяты, поскольку ежедневно живём этой CMS). По сути, WordPress — ПО с открытым исходным кодом, которое можно использовать для создания прекрасных сайтов, блогов или приложений. Сегодня на WordPress приходится около 29 % всех сайтов в интернете, то есть более четверти.



Для измерения производительности WordPress мы использовали бесплатную тему Twenty Seventeen. Для заполнения взяли фальшивый контент из wptest.io и в течение минуты тестировали главную страницу, которую одновременно просматривают 15 пользователей.


  • Количество публикаций на странице: 10, сгенерированы wptest.io.
  • На боковой панели (Sidebar) есть только поиск.
  • Образ Docker взят из https://hub.docker.com/_/wordpress/



    WordPress benchmarks



Результаты бенчмарков


  • WordPress 4.9.4 PHP 5.6: 49,18 запроса в секунду
  • WordPress 4.9.4 PHP 7.0: 133,55 запроса в секунду
  • WordPress 4.9.4 PHP 7.1: 134,24 запроса в секунду
  • WordPress 4.9.4 PHP 7.2: 148,8 запроса в секунду
  • WordPress 4.9.4 HHVM: 144,76 запроса в секунду

Победил PHP 7.2, он оказался чуть быстрее HHVM. Это важная перемена по сравнению с бенчмарками 2016 года, когда однозначным победителем был HHVM. Кроме того, PHP для WordPress работает гораздо стабильнее. Мы сами сталкивались с многочисленными проблемами при эксплуатации HHVM. А если сравнить PHP 7.2 с PHP 5.6, то разница в производительности оказывается трёхкратной!


WordPress 4.9.4 + WooCommerce 3.3.1


WooCommerce — полностью кастомизируемая open-source платформа на основе WordPress. К тому же это одно из самых популярных решений для электронной коммерции, на нём работает свыше 42 % всех коммерческих сайтов.



Для этого теста мы взяли WordPress с установленным WooCommerce и бесплатной темой Storefront eCommerce.


  • Количество товаров: 8 (по два в ряд).
  • Страница магазина задана в качестве главной.
  • Образ Docker взят из https://hub.docker.com/_/wordpress/



    WordPress + WooCommerce



Результаты бенчмарков


  • WordPress 4.9.4 + WooCommerce 3.3.1 PHP 5.6: 34,47 запроса в секунду
  • WordPress 4.9.4 + WooCommerce 3.3.1 PHP 7.0: 84,89 запроса в секунду
  • WordPress 4.9.4 + WooCommerce 3.3.1 PHP 7.1: 86,04 запроса в секунду
  • WordPress 4.9.4 + WooCommerce 3.3.1 PHP 7.2: 92,6 запроса в секунду
  • WordPress 4.9.4 + WooCommerce 3.3.1 HHVM: 69,58 запроса в секунду

WooCommerce с трудом работал с HHVM, а PHP 7.2 победил PHP 7.1 с небольшим преимуществом.


WordPress 4.9.4 + Easy Digital Downloads 2.8.18


Easy Digital Downloads (EDD) создал Пипин Уильямсон (Pippin Williamson). Это бесплатный WordPress-плагин, помогающий авторам и разработчикам продавать цифровые продукты.



Посмотрев, как работает WooCommerce, мы протестировали WordPress с одним лишь установленным Easy Digital Downloads. Использовалась бесплатная тема EDD Starter Theme.


  • Количество товаров: 6 (товары по умолчанию из самого плагина).
  • Две картинки в списке продуктов отсутствуют.
  • Образ Docker взят из https://hub.docker.com/_/wordpress/



    WordPress + Easy Digital Downloads



Результаты бенчмарков


  • WordPress 4.9.4 + EDD 2.8.18 PHP 5.6: 76,71 запроса в секунду
  • WordPress 4.9.4 + EDD 2.8.18 PHP 7.0: 123,83 запроса в секунду
  • WordPress 4.9.4 + EDD 2.8.18 PHP 7.1: 124,82 запроса в секунду
  • WordPress 4.9.4 + EDD 2.8.18 PHP 7.2: 135,74 запроса в секунду
  • WordPress 4.9.4 + EDD 2.8.18 HHVM: 127,74 запроса в секунду

PHP 7.2 доминирует.


Drupal 8.4.4


Drupal — open-source CMS, заслужившая популярность благодаря модульной системе и сильному сообществу разработчиков. Она появилась в 2000-м и, согласно W3Techs, используется примерно на 2,2 % всех сайтов, занимая 4,4 % рынка CMS.



Мы использовали бесплатную тему Bartik 8.4.4. Отметим, что Drupal 8.4.x несовместима с PHP 7.2 (#2932574), поэтому движок мы не тестировали.




Drupal


Результаты бенчмарков


  • Drupal 8.4.4 PHP 5.6: 7,05 запроса в секунду
  • Drupal 8.4.4 PHP 7.0: 15,94 запроса в секунду
  • Drupal 8.4.4 PHP 7.1: 19,15 запроса в секунду
  • Drupal 8.4.4 PHP 7.2: не поддерживается
  • Drupal 8.4.4 HHVM: 19,57 запроса в секунду

Поскольку последняя версия Drupal не поддерживает PHP 7.2, победителем стал HHVM. Хотя если посмотреть на улучшения производительности в предыдущих версиях PHP, то можно смело предположить, что 7.2 работал бы ещё быстрее.


Joomla! 3.8.5


Joomla! — бесплатная CMS с открытым исходным кодом для публикации контента. Она впервые вышла в августе 2005-го. Joomla! построена на основе фреймворка для веб-приложений по схеме «модель-представление-контроллер» и, согласно W3Techs, используется на 3,1 % всех сайтов в интернете.



Для тестирования Joomla мы использовали бесплатный шаблон Beez3.


  • Количество публикаций: 4 (добавленные при установке образцы публикаций по умолчанию)
  • Панели по умолчанию не использованы.
  • Образ Docker взят из https://hub.docker.com/_/joomla/


Joomla!


Результаты бенчмарков


  • Joomla! 3.8.5 PHP 5.6: 26,42 запроса в секунду
  • Joomla! 3.8.5 PHP 7.0: 41,46 запроса в секунду
  • Joomla! 3.8.5 PHP 7.1: 41,17 запроса в секунду
  • Joomla! 3.8.5 PHP 7.2: 42,36 запроса в секунду
  • Joomla! 3.8.5 HHVM: 51,84 запроса в секунду

На примере Joomla мы видим стабильный рост производительности PHP от версии к версии. Но HHVM всё ещё лидирует.


Magento 2 (CE) 2.1.11 + 2.2.2


Magento — популярная open-source платформа, написанная на PHP. Она появилась в марте 2008-го. Согласно W3Techs, Magento работает на 1,2 % всех сайтов.



Для тестирования Magento 2 benchmark мы использовали бесплатную тему Luma. Поскольку PHP 5.6 поддерживался только версией 2.1.11, нам пришлось прогонять бенчмарки на двух версиях Magento. Мы установили её с образцами данных и темой, идущими в комплекте. Для дополнительного тестирования использовали версию 2.2.2. Magento 2 пока не поддерживает PHP 7.2 и последнюю версию HHVM.




Magento 2


Результаты бенчмарков


  • Magento 2 (CE) 2.1.11 PHP 5.6: 10,75 запроса в секунду
  • Magento 2 (CE) 2.1.11 PHP 7.0: 20,87 запроса в секунду
  • Magento 2 (CE) 2.1.11 PHP 7.1: 29,84 запроса в секунду
  • Magento 2 (CE) 2.1.11 PHP 7.2: не поддерживается
  • Magento 2 (CE) 2.1.11 HHVM: не поддерживается

Поскольку Magento 2 не поддерживает PHP 7.2 и последнюю версию HHVM, победителем стал PHP 7.1. Впечатляет рост производительности от версии к версии.


Grav CMS 1.3.10


Grav — простая, но мощная open-source CMS, которой не требуется база данных. Её ещё иногда называют «CMS на основе неструктурированных файлов (flat-file)».



Мы использовали бесплатный пакет Clean Blog. Обратите внимание, Grav CMS больше не совместима с компилятором HHVM, а из сборки Travis удалена среда HHVM.


  • Количество публикаций: 4 (предустановленные образцы в Clean Blog)
  • Выключено кеширование страниц и файлов https://learn.getgrav.org/advanced/performance-and-caching, кеширование Twig работает.



    Grav CMS



Результаты бенчмарков


  • Grav CMS 1.3.10 PHP 5.6: 34,83 запроса в секунду
  • Grav CMS 1.3.10 PHP 7.0: 53,37 запроса в секунду
  • Grav CMS 1.3.10 PHP 7.1: 53,37 запроса в секунду
  • Grav CMS 1.3.10 PHP 7.2: 55,12 запроса в секунду
  • Grav CMS 1.3.10 HHVM: не поддерживается

PHP 7.2 снова одержал убедительную победу.


October CMS 1.0.433


October CMS — бесплатная open-source модульная CMS-платформа с собственным сервером, построенная на базе PHP-фреймворка Laravel. Впервые она вышла в мае 2014-го.



Мы использовали бесплатную тему Clean Blog. October CMS больше не совместима с PHP 5.6 и HHVM. И хотя мы cмогли обмануть инсталлятор, убрав проверку PHP, мастер конфигурирования вылетел с ошибкой 500.


  • Количество публикаций: 5 с двумя панелями слева (Recent posts и Follow me)



    October CMS



Результаты бенчмарков


  • October CMS 1.0.433 PHP 5.6: не поддерживается
  • October CMS 1.0.433 PHP 7.0: 43,83 запроса в секунду
  • October CMS 1.0.433 PHP 7.1: 47,95 запроса в секунду
  • October CMS 1.0.433 PHP 7.2: 48,87 запроса в секунду
  • October CMS 1.0.433 HHVM: не поддерживается

Два движка не поддерживаются, однако PHP 7.2 снова победил.


Приятно, что все эти не столь крупные CMS отказываются от поддержки старых версий PHP. Это одно из преимуществ, свойственных не слишком большим продуктам. К сожалению, когда речь заходит о WordPress и прочих платформах с большими долями рынка, прогресс замедляется из-за соображений обратной совместимости.


Laravel 5.4.36 + 5.6


Laravel — очень популярный open-source PHP-фреймворк, использующийся для создания веб-приложений. Он был разработан Тейлором Отвеллом (Taylor Otwell) и выпущен в июне 2011-го.



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


  • Количество публикаций: 10, с циклом Blade
  • База данных содержит одну таблицу posts
  • Таблица содержит шесть колонок post_title, post_content, post_author, created_at и updated_at.
  • Сессии отключены.
  • Перед бенчмарками выполнены команды composer dump-autoload –classmap-authoritative, php artisan optimize –force, php artisan config:cache, php artisan route:cache.



    Laravel 5.4.36



Результаты бенчмарков


  • Laravel 5.4.36 PHP 5.6: 66,57 запроса в секунду
  • Laravel 5.4.36 PHP 7.0: 114,55 запроса в секунду
  • Laravel 5.4.36 PHP 7.1: 113,26 запроса в секунду
  • Laravel 5.4.36 PHP 7.2: 114,04 запроса в секунду
  • Laravel 5.4.36 HHVM: 394,31 запроса в секунду

HHVM — несомненный победитель.


Laravel 5.6 несовместим с HHVM и требует PHP 7.1 или выше.



Laravel 5.6


Результаты бенчмарков


  • Laravel 5.6 PHP 5.6: не поддерживается
  • Laravel 5.6 PHP 7.0: не поддерживается
  • Laravel 5.6 PHP 7.1: 411,39 запроса в секунду
  • Laravel 5.6 PHP 7.2: 442,17 запроса в секунду
  • Laravel 5.6 HHVM: не поддерживается

Поразительная разница между результатами Laravel 5.6 PHP 7.2 и Laravel 5.4.36! Последние версии PHP явно пошли на пользу Laravel.


Symfony 3.3.6 + 4.0.1


Symfony — это набор многократно используемых PHP-компонентов и PHP-фреймворк для создания веб-приложений, API, микросервисов и веб-сервисов. Он вышел в октябре 2005-го.



Здесь мы использовали Symfony Demo с MySQL (по умолчанию используется SQLite). Тесты проведены несколько раз, взято среднеарифметическое. HHVM выкидывал ошибку 500. Подробности можно почитать здесь.


  • Количество публикаций: 10
  • Тестовый URL: /en/blog/
  • composer dump-autoload -o, php bin/console doctrine:database:create, php bin/console doctrine:schema:create, php bin/console doctrine:fixtures:load, php bin/console cache:clear –no-warmup –env=prod
  • В основном файле (app.php) отключено кеширование (AppCache).



    Symfony 3.3.6



Результаты бенчмарков


  • Symfony 3.3.6 PHP 5.6: 81,78 запроса в секунду
  • Symfony 3.3.6 PHP 7.0: 184,15 запроса в секунду
  • Symfony 3.3.6 PHP 7.1: 187,6 запроса в секунду
  • Symfony 3.3.6 PHP 7.2: 196,94 запроса в секунду
  • Symfony 3.3.6 HHVM: не поддерживается

PHP 7.2 снова победил!


Symfony 4.0.1 требуется PHP 7.1 или выше. И снова HHVM выкидывал ошибку 500.


  • В версии 4.0.1 в основном файле (index.php) не реализован AppCache.



    Symfony 4.0.1



Результаты бенчмарков


  • Symfony 4.0.1 PHP 5.6: не поддерживается
  • Symfony 4.0.1 PHP 7.0: не поддерживается
  • Symfony 4.0.1 PHP 7.1: 188,12 запроса в секунду
  • Symfony 4.0.1 PHP 7.2: 197,17 запроса в секунду
  • Symfony 4.0.1 HHVM: не поддерживается

PHP 7.2 опять царь горы.


PyroCMS 3.4.14


PyroCMS — open-source расширение для Laravel, ускоряющее создание сайтов и приложений с помощью этого фреймворка.



Мы использовали бесплатную тему Accelerant Theme (идёт по умолчанию в PyroCMS). PyroCMS не работает в HHVM, вероятно, из-за Laravel.


  • Количество публикаций: 5
  • Включён режим отладки (APP_DEBUG=true)



    PyroCMS



Результаты бенчмарков


  • PyroCMS 3.4.14 PHP 5.6: не поддерживается
  • PyroCMS 3.4.14 PHP 7.0: 27,33 запроса в секунду
  • PyroCMS 3.4.14 PHP 7.1: 27,81 запроса в секунду
  • PyroCMS 3.4.14 PHP 7.2: 29,28 запроса в секунду
  • PyroCMS 3.4.14 HHVM: не поддерживается

Результаты близки к PyroCMS, но PHP 7.2 опять был лучшим.


Pagekit 1.0.13


Pagekit — лёгкая модульная open-source CMS, позволяющая создавать прекрасные сайты. Она вышла весной 2016-го.



Мы использовали бесплатную тему One (идёт в Pagekit по умолчанию).


  • Количество публикаций: 5
  • Кеш отключён
  • Тестовый URL: /blog



    Pagekit



Результаты бенчмарков


  • Pagekit 1.0.13 PHP 5.6: 51,7 запроса в секунду
  • Pagekit 1.0.13 PHP 7.0: 108,61 запроса в секунду
  • Pagekit 1.0.13 PHP 7.1: 112,3 запроса в секунду
  • Pagekit 1.0.13 PHP 7.2: 116,18 запроса в секунду
  • Pagekit 1.0.13 HHVM: 61,16 запроса в секунду

Pagekit с трудом работал с HHVM. PHP 7.2 — безусловный победитель.


Bolt CMS 3.4.8


Bolt — это open-source инструмент управления контентом, который авторы стараются сделать как можно проще. Он построен на основе компонентов Silex и Symfony, использует Twig, а также SQLite, MySQL или PostgreSQL.



Мы использовали бесплатную тему Bolt Base 2016. HHVM не поддерживается (#6921).


  • Количество публикаций: 5
  • Тестовый URL: /entries
  • Сессии включены



    Bolt CMS



Результаты бенчмарков


  • Bolt CMS 3.4.8 PHP 5.6: 33,45 запроса в секунду
  • Bolt CMS 3.4.8 PHP 7.0: 60,21 запроса в секунду
  • Bolt CMS 3.4.8 PHP 7.1: 67,96 запроса в секунду
  • Bolt CMS 3.4.8 PHP 7.2: 72,05 запроса в секунду
  • Bolt CMS 3.4.8 HHVM: не поддерживается

Хорошо видно, что с каждой новой версией PHP производительность Bolt CMS растёт.


Anchor CMS 0.12.6 (pre-release)


Anchor — очень простая и компактная open-source система для ведения блогов.



Мы использовали бесплатную тему Default Theme.


  • Количество публикаций: 5



    Anchor CMS



Результаты бенчмарков


  • Anchor CMS 0.12.6 PHP 5.6: 495,33 запроса в секунду
  • Anchor CMS 0.12.6 PHP 7.0: 546,02 запроса в секунду
  • Anchor CMS 0.12.6 PHP 7.1: 565 запросов в секунду
  • Anchor CMS 0.12.6 PHP 7.2: 561,73 запроса в секунду
  • Anchor CMS 0.12.6 HHVM: 487,71 запроса в секунду

Результаты PHP 7.1 и PHP 7.2 очень близки, но PHP 7.1 оказался чуть быстрее.


PrestaShop 1.7.2.4


PrestaShop — популярное и очень быстро развивающееся open-source решение для интернет-магазинов. Первая версия вышла в 2008-м, и, согласно W3Techs, PrestaShop используется на 0,6 % всех сайтов.



Мы взяли бесплатную тему Classic Theme. PrestaShop не поддерживает HHVM.


  • Количество товаров: 7 (примеры по умолчанию)
  • Тестовый URL: /index.php
  • Кеширование страниц отключено, умное кеширование включено



    PrestaShop



Результаты бенчмарков


  • Prestashop 1.7.2.4 PHP 5.6: 61,96 запроса в секунду
  • Prestashop 1.7.2.4 PHP 7.0: 108,34 запроса в секунду
  • Prestashop 1.7.2.4 PHP 7.1: 111,38 запроса в секунду
  • Prestashop 1.7.2.4 PHP 7.2: 111,48 запроса в секунду
  • Prestashop 1.7.2.4 HHVM: не поддерживается

Результаты почти одинаковые, но PHP 7.2 на полноздри вырвался вперёд.


Craft CMS 2.6.3011


Craft CMS — продукт для разработчиков, дизайнеров и веб-специалистов, отличающийся гибкостью применения, широкими возможностями и простой использования.



Мы взяли бесплатную тему по умолчанию.


  • Количество публикаций: 5
  • Тестовый URL: /index.php?p=news
  • CraftCMS поставляется с собственным файлом Docker. Мы немножко настроили его ради совместимости с Nginx.



    Craft CMS



Результаты бенчмарков


  • Craft CMS 2.6.3011 PHP 5.6: 131,04 запроса в секунду
  • Craft CMS 2.6.3011 PHP 7.0: 266,54 запроса в секунду
  • Craft CMS 2.6.3011 PHP 7.1: 272,14 запроса в секунду
  • Craft CMS 2.6.3011 PHP 7.2: 280,02 запроса в секунду
  • Craft CMS 2.6.3011 HHVM: 26,28 запроса в секунду

Craft CMS плохо работает с HHVM. Но зато PHP 7.2 опять на коне!


Fork CMS 5.2.2


Fork — простая open-source CMS, в которой применяются компоненты Symfony. Здесь мы использовали бесплатную тему, идущую по умолчанию, Fork Theme. Fork CMS требуется PHP 7.1 или выше, она не поддерживает HHVM.


  • Количество публикаций: 2 (идущие по умолчанию данные из ForkCMS)
  • Тестовый URL: /modules/blog



    Fork CMS



Результаты бенчмарков


  • Fork CMS 5.2.2 PHP 5.6: не поддерживается
  • Fork CMS 5.2.2 PHP 7.0: не поддерживается
  • Fork CMS 5.2.2 PHP 7.1: 10,68 запроса в секунду
  • Fork CMS 5.2.2 PHP 7.2: 12,83 запроса в секунду
  • Fork CMS 5.2.2 HHVM: не поддерживается

PHP 7.2 превзошёл по производительности PHP 7.1.


Мы в Kinsta перешли на PHP 7.2


Если эти результаты вас не убедили, то мы уж и не знаем, что вас вообще убедит. Просто дружеское напоминание, если вы клиент Kinsta: мы выпустили PHP 7.2 в декабре 2017-го. Если вам нужно увеличить производительность, можете легко перейти на PHP 7.2 одним кликом в панели MyKinsta.



Если вас беспокоит несовместимость со сторонними плагинами (это возможно), то именно для этого нужны площадки для стейджинга. Можете потестировать без риска для вашего production-сайта.


Впечатления от результатов бенчмарков


Как видите, PHP 7.2 по производительности лидирует на всех платформах.


  • PHP 7.2 оказался самым быстрым движком в 14 из 20 конфигураций. Ещё две конфигурации (Drupal и Magento) пока не поддерживают PHP 7.2, так что результат вполне мог быть 16/20.
  • Применительно к WordPress PHP 7.2 был самым быстрым во всех тестах (стоковый сайт WordPress, WooCommerce и Easy Digital Downloads).
  • На примере многих результатов можно отметить рост производительности PHP от версии к версии. Поэтому так важно тестировать свой сайт, плагины и прочее и регулярно обновлять движок. Это пойдёт на пользу вашим посетителям и клиентам!
  • Если ваш хостинг-провайдер не предлагает новые версии PHP, возможно, пора переезжать.

Mail.Ru Group

966,00

Строим Интернет

Поделиться публикацией

Похожие публикации

Комментарии 116
    +1
    Странно, что не приведены настройки HHVM. Они тоже сильно влияют. Например, если собрать .hhbc файл, то ускорение составляет до 30% (этот режим является основным для фейсбука).
      0
      Я думаю показательным тут является то что мордокнига делает HHVM под (а лучше сказать в основном для) себя, а пыха делается для всех. результат в графиках. Для некоторых задач лучше HHVM а ежели хочется стабильности + скорость то 7,2
      0
      Было бы здорово посмотреть на результаты Magento CE 1.9.3.8 и сравнить их с Magento 2.
        0
        Это две абсолютно разные платформы. Там общего только то, что они обе — ecommerce. С тем же успехом можно престашоп стравливать.

        Вообще смущает 30 запросов в секунду на M2. Если это с включенным FPC то по сути автор тестировал memcached/redis/filesystem. Или FPC был выключен?
          0

          Не менее важно чтобы там был продакшн-режим и разогретый кэш.

            0
            вся проблема в том, что если тестировать домашнюю страницу m2 и тестировать корзину — на luma производительность будет абсолютно разной. Потому что первая — закеширована в хлам, а во второй закеширован только хидер и футер.
            В интернет-магазинах показатель для бенчмарка — количество заказов в минуту: это самая важная и тормознутая часть, обычно, а не RPS.
              0

              В мадженте даже purchase order занимает до 3 секунд на хорошей машине, что уже говорить про всякие credit card. Правда, там сильное влияние 3-party сервисов.

                0
                Кокразтыке, всякие creditcard ненамного дольше выполняются, чем purchase order. Основной тормоз это sales/order. Тот же hosted payment это и есть purchase order просто с дополнительным редиректом на HPP и обратно.
        –3
        интересно еще что быстрее апачи молудуль, апачи фастцги или нгникс фастцги.
          0
          Я может не совсем в теме. Но разве для HHVM не надо указать какой PHP она исполняет? У нее свой собственный PHP? не 5.6 и не 7.0 и не 7.2?
            0
            Собственный. Более того — это немного другой язык.
            0
            А почему в ларавеле всё накешировали, а в симфони отключили appCache?

            На сайте симфони опубликовали ссылку где в тестировании в 2 раза получилась разница в производительности www.phpbenchmarks.com/en

            Как думаете почему у вас другие результаты?
              0
              Думаю, задачей было не сравнение фреймворков, а сравнение именно версий PHP.
              Поэтому можно было включить какую-то опцию или отключить — важнее было узнать, как скрипт работает на конкретном PHP.
                +2
                Ну раз бенчмарки фреймворков неправильные, значит и вклад интерпретаторов неправильно отображается (на том сайте разница процентов в 15% между 7.1 и 7.2 только на симфони, а в посте её не видно)
                  0
                  Symfony 4.0 почти в 2 раза бестрее чкм 3.3. У вас одинаковые.результаты.

                  Кроме того, Symfony 4.0 is almost three times as fast as Laravel 5.5.
                  twitter.com/dunglas/status/940512934714904577
                    +1

                    do not trust benchmarks you didn't fake yourself.

                0
                А можно увидеть загрузку CPU по процессам во время проведения тестов?
                  0
                  А кто-нибудь знает use case когда 7-я версия вдруг проигрывает 5-й? Не может же это выглядеть как серебрянная пуля. Или это тот самый случай, когда «серебряная пуля бывает»?
                    +2
                    Скорее это тот случай, когда прежнее решение было настолько кривым, что новое делает его по всем параметрам.
                      0
                      Согласен. Вообще, мне кажется, это нормально когда следующая версия лучше предыдущей. Мне кажется это нормальное ожидаемое поведение. :-) Ненормально обратное поведение, когда следующая версия значительно хуже предыдущей.
                      0
                      PHP 7 это и есть серебрянная пуля (особенно в режиме PHP-FPM — прозрачная и понятная система, в которой понятно, на что идет память и мощь в отличии от менее очевидного режима работы как модуля). Иногда торчать на 5.6 приходится только ради библиотеки mysql_, когда проект переписывать не рентабельно и он работает в режиме совместимости.
                        0
                        А то, что было в версиях 5.2 — 5.4, на ваш взгляд, вообще трэш и угар? Интересно просто мнение профи, подскажите.
                          +2
                          Да я еще помню PHP 4.4.9, в которой ООП было больше на словах как немного усложненные массивы без областей видимости.
                          Я не такой уж и профи, чтобы свободно об этом говорить, но революционным показался именно 5.3, когда появились неймспейсы (хотя я тогда мало работал с большими скриптами и не до конца мог понять преимущества), а также анонимные функции, а в PHP 5.4 хорошо запомнился синтаксический сахар объявления массивов с помощью [].
                          Ну по сути 5.3 стал промышленным стандартом, до сих пор, наверное, можно было бы найти несколько хостингов с этой патченой версией.
                          Каждая версия добавляла немного в производительности, но только в 7.0 случился столь сильный рывок из-за плотного переписывания внутренностей.
                          Ну а второе важное явление в языке — это развитие экосистемы, которая помогала избегать велосипедостроения. Composer ну очень сильно упростил жизнь в поддержке модулей и фреймворков в более-менее актуальном состоянии.
                          Отделить собственно мое развитие от параллельного развития языка довольно сложно, но, думаю, если что — меня дополнят.
                            0
                            Спасибо! Про синтаксис объявления массивов — читал, и правда удобно. ПРо неймспейсы знал, но не пользовался)

                            А если код совсем ООП не использует (и неймспейсы тоже), то есть сплошная лапша — будет ли выгода от переезда на семёрку, или ничего не изменится?

                            Просто вспоминается история из реальной практики, когда некий несложный код работал на 5.2, внезапно, чуть быстрее чем на 5.4, хотя, казалось бы…
                              0
                              В семёрке здорово ускорили работу с массивами, и я плохо представляю себе сложный код, пусть даже в лапшестиле, без массивов.
                                0

                                переработали в целом то как происходит работа с памятью (влияние на кэш процессора, размеры структур, оптимизация массивов и объектов (а от объектов совсем вы не уйдете)). Не забывайте — wordpress не особо "ооп" использует, по большому счету это та самая лапша.

                                  0
                                  От объектов «совсем» можно, очевидно, уйти, если не юзать ООП (и имхо не обязательно код, состоящий из аккуратных функций — обязательно лапша)… С массивами — понял, спасибо
                                    0
                                    состоящий из аккуратных функций — обязательно лапша

                                    все соль в управлении стэйтом и зависимостями.


                                    если не юзать ООП

                                    шутки ради — когда люди юзают классы — это еще не ООП)

                                      0
                                      Мы сейчас про поддержку или про производительность?) Что нормально поддерживать стейт при таком подходе трудно — согласен. А вот как по скорости будет? Так же, хуже, лучше?
                                        0
                                        А вот как по скорости будет? Так же, хуже, лучше?

                                        вам универсальный ответ?


                                        В целом, инстанцирование объекта весьма дешевая операция, и ситуации когда в рамках стандартного проекта на PHP вам надо инстанцировать внушительный граф объектов все же является крайне редкой.


                                        То что в условиях простой виртуальной машины как в PHP динамическая диспетчеризация накладывает определенные накладные ресурсы — это тоже факт, то эту проблему может решить JIT.


                                        Ну и опять же, в случае PHP с объектами и нормальной декомпозицией может возникнуть проблема с тем что какой-то граф объектов придется инстанцировать на каждый запрос. Ровно такая же проблема и, например, с коннекшенами к базе — на каждый http запрос вам надо переподключаться (а эта операция тоже дается вам не бесплатно). pconnect и т.д. позволяют решить эту проблему, но у вас может быть не только sql и там всеравно надо будет делать реконнекты.


                                        Это я подвожу к мысли что в целом распространенная (но уже не единственная) для PHP модель выполнения приложения уже не эффективна. А пытаться "уменьшить последствия" за счет сознательного увеличения связанности кода — не думаю что в эту сторону имеет смысл инвестировать.

                                          0
                                          А какими вы видите альтернативы для этой модели?

                                          Насчёт коннекшенов к БД — в Java EE вроде с этим лучше, там пулы соединений. Но я бы не сказал, что среднее приложение на Java EE работает быстрее, скорее даже наоборот.
                                            0
                                            Как вы думаете, почему медленнее?
                                              0
                                              Я не думаю, опыт показывает. Имел счастье (или несчастье) пользоваться сайтами, написанными на Java. Включая и сайт Сбербанка 3-5 летней давности. И старый сайт моего интернет-провайдера.

                                              А если Вы о причинах… Ну наверное потому, что Java EE требует много памяти, поскольку там куча объектов инстанцированы и никуда не исчезают, ожидая новых запросов. И фреймворки довольно тяжёлые, много проверок, большой упор на безопасность. Несколько слоёв абстракции, несколько фреймворков взаимодействуют друг с другом. Железо же обычное, или даже хуже обычного, потому что на хорошее денег не хватает, все уходят на зарплаты программистам :D

                                              Но это мои догадки.
                                                0
                                                поскольку там куча объектов инстанцированы и никуда не исчезают

                                                Это не особо влияет на производительность.


                                                Несколько слоёв абстракции

                                                а вы думаете в современных php фреймворках по другому?


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

                                                  0
                                                  Скорее всего, так и есть) Но просто по факту выходит вот так. Кстати, портал Билайна всегда был на Java. И опять же, вспоминая версию их сайта от 2012-2013 года… Это короче полная жесть. По 3-4 секунды на каждый переход по ссылке. Да и после редизайна в конце 2014-ого стало не сильно лучше. Только вот сейчас наконец последние пару лет оно нормально стало работать. И то, когда надо получить что-то редко запрашиваемое, типа страницы архивных тарифов — начинается та же история и даже хуже.
                                            0
                                            Про связность — сложный вопрос. Если проект небольшой, и разработчиков 1 или 2 человека — какая вообще разница. Если проект большой и команда тоже — там иначе и не выйдет, всё равно невозможно будет без ООП обходится, иначе все в «лапше» просто утонут.
                                              0
                                              Если проект небольшой, и разработчиков 1 или 2 человека — какая вообще разница.

                                              разница в том, что если не держать связанность в узде, то рано или поздно мы придем к ситуации когда вносить изменения в код становится сложно. Вы же видели код который "проще переписать с нуля чем впилить фичу"? И мы не будем сейчас поднимать вопрос что это никогда не проще, просто вспомните то ощущение беспомощности и отвращения.


                                              всё равно невозможно будет без ООП обходится

                                              подавляющему большинству наличие классов в их коде не мешает обходиться без ООП (тут больше вопрос в четком определении что это такое). Вы же видели как люди active record тот же юзают. А любовь к слоям?


                                              иначе все в «лапше» просто утонут.

                                              А теперь представьте себе лазанью. Где люди настолько упоролись в архитектуру (без осознания что те или иные решения дают, просто прочитали пару книжек и впихнули все практики которые нашли в одно решение). Когда для добавления нового поля на UI вам надо "прорезать" все слои. При том что связанность там будет на том же уровне что и в лапшекоде на уровне wordpress. Но при этом рефакторить такой код в разы сложнее (больше зависимостей).


                                              Люди почему-то смещают фокус с идеи (зависимости сами по себе плохо и надо уменьшать/прятать их количество всеми силами) на конкретику, которая проще в восприятии. Например луковая архитектура. Можно посмотреть, легко разобраться, не особо надо думать. А осознания плюсов и минусов, зачем… и тааак сойдет. Зато ООП.


                                              Есть же еще, скажем, ФП, которое намного более интересно в этом плане. Там и определения четкие, и критерии изоляции функции более простые. Но на PHP с ФП сложно, язык не приспособлен для такого. А идея что хороший разработчик должен знать как минимум 3 языка (не обязательно все три на хорошем уровне, просто для расширения кругозора), почему-то считается дикой. И все сводится к обсиранию того или иного языка.

                                                0
                                                >Вы же видели код который «проще переписать с нуля чем впилить фичу»?

                                                К счастью, миновало. Мой код до такой степени безобразия не доходил…

                                                >Есть же еще, скажем, ФП, которое намного более интересно в этом плане. Там и определения четкие, и критерии изоляции функции более простые.

                                                С большим уважением отношусь к ФП. Но во-первых, чтобы понять их в полной мере, нужна серьёзная мат. подготовка (наш препод по практике в конце второго курса, будучи уже аспирантом, нам признался, что курил вывод какой-то теоремы 2-3 ночи и еле вкурил, чтобы разобраться с монадами). А во-вторых, для практических задач… Ну вот смотрите, простой текстовый редактор. Или даже не очень простой. Его будет проще сделать на Java/C++, или на Haskell? Я ставлю на первый вариант :) Хотя на Haskell пытались. И даже делали :)

                                                >Люди почему-то смещают фокус с идеи (зависимости сами по себе плохо и надо уменьшать/прятать их количество всеми силами) на конкретику, которая проще в восприятии.

                                                Это да, совершенно согласен.
                                                  0
                                                  Мой код до такой степени безобразия не доходил…

                                                  То есть вам никогда не приходилось работать в команде над уже существующим проектом?)


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

                                                  на самом деле для базовых вещей — не особо. Вам не надо наизусть знать тезисы Алонзо-Черча что бы писать на F# к примеру или Scala.


                                                  Или даже не очень простой. Его будет проще сделать на Java/C++, или на Haskell?

                                                  Представим себе редактор вида google docs с возможностью колаборативного редактирования. Где несколько человек могут одновременно менять содержимое документа.


                                                  То есть по сути нам будет проще, если все изменения документа будут представлены append-only структурой данных, из маленьких имутабельных дифов, проигрывая который можно восстановить стэйт документа и предотвратить коллизии.


                                                  И знаете, Haskell тут будет эффективнее. При условии что вы знаете haskell на том же уровне что и человек который "проще бы запилил на java".


                                                  Вы же должны понимать что проблема не с тем что Haskell сложна, а со стериотипами что это сложнее чем java. Это больше проблема образования/узкого кругозора разработчиков нежели идеи/языка.


                                                  чтобы разобраться с монадами)

                                                  А вы уверены что с объектами разобрались? Там же еще сложнее — нет никаких формальных определений или принципов. Есть очень субъективные штуки и все. И проблема с ООП как раз таки в том, что в силу очень слабой формализации люди трактуют так как им привычно. При том что даже если бы большинство, которое считает что ООП это про классы, потрудились бы изучить хотя бы основы структурного проектирования — было бы проще.


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

                                                    0
                                                    >А вы уверены что с объектами разобрались? Там же еще сложнее — нет никаких формальных определений или принципов. Есть очень субъективные штуки и все.

                                                    Но эти субъективные штуки кажутся интуитивно проще, что поделать :)

                                                    >То есть по сути нам будет проще, если все изменения документа будут представлены append-only структурой данных, из маленьких имутабельных дифов, проигрывая который можно восстановить стэйт документа и предотвратить коллизии.

                                                    Это хорошая идея, но я не думаю, что реализовать это на традиционном ЯП через императивный подход будет сильно сложнее. Хранить список операций и проигрывать его — для решения этой задачи непременно нужно писать на функциональном языке, серьёзно?)

                                                    >Тот факт что надо потратить 2-3 ночи на изучения такой концепции как монады

                                                    Проблема не в том, что три ночи. А в том что даже для некоторых аспирантов на матмехе спбгу это трудно. А значит, идеи там правда непростые. Нам даже не стали пытаться объяснять, как это всё работает под капотом.

                                                    А вот C++ на начальном уровне сейчас уже многие школьники знают. И даже что-то пишут
                                                      0
                                                      кажутся интуитивно проще

                                                      ключевое слово — кажется. По факту большинство не понимает ключевых концептов для объектов (изоляция, сокрытие информации, снижение связанности).


                                                      если бы это было "интуитивно" — то небыло бы написано столько говна.


                                                      что реализовать это на традиционном ЯП через императивный подход будет сильно сложнее.

                                                      не сложнее, менее удобно, больше кода.


                                                      Если вам интересно — посмотрите вот эту лекцию: Functional architecture — The pits of success — Mark Seemann


                                                      А в том что даже для некоторых аспирантов на матмехе спбгу это трудно.

                                                      естественно что "не разбираться с вопросом" и полагать что все и так интуитивно понятно намного проще) Но это не так.


                                                      А значит, идеи там правда непростые.

                                                      Вы не поверите, но даже "класс" штука непростая. Если интересно — почитайте публикации Хоара (там где он впервые заговорил о том что сегодня называется "класс"), или Барбары Лисков.


                                                      И даже что-то пишут

                                                      и это пугает.

                                                        0
                                                        Про принцип Лисков я читал. Я бы не сказал, что там нечто недоступное для осознания)

                                                        >и это пугает.

                                                        Вы думаете, лучше бы и не писали? Все должны с чего-то начинать)
                                                          0
                                                          что там нечто недоступное для осознания)

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

                                                          0
                                                          >Если вам интересно — посмотрите вот эту лекцию

                                                          Спасибо, обязательно :)
                                                    0
                                                    Также хочу ещё добавить, что помимо реально хороших программистов есть начинающие кхм… кодеры, к которым, думается, всё ещё отношусь и я. Так вот эти люди часто понимают (иногда в полной мере), чем плох их стиль программирования, и как потом «весело» будет поддерживать их код другим. Но ничего с собой поделать не могут. Потому что применение сложных паттернов, введение новых уровней абстракции — оно, конечно, облегчает потом введение каких-то вещей, или модификацию существующих (если проект до этого доживёт). Но это сразу понижает наглядность кода, делает его более абстрактным, «сферическим» (взять простой пример: абстрактный источник данных с возможностью сделать этим источником что угодно vs. конкретный файл с конкретным именем, которое визуально врезается в память, и которое в коде сразу видно, потому что оно выделяется на фоне окружающего кода). Это для многих тяжело. Надо ведь мозг включать, уже не получится делать по привычке, автоматически. Лень побеждает, и получается очередная лапша :)
                                                      0
                                                      которое визуально врезается в память

                                                      а зачем?


                                                      Ну то есть вот серьезно, что это вам дает? Мне это говорит только о том, что такое понятие как "абстракция" в целом не понятно новичку. И как следствие через N лет мы видим очередного программиста который лепит AbstractFactoryFactory и считает что он умеет в абстракцию (потому что абстрактный класс замутил).


                                                      Мне кажется что неумение декомпозировать задачи свидетельствует о огромном фэйле системы образования.


                                                      Это для многих тяжело. Надо ведь мозг включать

                                                      а теперь представьте что у вас нет ни кассов, ни интерфейсов, ни сервисов, фабрик и всяких там "слоев" а есть просто функции и структуры данных. И в идеале все функции чистые (то есть зависят только от своих аргументов). И функции можно передавать как аргументы другим функциями (по сути late binding). И вы можете любую "грязную функцию" подменить на чистый аналог (для тестирования). И все можно протестировать. И все намного проще, нет кучи лишних терминов (функторы, фри монады и прочие теории категорий можно изучить в факультативном режиме, это не требуется для начала).

                                                        0
                                                        >Ну то есть вот серьезно, что это вам дает? Мне это говорит только о том, что такое понятие как «абстракция» в целом не понятно новичку.

                                                        Я и не говорю, что такое — хорошо и правильно. Но что это даёт — могу сказать. Лёгкое узнавание. Понижается скорость чтения собственного кода, быстрее понимаешь, какая строчка что делает (и какой блок что делает). И чем больше в коде абстракций, фабрик и сервисов, тем ниже (для меня и для многих новичков) его читаемость.

                                                        >Мне кажется что неумение декомпозировать задачи

                                                        А если человек, предположим, умеет их декомпозировать. Что это изменит? Проблему, описанную выше, это не решит. Это уже проблема особенностей мышления конкретного человека. Тут или себя переделывать, или даже не знаю, менять профессию :)

                                                        >а теперь представьте что у вас нет ни кассов, ни интерфейсов, ни сервисов, фабрик и всяких там «слоев» а есть просто функции и структуры данных. И в идеале все функции чистые (то есть зависят только от своих аргументов). И функции можно передавать как аргументы другим функциями (по сути late binding).

                                                        Очень похоже на мой код для сайтов на JavaScript, кроме шуток. Но JS — не функциональный ЯП (хотя и имеет некоторые черты, но я лучше об этом не буду, чтобы не наговорить глупостей).

                                                        >И все можно протестировать. И все намного проще, нет кучи лишних терминов

                                                        Да, и правда намного проще. Только в чём разница вот такого кода на чистых функциях (не важно, на Haskell, Scala, Erlang или на чём), и обычного кода, который пренебрежительно называют «лапшой»? Ведь и там, и тут — куча мелких функций с низкой связностью, которые по отдельности легко тестить, но в которых можно утонуть, когда их становится много, и которые все одноуровневые (нет иерархии). Или последнее я зря сюда добавил, иерархия допустима?
                                  +1
                                  Целая горсть таких. К счастью, composer require dshafik/php7-mysql-shim «works like a charm». Больше проблем доставили другие несовместимости между 5 и 7. Но, в целом, даже дремучее legacy за один рабочий день вполне себе втаскивается на 7.2.
                                    0
                                    Знаю, но не в тех случаях, когда включая показ Notice, сталкиваешься с тысячами, тысячами подобных ошибок и не знаешь, что привнесено из-за изменения версии, а что из-за раздолбайства программистов.
                                    Поэтому иногда подобные проекты доживают последние дни на комфортном 5.6
                                    0
                                    К слову. библиотека mysql_ никуда не делась, ее просто выкинули из поставки по умолчанию и перенесли в pecl. Ее уже не развивают, но поддерживают для работы в php 7 и выше. Как временное решение пойдет.

                                      0
                                      Опять же, давно интересовало — в чём причина отказа от этой библиотеки? Писали, что она морально устарела — так что мешало переписать её саму изнутри, сохранив полностью API? Это не потребовало бы менять клиентский код, писавшийся под неё, во многих проектах. Чем API mysqli лучше (про PDO не будем, там в принципе иной подход)?
                                        0
                                        так что мешало переписать её саму изнутри, сохранив полностью API?

                                        Получится mysqli. АПИ там не сильно отличается, в функциональном плане.
                                        Чем API mysqli лучше

                                        Там есть объектный подход, что позволяет не писать свою обёртку, так же там есть поддержка подготовленных запросов, что позволяет забыть о SQL инъекциях.
                                          0
                                          АПИ там не сильно отличается, в функциональном плане.

                                          Но отличается! Хотя бы тем, что «i» в имена функций добавили (и не только этим). Переучиваться всегда неудобно

                                          что позволяет не писать свою обёртку

                                          Вы про конструктор запросов?

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

                                          Вот это упустил. Пожалуй, и правда стоит её изучить получше)

                                          Кстати, мне кажется, или кастомный код всё-таки надёжнее, чем использование подготовленных запросов? Не помню, как дела с типами параметров в этих запросах обстоят, но как минимум даже если они поддерживаются, мы можем ещё больше ограничить допустимое множество значений в кастомном коде. А там, где оно ограничено — инъекции и так практически исключены. Где требуется свободный ввод пользователем произвольного текста — ну так функции фильтрации ещё с доисторических времён существуют :)
                                            0
                                            Хотя бы тем, что «i» в имена функций добавили

                                            Почти все изменения фиксятся чуть ли не автозаменой в блокноте. Не вижу никаких сложностей с переносом древнего кода с mysql на новые рельсы. Это не на PDO переезжать.
                                            Переучиваться всегда неудобно

                                            Да это же разве переучиваться? И сколько нужно было спать в анабиозе, чтобы пропустить закапывание mysql и рост использования mysqli?
                                            Вы про конструктор запросов?

                                            Нет, просто про объектный интерфейс, из коробки сразу писать $mysqli->query(«запрос») вместо таскания идентификатора соединения при вызове каждого метода. А раньше нужно было писать для этого объект с обёртками функций и приватным полем с коннектом.
                                            Вот это упустил. Пожалуй, и правда стоит её изучить получше)

                                            Это нужно было сделать лет 10 назад.
                                            А там, где оно ограничено — инъекции и так практически исключены.

                                            А с подготовленными запросами полностью. БД просто не будет парсить эти ваши строки в поисках каких-либо тегов, она заранее знает, где строка, где число. Можно напрямую вставлять
                                            Robert'); DROP TABLE Students;-- 

                                            и именно эта строка сохранится в БД, вместо стирания таблиц со студентами в mysql, когда забыли про экранирование.
                                              0
                                              Да это же разве переучиваться?

                                              Да, имхо, другой порядок аргументов и их количество — это переучиваться.

                                              вместо таскания идентификатора соединения при вызове каждого метода

                                              Зачем его таскать? У вас больше одной базы данных используется единовременно? Насколько я знаю, если коннект один — дескриптор соединения передавать не нужно, библиотека использует текущий автоматически (если про mysql речь идёт, по крайней мере).

                                              А раньше нужно было писать для этого объект с обёртками функций и приватным полем с коннектом.

                                              Я вот не писал его, и всё отлично :)

                                              И сколько нужно было спать в анабиозе, чтобы пропустить закапывание mysql и рост использования mysqli?

                                              Я как научился использовать PHP по учебникам 2004-2005 года, так его и использую. Да, в 2012-ом смотрел новые возможности версий 5.3 и 5.4, особенности реализации ООП, трейты. Но использовать это всё как-то так и не решился :)

                                              Это нужно было сделать лет 10 назад.

                                              Вот здесь я вас не понял. Я про то, что можно фильтровать переданные данные ещё строже, чем их отфильтрует функция экранирования вроде mysql_real_escape_string (и это ещё безопаснее, на мой взгляд). Вы не согласны с этим разве?

                                              она заранее знает, где строка, где число

                                              Ага, то есть типизация значений там имеется? Это хорошо. Я, впрочем, явно всегда тип указываю (строки фильтрую через стандартную функцию, остальное — принудительно к int).
                                                0
                                                Да, имхо, другой порядок аргументов и их количество — это переучиваться.

                                                С вами тяжко.
                                                Зачем его таскать?

                                                Для однозначности.
                                                Я вот не писал его, и всё отлично :)

                                                Кто-то и лапшекод пишет, и им отлично, примерно до момента, когда всё это добро нужно расширять и поддерживать.
                                                Я как научился использовать PHP по учебникам 2004-2005 года, так его и использую.

                                                Это плохо. Необходимо профессиональное развитие, если вы на этом зарабатываете. Специалист со знаниями 10-летней давности не самая востребованная вещь.
                                                Вот здесь я вас не понял.

                                                Я имел в виду переход на mysqli.
                                                Не хочу показаться снобом, но писать имена таблиц и столбцов без обратных кавычек в качестве обрамления — имхо, моветон :)

                                                Это вообще была отсылка к xkcd.
                                                  0
                                                  примерно до момента, когда всё это добро нужно расширять и поддерживать

                                                  Вы немного валите всё в кучу. Лапшекод — да, его поддерживать сложно, сам не раз с этим сталкивался. Не имею ничего против Ваших слов, что это — зло. Но зачем таскать дескрипторы, если коннекшн один?.. Вам что, нечего делать, как печатать лишние буковки? Или это задел на некую туманную отдалённую перспективу, когда в результате расширения системы коннекшнов станет много, и их будет целый пул? Ну так когда будет — напишете и обёртку, и менеджер пула дескрипторов, и что угодно. И желательно на ООП. А пока этого нет — зачем ерундой страдать и терять время?
                                                  Это плохо. Необходимо профессиональное развитие, если вы на этом зарабатываете. Специалист со знаниями 10-летней давности не самая востребованная вещь.

                                                  Ну почему, если мне моих знаний хватает для реализации нужных вещей?
                                                  Это вообще была отсылка к xkcd.

                                                  Я знаю, к чему была эта отсылка :) Но ведь обратные кавычки не просто так используют? А ведь я всё ещё встречаю код, где их нет: недавно вот на StackOverflow начинающий программист задавал вопрос, их там не было, да и под SQLite почему-то принято их не использовать — не знаю, это свойство СУБД их не поддерживать, или просто традиция разработки.
                                                    0
                                                    Вам ниже другой человек уже ответил, весьма правильно. Вы вольны использовать любые инструменты, только не удивляйтесь, когда через пару лет вы не сможете найти себе работу, не сможете подключить современную библиотеку или ограничения старых инструментов не дадут использовать новую штуку.
                                                      0

                                                      практика показывает что описанная вами ситуация случится ой как не скоро… и это меня сильно печалит.

                                                  0
                                                  У вас больше одной базы данных используется единовременно?

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


                                                  В любом случае я не очень понял вашу мысль… дискриптор на коннекшен то один но вы его явно должны задать.


                                                  Я как научился использовать PHP по учебникам 2004-2005 года, так его и использую.

                                                  то есть за ~10+ лет скоуп ваших задач никак не поменялся? Или PHP просто не так часто проскакивает в списке ваших каждодневных задач? Можете немного описать контекст использования вами PHP?


                                                  Но использовать это всё как-то так и не решился :)

                                                  Ну вот и славно, не используйте трейты.

                                                  0
                                                  DROP TABLE Students

                                                  Не хочу показаться снобом, но писать имена таблиц и столбцов без обратных кавычек в качестве обрамления — имхо, моветон :)
                                                  И кстати, скорее всего, есть возможность сконфигурировать СУБД так, чтобы имена без такого обрамления не трактовались как имена таблиц и столбцов от слова «совсем». А перед отправкой запроса на сервер — банально удалять из всех строк обратные кавычки (если они не требуются нам в тексте, иначе придётся что-то придумывать). При таком раскладе инъекция тоже не сработает.
                                      0
                                      Не к обеду, конечно, но насколько в России популярен движок Битрикса, а про него ни слова.
                                      Это от «местами несовместимости», или просто возиться не хотелось?
                                        0
                                        Думаю, просто многие избегают даже произносить это слово :-)
                                          –1
                                          Просто Битрикс очень тяжёлый)
                                            0
                                            А может он просто не очень грамотно написан с точки зраения архитектуры? и подталкивает программистов к работе в режиме «костыль лучшее лекарство»? я не эксперт по битриксу, но из того что слышал это как бы не сборник «best practices», а скорее наоборот. Не хочу никого обидеть. :-) Кстати php ы этом смысле особенно до 7 не очень настаивает сам по себе на best practices. Считается практически одним из самых простых, порог входа в индустрию программирования со стороны php очень низкий. То есть доля недообразованных программистов в php значительно выше чем в других языках. Но зато нас намного больше! Берем количеством, а не качеством, так сказать :-(
                                              0
                                              Но Битрикс такой медленный не поэтому. Тем более, CMS Wordpress, которая вообще не использует ООП подход (раньше как минимум так было, сейчас не в курсе) — одна из самых быстрых. Так что ИМХО, проблема в излишней сложности архитектуры и навороченности…
                                                0
                                                Я правильно вас понимаю, по-вашему, ООП приводит к потере производительности по умолчанию? У меня очень другое определение для понятий ООП и архитектура. По-моему, когда архитектура правильная, например как у unix систем, то они работают стабильнее и быстрее по умолчанию в сравнении с системами у которых были допущены архитектурные ошибки, скажем windows. И вопрос для меня стоит не в «сложности архитектуры» а в самой Архитектуре как таковой. Если архитектура правильная, ну или назовите ее «удачная», то система поддается модификации и поддержке без больших потерь качества и производительности. А вот если архитектура плохая или я соглашусь на «неудачная», тогда имеем проблемы в очень многих ситуациях, практически неизлечимые без интервенции в Архитектуру решения. Слово «сложность» в данном случае это попытка оправдать неудачную архитектуру определенного продукта. Я уверен что Magento не проще а может и сложнее Bitrix, но судя по всему проблем значительно меньше. Так что дело не в псевдосложности Bitrix, а именно в его архитектуре. И я считаю что ООП не привносит особых изменений в производительность по определению, это всего лишь другой способ написания кода. Как его писать правильно — это отдельная история.
                                                  0
                                                  Абсолютно согласен со всем вышенаписанным по поводу хорошего и плохого дизайна. Но хотелось бы просто напомнить про тот нюанс, что ООП подразумевает а) представление сущностей в виде объектов, б) контроль доступа к полям и методам, в) хранение информации о цепочках наследования. Это далеко не полный список. Каждый из этих пунктов жрёт дополнительную память. И это независимо от величины стека вызовов, который у нас образуется в рантайме, просто на хранение вот этого всего, как минимум для созданных нами объектов, уходит память. А теперь представим, что наш проект — к памяти требователен, по каким-то причинам… И какой код будет работать стабильнее, с ООП или с лапшой в коде? :)
                                                    0
                                                    Вот вы сами и «споткнулись» в рассуждениях. Да, пару байт или тактов процессора можно сэкономить без ООП. Но вот «зуб даю» что стабильнее будет работать ООП код :-) И если мы не говорим о чем-то маленьком или эмбедед и драйверах, а говорим об Приложениях или Application с достаточно сложной структурой, множеством модулей и взаимодействием и интеграцией с другими системами, то «спагетти-код» никогда не будет работать стабильно, вот просто никогда :-) (это конечно мое сугубо личное мнение)
                                                      0
                                                      А что мы подразумеваем под «стабильно»? «Корректно на данный момент на данных тестовых кейсах/по отзывам юзеров», или «Корректно всегда, даже после внесения серьёзных изменений»? Если первое — то возможно, хоть и сложно, и при спагетти коде. Если второе — тут беда.
                                                        0
                                                        По поводу Embedded не очень согласен. Вот представим большое приложение, с кучей модулей, большими, сложными запросами, и слабое железо (например, по причине дешёвого хостинга или виртуального сервера). Допустим, есть тормоза, видные на глаз. Неужели влияние на уменьшение этих тормозов путём написания не-ООП кода будет мизерным? Я тестов не проводил, хочу узнать, как оно на самом деле)
                                                          0
                                                          Да, изменения в РНР коде не дадут почти никакого эффекта. Сегодня, и уже давно, купить железо в 2 раза сильнее стоит в 10 раз дешевле чем переписать код и приносит результат сразу и в разы, в том время как переписка/рефакторинг кода занимает кучу времени у кучи специалистов и приносит насколько процентов производительности.
                                                          Например если у вас сатрый комп который типа LAMP все в одном и у вас проблемы с проихводительностью, то купив два новых компа и разнеся РНР и MySQL на разные машины вы с высокой долей вероятности решите проблемы производительности за один день. Причем с доступностью облаков сегодня — это проверяется за пару часов в облаке за 2 бакса. Стоимость разработки это бич бизнеса сегодня. И еще раз — если вы будете переписывать ООП код в функциональный ради выигрыша в производительности в сложной системе, то во-первых вы с высокой степенью вероятности облажаетесь, а во вторых это будет стоить страшных денег в разы превосходящих замену железа.
                                                            0
                                                            Итого, резюмируя — работа с классами и объектами не имеет ощутимых накладных (во всяком случае, в PHP 7.x)? Если имеет — то насколько они велики?
                                                              0
                                                              Ну, я когда начинал разработку одного довольно крупного портала, специально замерял время полного рендеринга одной страницы элемента данных из каталога (и обзорных страниц тоже). В измерение входило и обращение к базе данных, и все необходимые запросы к ней (более детально не мерил).

                                                              На старте разработки у меня показатели равнялись 18-24 мс при первой загрузке, и 10-13 при повторных (благодаря IonCube Optimizer, и возможно, кэш MySQL запросов играл роль). Когда я померил спустя год — та же страница рендерилась уже 40-50 мс при первой загрузке (т.к. существенно усложнилась бизнес-логика системы). Страница, где генерировался живой календарь на 100 дней (без кэширования) — та вообще очень долго рендерилась, примерно под 80-90 мс. Понятное дело, был бы я поумнее — сделал бы кэш этого календаря, и скорее всего то, что я вынес часть функционала в инклюды, сильных тормозов не дало (хотя это тоже требует дополнительных обращений к диску для PHP движка, как мне кажется), проблема была в усложнении самого кода.

                                                              Получается, если бы я использовал ООП, показатели не просели бы очень существенно? :) Я не из головы просто фантазирую, а в самом деле, когда я смотрел бенчмарки производительности разных функций PHP версии не то 5.3, не то 5.4, применение конструкторов и других элементов ООП парадигмы было одним из самых узких мест. Проигрыш был в 2.5 — 3 раза примерно.
                                                                +1
                                                                Проблема инклудов в современном РНР это то что оно не поддается кэшированию не уровне opcache который используется всегда, если руки растут из правильного места, я имею ввиду спагетти инклуды.
                                                                В общем, это долгая лекция. Попытаюсь еще раз объяснить. Теоретическая возможность сэкономить пару байт в памяти и пару тактов процессора на практике не выдерживает реальной конкуренции с ООП подходом по следующим причинам: скорость разработки, возможность независимой разработки модулей без потери их взаимосвязанности и взаимозаменяемости, возможность использования сторонних модулей и библиотек, простота работы в команде (где опытный разработчик уже знает как надо писать, а начинающий может легко найти документацию и best practices) так что мы снова экономим дорогое ВРЕМЯ, причем не только не разработку, но на обучение, тестирование, отладку, поиск источников проблем и т.д. Плюс как я уже говорил замена железа стоит дешевле и приносит мгновенные результаты, без необходимости заново тестировать всю систему в случае «оптимизации под память и проц»
                                                                  0
                                                                  А если команда из одного человека, денег — минимум или нет, а время потенциально неограничено? Я в целом понимаю, что в любом случае ООП может дать плюсы (хотя от величины проекта сильно зависит), но всё же? И не очень понятно, что Вы имеете в виду под
                                                                  без необходимости заново тестировать всю систему в случае «оптимизации под память и проц»

                                                                  — типа оптимизировали криво, и всё поломали?
                                                                    0
                                                                    (хотя от величины проекта сильно зависит)

                                                                    давайте так. плюсы дает модульность. ООП это все же про рантайм, про объекты и их взаимодействия, а не про классы и как оно там по файлам раскидано.


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


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


                                                                    Поскольку мы хотим в идеале свести расстояние от кода, который производит побочный эффект (изменяет состояние системы) до того где это состояние хранится к минимуму, нам было бы идеально описывать стэйт и код по работе с этим стэйтом в рамках одного модуля. В PHP выбор в этом плане не велик — это могут быть только классы.


                                                                    Как вы дробите логику. это уже второстепенный вопрос. Основной все же — как быстро проследить сайд эффекты и предсказать как система будет вести себя в рантайме. Именно это позволяет нам быстрее и дешевле заниматься поддержкой приложения (а так же вопросом передачи знаний о проекте между разработчиками, это часто выкидывают из уравнения и потом удивляются "а почему это так сложно найти норм разработчиков… что бы выхлоп был надо что бы чел 4 месяца хотя бы плотно с кодом работал что бы разобрался что к чему".

                                                                    0
                                                                    Теоретическая возможность сэкономить пару байт в памяти и пару тактов процессора

                                                                    Пара байт и пара тактов — нет. А несколько мегабайт и пара сотен или тысяча тактов? Как я писал уже в каком-то комменте, по одному из официальных бенчей разница в 2-3 раза выходила по времени отработки на ряде «тяжёлых» функций.
                                                                    который используется всегда, если руки растут из правильного места

                                                                    Вот здесь тоже не понял. Что нужно делать, чтобы opcache использовался?)
                                                                      0
                                                                      тысяча тактов

                                                                      О Боги, мы все умрём за время, пока исполнятся тысяча тактов процессора!
                                                                      Вот здесь тоже не понял. Что нужно делать, чтобы opcache использовался?)

                                                                      С PHP 5.5 в общем-то ничего, он идёт из коробки, если кто-то с кривыми ручками его не отключит в конфиге, который заботливо переносился со времён PHP 4.
                                                                        0
                                                                        Хм. Почему-то при переезде с 5.3 на 5.5 того самого проекта существенной разницы в скорости я не заметил…
                                                                          0
                                                                          Опкешеры были доступны и раньше, возможно, использовались они, разница между ними действительно не столь велика.
                                                                          Попробуйте перейти на семёрку, вот там уже разница около двух раз.
                                                                        0
                                                                        Уважаемый, мне жаль вас огорчать, но вам надо просто еще многому учиться, учиться и еще раз учиться. Настоятельно рекомендую сделать 2-3 проекта в команде! чтобы были сроки сдачи и заказчик с дубиной за спиной. Ваши вопросы нестолько наивны и понятны, что я устал уже пытаться на них отвечать. Идите, пробуйте, читайте. Истина где-то рядом. Формат комментариев не подходит как системный инструмент для обучения, но похоже вы и об этом пока не догадываетесь. За сим дискуссию закрываю, вы уж меня извините.
                                                                    0
                                                                    Сегодня, и уже давно, купить железо в 2 раза сильнее стоит в 10 раз дешевле

                                                                    Это если вообще есть деньги. А если проект только начинается и в кармане ноль, а железо — слабое, что тогда? Всё равно нет смысла мучиться, т.к. выигрыш никакой?
                                                                      0
                                                                      Не надоело по пятому разу одно и тоже спрашивать? Нет, смысла мучаться нет. У меня есть дядя, он до сих пор считает что если программист не знает и не понимает ассемблер — то он не программист. Это просто другое измерение — хочется считать биты и байты — идите в Си и Ассемблер — там своя красота и свои лучшие практики. А если работаете на РНР, то извольте разобраться зачем его изобрели и как правильно и красиво писать на выбранном языке. Вся индустрия уже одной ногой в облаках, пока вы будете ковырять свой старый сервер, пытаясь выжать из него последнее, человечество улетит на Марс, а вы останетесь один на один со своим старым другом-серваком, на котором посыпется винт.
                                                                        0
                                                                        а вы останетесь один на один со своим старым другом-серваком, на котором посыпется винт

                                                                        Дело не в том, винт или SSD. Можно купить VPS на платформе виртуализации, где будут дико урезаны ресурсы по процессору и по I/O (считайте, по доступу к накопителю). А можно иметь сервер на старом нетбуке (как у меня дома), где вроде как SSD, но по скорости — вдвое хуже, чем ноутбучные винты тех лет.

                                                                        Это просто другое измерение — хочется считать биты и байты — идите в Си и Ассемблер

                                                                        На мой взгляд, при разработке на любом языке есть место быстрому коду, оптимизациям, эффективным алгоритмам. С Марсом — красиво, но маниловщина. Облака — тоже спорная штука) И потом, при чём тут Марс и написание сайтиков на PHP? Нашли тоже, что сравнивать.

                                                                        А если работаете на РНР, то извольте разобраться зачем его изобрели и как правильно и красиво писать на выбранном языке.

                                                                        В целом, понимаю Вашу логику, и в целом, теоретически, согласен. На самом деле, там действительно имели место некоторые серьёзные проблемы с производительностью ООП в пятой ветке. Всё, что я хотел от вас услышать — «в семёрке такого нет, можете расслабиться и забыть про это». Но судя по Вашим ответам, Вы или не в курсе тех проблем, или Вам пофиг. Если второе — то вообще печаль.
                                                                          0
                                                                          Вы просто предлагаете оптимизировать широкое место, где и так проблем нет. Тормоза идут от соединений с БД и сторонними сервисами, сетевом взаимодействии вообще, от тяжёлых вызовов, например, при работе с графическими библиотеками, от циклов на миллионы итераций. Создание и уничтожение объектов, будь оно хоть в 20 раз медленнее, никак не скажется на скорости выполнения приложения, потому что никакой профайлер не покажет вам разницу в шестом знаке после запятой.
                                                                            0
                                                                            На мой взгляд, при разработке на любом языке есть место быстрому коду, оптимизациям, эффективным алгоритмам.

                                                                            вопрос издержек на поддержку. Если "быстрый код" генерится из красивого DSL который прост и понятен — то это норм. Если вам надо "руками писать" этот быстрый код, то я нахожу это не эффективным, с учетом того что многие из проблем решаются сбором статистики выполнения и кодогенерацией в рантайме (JIT).


                                                                            Существуют конечно задачи где прям максимум надо выжать, и именно там надо загоняться, но это 0.01% от задач которые решают PHP разработчики. В качестве такого примера — приходилось мне как-то кластеризацию точек на kmeans писать на PHP. Что бы можно было меньше чем за минуту пересчитать 200K точек (O(N^2)). В итоге kmeans был заменен чуть другим алгоритмом дававшим схожий по точности результат, но работавший за O(NlogN). И когда речь идет о 210^10 итераций и 210^6 итераций, та константа, где надо метод вызвать, не играет особо роли.


                                                                            Но судя по Вашим ответам, Вы или не в курсе тех проблем, или Вам пофиг.

                                                                            Проведите собственное исследование вопроса) И заодно попробуйте погонять то же самое на dev-master версии PHP (там уже немало оптимизаций маленьких понапихивали). И тогда уже делайте выводы. А то верить людям в интернетах — дело такое...

                                                              0
                                                              одна из самых быстрых

                                                              С чем вы сравниваете? Для бложика на WP 1 секунда на запрос (без кэша) это нормально. И проблема там в архитектуре а не в "ооп или не очень".


                                                              проблема в излишней сложности архитектуры и навороченности…

                                                              битрикс… архитектура… навороченность… ну ладно. Вы же понимаете что вы сравниваете производительность платформы для блогов и платформы для ecom? Попробуйте напихать плагинов в WP что бы оно походило на bitrix и сравните производительность (без кэша). А потом варниш сверху и туда и туда.

                                                                0
                                                                Так Вы полагаете, дело исключительно в обилии функционала и модулей серьёзных платформ, которых нет у WP? Ну тогда по той же причине и Битрикс, скорее всего, такой тормозной. Видел я в своё время сайт на Joomla 1.5 на среднем хостинге (неплохом достаточно по характеристикам, мои проекты на нём не тормозили особо) с 20-30 подключенными плагинами. Это было что-то. Страницы по 3-4 секунды грузились. И это при не такой высокой нагрузке в плане посетителей.
                                                                  0
                                                                  Вы полагаете, дело исключительно в обилии функционала

                                                                  в универсальности. Сами понимаете что универсальное решение не может быть эффективнее специализированного. Ни в плане поддержки ни в плане производительности.


                                                                  Страницы по 3-4 секунды грузились.

                                                                  я видел блоги на WP где страницы столько грузились, и самописы, и на фреймворках… при схожей сложности. Видел и делал так же системы где допустимы порог отдачи контента 100ms и это более чем реальная задача для какой-нибудь симфони где все упирается в так нелюбимое вами ООП. А если загнаться те же 100ms можно превратить в 10ms. Это уже вопрос архитектуры и т.д. и для этого не надо "отказываться от ооп".

                                                        0
                                                        Это же перевод. Не думаю, что за пределами ex-USSR кто-то вообще знает о существовании этой CMS.
                                                          0
                                                          Даже в некоторых ex-USSR странах не знаем и знать не хотим :)
                                                            0
                                                            Вы не одиноки, я тоже придерживаюсь этого табу :)
                                                              0

                                                              Вы теряете много, особенно в разделе юмор. А так, кто-то на ИТ конференции говорит Битрикс и уже весь зал ржет.

                                                          0
                                                          Было интересно кроме самих цифр увидеть какой-то анализ, почему в одних случаях разница между 7.0/7.1/7.2 существенна а в других нет, или почему так выбивается laravel c hhvm?
                                                            0

                                                            Скажите пожалуйста, а почему, на ваш взгляд, не рассматривался Yii2? Разве он настолько не популярен?

                                                              +1

                                                              Забавно, что в бенчмарк попал Craft CMS, сделанный на Yii2, но не попал сам Yii2 :)

                                                                0
                                                                Возможно удивлю, но скорее там все таки еще Yii1
                                                                craftcms.com/changelog
                                                                Released on Jun 9, 2017 Updated Yii to 1.1.19.
                                                                Yii2 не упоминается здесь не разу
                                                            0
                                                            Было любопытно посмотреть на тестирование версий PHP по отношению к Laravel. А что на счёт других фреймворков? Может кто видел свежие статьи на эту тему?
                                                              0
                                                              На phpbenchmarks другие результаты обработки по SF / Laravel
                                                                –2
                                                                Не очень понимаю смысл сравнения производительности разных версий, в чем суть выпуска новой версии без увеличения скорости работы, было бы полезнее провести сравнения скорости работы php vs c#, java, nodejs, golang. Ах да, пыхыпэ там будет сильно отставать.
                                                                  0
                                                                  Это ещё нужно проверить что будет отставать. Если говорить о php5 + symfony 2 то это так. Но теперь есть
                                                                  Php7 + symfony 4. И все нужно проверять заново и на реальных задачах и с включенными кэшами и с insert в базы данных. И с 1000 конкурентных обращений. Эта статья мне понравилась не столько цифрами и выводами, сколько самим перечнем cms в которых авторы явно знают толк. Кстати если уже на то пошло не попала базовая cms от сообщества symfony — zulu
                                                                    0
                                                                    Я в своё время написал микро-движок для блога, хранящий посты в файлах и не нуждающийся в БД. Было бы интересно потестить под нагрузкой в режиме «на чтение» и сравнить производительность с традиционными CMS. С одной стороны, СУБД очень умно кэшируют наиболее частые запросы, и там есть горячий кэш. С другой стороны, обращение к СУБД — это или межпроцессный обмен данными через сокет, или даже TCP запрос на другой узел, что как бы уже заведомо создаёт задержки =) Плюс управление сессиями, авторизация, проверка прав доступа на стороне СУБД.
                                                                      0
                                                                      >> межпроцессный обмен данными через сокет, или даже TCP запрос на другой узел
                                                                      Конкурентный доступ к файлу на медленном диске всяко будет проигрывать нормальной БД.
                                                                        0
                                                                        Системный кэш файловой системы на мелких (ну вы же не собираетесь читать и парсить что-то огромное, я надеюсь) файлах быстрее БД. Иначе зачем нужен Nginx для статики, а?
                                                                          0
                                                                          Вот-вот, там в файлах маленькие тексты хранились, 1-2 страницы формата А4. Это же кэшируется без проблем, если нам нужно только чтение :)
                                                                      0
                                                                      А можно добавить ещё в статью, что не так с HHVM и почему его все начали выкидывать?
                                                                        0
                                                                        А что статья? Просто PHP7 показывает аналогичную производительность безо всяких минусов HHVM, а ведь туда ещё JIT не прикрутили. То есть HHVM стал просто не нужен.
                                                                          0
                                                                          А какие там минусы?
                                                                            0
                                                                            Необходимость компиляции, медленное внедрение поддержки возможностей новых версий PHP, свои глюки, отсутствие поддержки расширений чистого PHP, отсутствие на шаред-хостингах. Кажется всё. С этим ещё можно было мириться ради скорости в нагруженных проектах, но сейчас и её нет. Если они в ближайшее время не сделают опять отрыв раза в полтора-два, то его можно будет смело закопать.
                                                                              0
                                                                              Необходимость компиляции

                                                                              какой компиляции?


                                                                              Основная проблема HHVM — не полная совместимость между PHP.

                                                                                0
                                                                                какой компиляции?

                                                                                JIT наверное.
                                                                                  0

                                                                                  наверное? Фишка JIT в том что никакой пред компиляции не нужно. В том же PHP тоже есть процесс "трансляции" php в опкоды, причем штуки вроде opcache их могут менять по своему усмотрению. Вы же это в минусы не записываете?

                                                                                    0
                                                                                    Верно, я читал про HHVM когда он ещё был простым HipHop с компиляцией. Действительно, сейчас первый минус отсутствует, признаю свою ошибку.
                                                                        0
                                                                        Интересно, чем мотивируется выбор конкретных платформ?

                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                        Самое читаемое