Какую версию php выбрать для сайта

Выбрать версию PHP под определенную CMS и не плакать

“Я же сказал — полетели, а не побежали!”
“Давай, страус, пошел! Работаем, работаем!”

PHP сейчас один из самых популярных языков программирования, используемых для создания сайтов. На shared linux веб хостинге в России с выбором версии PHP не совсем гладко, хотя встречаются исключения из этого правила.
Почему выбор версии необходим? Интересно? Добро пожаловать под кат!

Рассмотрим системные требования самых распостраненных CMS на рынке России — WordPress, Bitrix, Drupal и Joomla к версиям PHP (про модули говорить не будем, это тема для отдельной статьи):

У себя мы используем CloudLinux, который по пакетной базе соответствует CentOS 6.7. Ситуация “из коробки” не радужная – версии PHP весьма старые.
А те клиенты, у которых сайт создан давно и CMS не обновлялась (а таких немало приходит к нам с других хостингов) как правило хотят ровно обратного — более старых версий PHP из-за того, что на их CMS имеются проблемы с совместимостью.
Так что выходов два: либо собирать самому из исходников, либо ставить из сторонних репозиториев, что не всегда возможно.

Немного остановлюсь на агенте, который взаимодействует между ЛК и системой где развернут хостинг. Агент (написан на питоне) представляет из себя службу с документированным api, позволяющую взаимодействовать с CloudLinux`ом. в качестве оркестратора. Касаемо PHP — агент позволяет изменить версию и настройки для определенного клиента. При создании новой услуги (пользователя) агент использует предустановленные настройки, которые позже можно сменить на кастомные.

Если интересно узнать как все это устроено более детально, жду комментарии по наиболее интересным моментам.

Если вы увидите какие-либо ошибки в статье — пишите пожалуйста об этом в личку.

Источник

Как выбрать тот самый PHP-фреймворк. Сравнительное тестирование

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

Для этого нужно учесть достаточно большое количество характеристик, от «как быстро всё будет работать» до «а необходима ли нам эта фича?». И так каждый раз. Именно в моменты мозгового штурма команда сравнивает удобство фреймворка, скорость, набор фич, которые реализованы в нем или в совместимых с ним модулях.

Но какой же всё-таки лучше, быстрее и производительнее?

Разработчики постоянно проводят сравнение фреймворков, чтобы прояснить для себя этот вопрос. Например, в статье Lukasz Kujawa приведено сравнение PHP фреймворков. Одно «но» — статья за 2013 год. А ведь время идёт… Поэтому мы решили провести своё, актуальное сравнение фреймворков.

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

Одной из основных целей данной статьи также является попытка практическим путем определить улучшения в производительности и эффективности новых версий PHP. Поэтому тестирование было проведено на РНР 5.6/7.0/7.1

Что будем сравнивать?

Для сравнения были выбраны следующие фреймворки:

Методика тестирования и тестовый стенд

Машина, на которой производилось тестирование, обладает следующими характеристиками:

Operation system: Linux Mint 17 Cinnamon 64-bit
Cinnamin Version 2.2.16
Linux Kernel: 3.13.0-24-generic
Processor: Intel Core i3-4160 CPU 3.60 Ghz X 2
Memory: 8 GB

Server version: Apache/2.4.7 (ubuntu)
Server build: Jul 15 2016
php 7.1 / php7.0 / php5.6

Вводим команду git clone https://github.com/kenjis/php-framework-benchmark — и фрейм уже на нашей машине. Поскольку мы использовали Mint, необходимо выполнить настройку:

# Added net.netfilter.nf_conntrack_max = 100000 net.nf_conntrack_max = 100000 net.ipv4.tcp_max_tw_buckets = 180000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 10

Немного о структуре самого php-framework-benchmark:

/benchmarks — содержит bash-скрипты, отвечающие за сбор информации о количестве запросов в секунду (при помощи утилиты ab), количестве информации, сколько времени было потрачено и сколько файлов вызывалось из файла «точки старта».

/lib — директория, в которой находятся файлы, отвечающие за обработку полученной информации после вывода страницы “Hello world”, вывод таблиц с результатами и построение диаграмм.

Остальные папки — это заготовки фреймов, в которые уже добавлен один контроллер, который вернет строку “hello world” при обращении по URI, составленному по правилам обращения к данному фреймворку.

Для запуска теста сначала нужно настроить фреймворки. Рассмотрим два подхода.

Команда bash setup.sh настроит те фремворки, которые описаны в файле list.sh. Вы можете его редактировать: добавлять и удалять папки для тестирования. То есть конфигурировать так, как вам необходимо.

Командой bash setup.sh fatfree-3.5/ slim-3.0/ lumen-5.1/ silex-1.3/ вы можете установить какие-то отдельные фреймворки, задав их параметрами к команде. В некоторых случаях это удобно, но мы использовали первый подход.

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

Для отображения графиков мы воспользовались ссылкой http://localhost/php-framework-benchmark/.

Как вы понимаете, необходимо было произвести настройку Apache и заставить его смотреть в папку с фреймом. Всё это описано в readme, поэтому вопросов не возникает.

Результаты тестирования фреймворков

Каждый раздел имеет структуру, состоящую из двух форм представления результатов.

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

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

Производительность (throughput)

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

Мы получили следующие результаты (запросы в секунду):

* — bluz-7.3.1 не поддерживает php 5.6

Для наглядности построили графики для каждой версии PHP:

PHP5.6:

PHP7.0:

PHP7.1:

Сводная накопительная диаграмма (по фреймворкам):

Занимаемая память (peak memory)

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

* — bluz-7.3.1 не поддерживает php 5.6

PHP 5.6:

PHP 7.0:

PHP 7.1:

Сводная накопительная диаграмма (по фреймворкам):

Время выполнения

Время выполнения — время, затрачиваемое системой для выполнения поставленной задачи. Измеряется от начала выполнения задачи до выдачи результата системой.

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

Время приведено в миллисекундах (ms):

PHP 5.6:

PHP 7.0:

PHP 7.1:

Сводная накопительная диаграмма (по фреймворкам):

Подключаемые файлы

Характеристика, отвечающая за количество подключаемых файлов, которые описаны в файле «точки входа» фреймворка. Понятно, что система тратит какое-то время на поиск и подключение. Следовательно, чем меньше файлов, тем быстрее будет осуществляться первый запуск приложения, так как обычно в последующие разы фреймворк работает с кэшем, что ускоряет работу:

Разница в количестве подключаемых файлов между Laravel 5.3 и Laravel 5.4 может показаться странной и дать повод к обсуждениям, спорам и т.п. Спешим разъяснить ситуацию. Как вы знаете, с помощью команды

в Laravel 5.3 можно сгенерировать файл compiled.php, и тем самым уменьшить количество подключаемых файлов, собрав их в один. Но есть одно «но»: команды для генерации этого файла в Laravel 5.4 больше нет. Разработчик решил удалить эту фичу, так как посчитал (https://github.com/laravel/framework/pull/17003), что для настройки производительности лучше использовать opcache.

Стоит ли обновляться?

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

При переходе с PHP 5.6 на PHP 7.0 средний прирост производительности составил почти +90%, при этом минимальный прирост производительности составил +33% для Laravel 5.3, а максимум — >200% для Zend Framework 2.5.

Переход с версии 7.0 на 7.1 уже не так шокирует, но всё же в среднем даёт почти 20% прирост производительности.

Сведя все полученные данные по производительности различных версий PHP, получим вот такие «матрасы»:

Забавный факт: Laravel 5.3 показал наименьший прирост производительности при миграции с PHP 5.6 на PHP 7.0, но при этом наибольший прирост при миграции с версии 7.0 на версию 7.1, и как итог — производительность Laravel 5.3 и 5.4 на PHP 7.1 практически одинакова.

Потребление памяти тоже оптимизировали, так что переход с PHP 5.6 на PHP 7.0 позволит вашему приложению потреблять на 30% меньшем памяти.

Обновление с версии 7.0 до версии 7.1 практически не даёт прироста, а в последних Symfony и Laravel так и вовсе уходим в «минус», потому что они начинают чуть больше «кушать».

Осталось ещё посмотреть на время выполнения, и да, тут тоже всё отлично:

Примечание. Тестирование при помощи ab — с чем мы столкнулись

«А что со slim и phpixie» — этот вопрос подтолкнул на расследование поведения утилиты ab при взаимодействии с этими фреймворками.

Выполним тест отдельно для Slim-3.0:

Concurrency Level: 10
Time taken for tests: 5.005 seconds
Complete requests: 2
Failed requests: 0
Total transferred: 1800 bytes
HTML transferred: 330 bytes
Requests per second: 0.40 [#/sec] (mean)
Time per request: 25024.485 [ms] (mean)
Time per request: 2502.448 [ms] (mean, across all concurrent requests)
Transfer rate: 0.35 [Kbytes/sec] received

Что-то не так — количество запросов в секунду всего 0.4 (!)

Concurrency Level: 10
Time taken for tests: 3.004 seconds
Complete requests: 1961
Failed requests: 0
Total transferred: 1995682 bytes
HTML transferred: 66708 bytes
Requests per second: 652.86 [#/sec] (mean)
Time per request: 15.317 [ms] (mean)
Time per request: 1.532 [ms] (mean, across all concurrent requests)
Transfer rate: 648.83 [Kbytes/sec] received

Дело было в Keep Alive соединении, подробнее можно узнать тут.

“When you make requests with «Connection: keep-alive» the subsequent request to the server will use the same TCP connection. This is called HTTP persistent connection. This helps in reduction CPU load on server side and improves latency/response time.

If a request is made with «Connection: close» this indicates that once the request has been made the server needs to close the connection. And so for each request a new TCP connection will be established.

By default HTTP 1.1 client/server uses keep-alive where as HTTP 1.0 client/server don’t support keep-alive by default.”

Таким образом, тест для Slim должен выглядеть так:

Concurrency Level: 10
Time taken for tests: 3.000 seconds
Complete requests: 10709
Failed requests: 0
Total transferred: 2131091 bytes
HTML transferred: 353397 bytes
Requests per second: 3569.53 [#/sec] (mean)
Time per request: 2.801 [ms] (mean)
Time per request: 0.280 [ms] (mean, across all concurrent requests)
Transfer rate: 693.69 [Kbytes/sec] received

Заключение

Как и стоило ожидать безоговорочным лидером по производительности (но не скорости разработки) является Phalcon. Второе место, — а на самом деле первое среди PHP-фреймворков (а не C, на котором написан исходный код Phalcon) — занимает CodeIgniter 3!

Конечно же, не стоит забывать, что каждому инструменту своё предназначение. Если вы выбираете небольшой и легкий фреймворк и собираетесь написать на нём что-то отличное от простейших приложений или REST API, то, скорее всего, вы столкнётесь с проблемами при расширении функционала. И наоборот — избыточность полнофункциональных, больших фреймворков повлечёт за собой финансовые издержки на содержание хостинга даже для элементарных приложений под большой нагрузкой.

Это тестирование проводилось для того, чтобы убедить/рассказать/укрепить позицию языка РНР версий 7.0 и 7.1 в вашем сознании и в будущих проектах, донести информацию о том, что производительность действительно возросла.

Рефакторинг внутренних структур данных и добавление дополнительного этапа перед компиляцией кода в виде абстрактного синтаксического дерева — Abstract Syntax Tree (AST), — привели к превосходной производительности и более эффективному распределению памяти. Результаты сами по себе выглядят многообещающе: тесты, выполненные на реальных приложениях, показывают, что PHP 7 в среднем вдвое быстрее PHP 5.6, а также использует на 50% меньше памяти во время обработки запросов, что делает PHP 7 сильным соперником для компилятора HHVM JIT от Facebook.

Источник

Версии PHP: зачем их обновлять и чем они различаются

Почти 80% всех существующих сайтов, по данным W3Techs, работают на базе языка программирования PHP. Значительную их часть составляют сайты, созданные с помощью WordPress и других популярных CMS. Однако, несмотря на такую распространнёность, не все владельцы сайтов знают о необходимости переходить с устаревших версий PHP на более актуальные. Что отражается на качестве работы сайтов.

Кратко о версиях PHP

Какие версии PHP считаются актуальными, а какие — устаревшими? Чтобы разобраться в этом, рассмотрим этапы жизненного цикла версий этого языка:

Релиз. Выпускается новая версия PHP, которая прошла все этапы предварительного тестирования и подходит для использования в «боевых условиях».

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

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

Завершение жизненного цикла. Через год критических обновлений защиты версия перестаёт поддерживаться полностью. Однако ей можно продолжать пользоваться, но уже на свой страх и риск.

На момент публикации этого материала продолжают поддерживаться три версии PHP:

7.4 (дата релиза — 28 ноября 2019 года, самая актуальная версия);

7.3 (дата релиза — 6 декабря 2018 года, активная поддержка подходит к концу);

7.2 (дата релиза — 30 ноября 2017, активно не поддерживается, важные обновления безопасности скоро перестанут выходить).

Версии 7.1, 7.0 и все версии PHP 5 больше не обновляются. А уже в конце 2020 года самой актуальной станет версия 8.0.

А что насчёт PHP 6? Если вы не знаете, почему шестые версии здесь не упоминаются, то сейчас поясним.

PHP 6: строили, строили, но не построили

На разработку версии 6.0 было потрачено немало времени. Предполагалось, что самым важным нововведением в ней станет поддержка символов Юникода, благодаря которой возможности языка были бы расширены. Однако разработчики PHP 6 столкнулись со множеством трудностей, что вынудило их постепенно отказаться сначала от внедрения Юникода, а затем и вообще от запуска версии 6.0.

Пока шла работа над PHP 6, на эту тему было выпущено немало статей и книг. И представление о PHP 6 как о версиях языка с внедрённым Юникодом уже успело устояться в IT-сообществе. Поэтому новому поколению языка, пришедшему на смену PHP 5, было решено присвоить номер 7.

PHP 7: обновление, которое ждали больше 10 лет

Первая версия PHP 7 была представлена ещё в конце 2015 года, но до сих пор почти половина сайтов в мире, по информации WTechs, не перешли на PHP 7 и остаются на PHP 5. Каких возможностей лишены те, кто всё ещё не обновился?

С заботой о пользователях мобильных гаджетов разработчики также поработали над исполнением движка и уменьшили потребление памяти при работе PHP. Также с помощью Abstract syntax tree (AST) операционный код стал более производительным. И в целом код на PHP 7 стал чище, понятнее и удобнее.

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

PHP 8: взгляд в будущее

Версия 8.0 активно разрабатывается в данный момент, но о ней уже кое-что известно. Планируется, что в новейших версиях PHP будет генерироваться меньше кода. Для этого будет использоваться технология JIT (Just in Time). С её помощью при выполнении приложения весь код будет не компилироваться заново, а частично заимствоваться из уже скомпилированных версий.

Компиляции станет меньше и благодаря технологии FFI (Foreign Function Interface), которая упрощает вызов функций, написанных на разных компилируемых языках программирования. Благодаря JIT и FFI производительность PHP 8 должна ощутимо повыситься по сравнению с PHP 7.

Релиз первой альфа-версии 8.0 намечен на лето этого года. Затем традиционно будут представлены несколько альфа- и бета-версий, а также релизов-кандидатов, после чего 3 декабря 2020 года ожидается выпуск финального варианта.

Кратко об обновлении PHP

Какую версию PHP лучше всего использовать? Конечно же, самую актуальную на данный момент. Тогда вы всегда будете получать:

О работе с PHP на VPS мы пока говорить не будем, так как для этого нужен отдельный материал. Поэтому дальше мы дадим рекомендации пользователям виртуального и специализированного хостинга.

Узнайте, какая версия PHP используется на вашем сайте. Эта информация доступна в настройках веб-сервера: например, на хостинге «Джино» они расположены здесь). Владельцы сайтов на WordPress могут увидеть текущую версию PHP в панели администратора, в разделе Инструменты / Здоровье сайта / Информация. Также вы можете написать этот скрипт, разместить его в файлах сайта и обратиться к нему из браузера:

В результате будет показана информация о версии.

Если ваша текущая версия PHP не входит в число поддерживаемых, взвесьте все «за» и «против» перед обновлением. Ведь чем старее скрипты вашего сайта, тем сложнее может быть перейти на поддерживаемую версию PHP. Тем, кто готов обновиться, нужно сделать следующее:

Убедитесь, что у вас сохранена свежая резервная копия файлов сайта.

Проверьте совместимость используемого ПО, фреймворков, библиотек, плагинов с выбранной вами версией PHP. Если что-то из этого не совместимо с ней, убирайте и заменяйте на более современные аналоги.

Измените версию PHP на хостинге, через настройки сервера в контрольной панели или через запрос в техподдержку.

После обновления протестируйте все функции сайта, при тестировании проверяйте лог на предмет «Fatal error» и других ошибок, которых раньше не было. Если все функции работают, а на страницах сайта появляются предупреждения PHP — отключите отображение ошибок.

Если после обновления возникли серьёзные нарушения в работе сайта, верните старую версию PHP. Разберитесь в проблемах сами или обратитесь за помощью к специалистам.

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

Источник