PHP 5.6, 7.0, 7.4 и 8.0 и производительность

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

Немножко истории PHP. Последняя стабильная версия пятой ветки 5.6.40 вышла 10.01.2019 и была объявлена финальной. Первая версия седьмых пых (7.0.0) выложена 3.12.2015, а последняя 7.4.16 от 5.03.2021. Судя по changelog, все чем занимались разработчики седьмой ветки с конца 2015 по начало 2021 года - это фиксили баги, еще раз фиксили баги, и фиксили баги, вызванные предыдущими фиксами багов. За 5 с лишним лет эту версию можно считать стабильной и подходящей для большинства задач в production.

26 ноября 2020 года вышел релиз PHP 8. Объявлена куча нововведений в синтаксисе, хотя именно за подобные вещи я не люблю разный новодел в стандартах языка C++ (например, С++14 и более новые, из-за которых надо еще думать, под каким компилятором данный код соберется без ошибок). Первый наводящий вопрос: через сколько лет PHP 8 станет достаточно надежным для продакшн задач? Возможно, не через 5, но ближайший год я бы ему точно не доверял. Но это чисто мое субъективное мнение. Пост не об этом.

Я проверил несколько образцов кода, приведенных по ссылке выше. Весь код, который писался под PHP 7, работает и под PHP 8, но естественно не наоборот. Не видел 8ю версию в дикой природе (а именно на серверах под посещаемыми и/или нагруженными проектами, все прогрессивное человечество сидит на семерке) потому сказать насколько много исправлений нужно вносить в код какого-либо сайта чтобы его адаптировать с 7 на 8 пока не могу. Пока рабочая гипотеза если писать как для 7 - на 8 запустится без проблем.

Далее. В интернете ходят утверждения что PHP 7.0 в разы быстрее 5.6, а 8.0 значимо быстрее 7.4. Проверяю. Написал бредокод, содержащий вызовы всяких разных функций, различные работы со строками, json, вычисление хешей и RSA шифрование. Не думаю что кого-то интересует данный бенчмарк, но если хотите - могу выложить. Формально код может быть любым, главное чтобы при повторных запусках сложность вычислений сохранялась и не было повторений одного и того же (есть риск что что-то где-то будет закешировано).

Тестирование проводилось на не нагруженном dev сервере, размещенном в одном из крупнейших облачных ДЦ. Сервер простаивает, соседи не надоедают, оверселлинга у провайдера нет. Запускался скрипт через php-cli разных версий последовательно, после чего эксперимент повторялся (всего по 3 замера). Набор модулей как стало с панелью управления из коробки.

Итого. Один и тот же код вызывался в цикле 100 раз, время исполнения данной программы замерялось. Средние по 3 замерам:


О чудо, неужели в PHP 8 что-то настолько оптимизировали? Нет. Я провтыкал что через apt-get надо установить ВСЕ те же модули, которые стоят на остальных версиях и активировать их. Этот php8.0 cli запускался только с 2 модулями - opcache и readline. Несмотря на это json и прочие функции работали, что говорит либо о включении десятка отдельных модулей в php8.0-common, либо о гипотетическом использовании этих модулей из других версий пыхи (не верю). Проверять лень, первое более вероятно. После установки стандартного супового набора запустил тест на PHP 8 еще раз.
Получаю 97.46 секунд, то есть даже дольше, чем на 5.6. Еще одна загвоздочка. Время выполнения тестового скрипта на PHP 7.0 воспроизводится с точностью 2 знака после точки (разница в третьем знаке). Среднеквадратическое отклонение 0.004 сек, если что. Для 7.4 это уже пол секунды, для голой 8 почти секунда, для одетой 8 и 5.6 это 1.43 и 1.84 секунды соответственно. Стабильнее всего один и тот же код по времени отрабатывается почему-то на 7.0. Я не ставил 7.1, 7.2 и прочие промежуточные билды, так как не вижу в этом особого смысла.
После этого запускаю еще пару тестов. PHP 7.0 с модулями только opcache, readline и json отработал за 53 сек, 7.4 за 56 секунд.

Для того чтобы повторить этот тест в идеальных условиях нужно уменьшить время одного запуска, но усреднять большее число запусков (то есть не 3 цикла * 4 версии * минута с лишним, а 10-20 циклов, но время одного запуска уменьшить до десятка секунд. По хорошему прикрутить сюда еще работу с GD, xml, mbstring и другими популярными модулями, но устанавливать на чистый сервер исключительно эти необходимые модули и ничего больше (с учетом того что в 8 несколько модулей интегрированы в один - условия уже не идеальные).

То есть да, производительность 7.0 выше чем 5.6, и значительно. У 7.4 немного ниже, чем 7.0 (не удивлюсь, если другой бенчмарк выдаст одинаковое время, или даже наоборот на те же несколько секунд). С учетом того что в 7.4 что-то там пофиксили - хорошо, переходим с 7.0 сразу на 7.4.
С производительностью 8 версии явно какая-то лажа и эта лажа кроется в одном из установленных модулей. Принципиальных отличий между запуском cli и fpm (или mod_php) нет, потому она же вылезет и при проверке работы PHP на веб сервере.

Но это все касается софта, на котором крутятся ваши сайты. Между 7.4 и 7.0 разница 5-8%, между 7.0 и 5.6 на четверть. Сколько это будет в секундах, если ваш сайт крутится на NVMe хостинге, движок не джумла, отдает страницу за 40-100 мс? Десяток-два миллисекунд? Отлично, это значимая величина для высоконагруженных проектов, но не для домашних страничек.

И все это ни в коем случае не дает право разработчикам плевать на часть клиентов и писать код не совместимый с тем же 5.6 или 7.0 (а я вижу кто-то уже на синтаксис 8.0 не ровно посматривает, как же, это тебе не скобочки вместо array() писать...).

А теперь отвлечемся от привычек нас, малолетних рукожопов, и посмотрим что делают взрослые дядьки в таких случаях. Минимальные системные требования:

• Wordpress - PHP 5.6.20 (пруф, пруф) и заметьте фразочку что на старых версиях в админке появится предупреждение. Не перестанет работать, а предупреждение, Карл!
• Joomla - рекомендуют 7.3, минималка 5.3.10 (пруф).
• DataLife Engine - PHP 5.4 и выше (пруф).
• Drupal - рекомендуют PHP: 7.3, 7.4, 8.0, минимальная 5.4.0.
• OpenCart - PHP 5.4 и выше.
• ModX - рекомендуют 7.2 или 7.3, минимум 5.6.x.
• Typo3 - PHP 5.2.
• NetCat - PHP 5.3 и выше, но не старше 7.0 (уверен что они просто забыли инфу обновить, между 7.0 и 7.4 нет принципиальных различий)
• 1С-Битрикс - Минимальные технические требования PHP 7.2, при этом зачем-то присутствует поддержка Apache 1.3 (куда вы спрятали логику?)

Это то что мне не лень было насобирать. Большинство популярных форумных движков (SMF, MyBB) требуют 5.2 или 5.4 (ладно, проехали, считаем что версий старше 5.6 не существует). IPB действительно переехали на 7.1, но абсолютное большинство солидных продуктов еще поддерживают пятую ветку.

Короче, сказку на ночь заканчиваю. Утверждение ddsyarik абсолютно верное:
Код написаный под 8 пыху, не будет работать на ... (а вместо ... можно подставить любую другую версию PHP), но это абсолютно не повод писать код так, чтобы он не запускался на старых версиях.

Metal Messiah, но лучше использовать последнюю версию, ведь PHP создавался как генератор страниц, было даже расширение .phtml, если к примеру у меня сайт статичный, но на некоторых страницах мне нужен php то тут версия не играет особой роли.
Но в современной версии всё немного усложнилось и скорость работы имеет значение, и неважно какой именно процент того самого прироста мы получаем в итоге, важен сам прогресс.

Metal Messiah, да ты америку открыл с opcache и readline, факт в том, что из коробки 7.x быстрее 5.x. Не знаю, что за бенчмарк ты понаписал, но если верить этим данным: http://www.phpbenchmarks.com/en/, то все видно сразу.

Теперь приведу аргументы в пользу новых версий PHP
1) С 7.0 появился очень удобный синтаксис ??, очень сильно упрощает работу, уже из-за него можно отказаться от устаревшей версии 5.x
Было

Стало

А еще можно цепочку сделать, я даже не хочу ее расписывать для 5.x

2) С 7.0 можно указать тип возвращаемого значения, с 7.1 можно указывать NULL, это очень удобно в IDE (если ты конечно ей пользуешься, а не как школота в notepad++), раньше приходилось это делать в phpdoc, сейчас можно прямо в коде

3) С 7.1 можно отловить несколько исключений в одном блоке

4) С 7.3 можно выкинуть исключения в функциях json_encode/json_decode, если передан невалидный json, раньше приходилось проверять ошибки через json_last_error
5) С 7.4 добавили синтаксис ??=
Было

Стало

6) С 8.0 появилась крутая фича как "Именованые параметры"
Например метод

Раньше для того, чтобы передать один параметр d, приходилось все перечислять, теперь этого делать не надо
Было

Стало

7) С 8.0 появился оператор безопасного null, эта та фича, ради которой я уже перехожу на 8.0, это насколько удобно, что не передать словами
К примеру надо получить ID группы пользователя, но не известно авторизован ли пользователь
Было

Стало

8) С 8.0 в можно указывать несколько типов, иногда бывает полезно


Если раньше на хостингах ставилась одна версия PHP для всех и было проблемно поддерживать актуальную версию PHP, чтобы угодить всем. То сейчас почти везде можно выбрать версию PHP. У кого старые скрипты - сами поставят старую версию. А новые скрипты уже можно писать на php 8.0 и клиенты сами поставят 8.0.

BaHeK, если на хостинге всё понятно и оправдано, то для VPS с ограниченным объемом памяти запуск нескольких версий PHP будет стоить +250мб на каждый экземпляр интерпретатора.
То есть, если у тебя

Это минус 600-700Мб ОЗУ. А к примеру на VPS с 1024Мб на борту это может быть критичным. Пользователь является заложником этой ситуации, когда нужна работа нескольких приложений заточенных под разные версии PHP . По этому оптимизация кода под последнюю версию PHP всегда оправдана.

Я именно в этом и убедился. А 8.0 медленнее 7.4 и только незначительно быстрее 5.6. Так что, дружно переходим на 8.0 и потом 5 лет репортим баги, или сидим на 7.4 и ждем пока 8.0 будет без багов и превосходить 7.4 по скорости?

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

А код должен быть совместим с максимально возможным числом версий. Пусть он будет совместим с 8.0 и 5.6 одновременно, разве сложно так писать?

Да, есть проблема с одновременным запуском PHP-FPM разных версий в BrainyCP и Hestia из коробки. Для экономии ресурсов лишние нужно выпилить, желательно навсегда. В VestaCP нужные версии ставятся вручную, потому "лишние" там не появятся. Что там в ISP / CPanel я не скажу, не работаю с ними уже достаточно давно как пользователь и никогда не держал их на своих серверах.

Как писать и на чем запускать - это два разных момента. Не стоит их путать. Ты можешь код, написанный под 5.6 в общем случае запустить на 7.х и он будет работать правильно, но быстрее. Либо CMS, которая правильно писалась под 7.0 (разработчик не использовал никакие навороты типа скобочек вместо array() и она будет работать на 5.6) запускается под 5.6 чтобы не держать отдельный FPM.

Зависит от того, какие модули включены. Если сайты работают на MySQLi, то PDO и Sqlite можно просто вырубить.

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

Нет, не использую IDE. И причем тут школота? Вам лишь бы IDE было, а в старые добрые времена у тебя только FTP и блокнот были. Для того чтобы вывести из строя солдата армии США достаточно вытащить из его рюкзака рулон туалетной бумаги, а чтобы превратить современного про кодера в прокладку между стулом и клавиатурой достаточно забрать у него IDE. Как же, в notepad++ и аналогичных редакторах с подсветкой синтаксиса и автодополнением программировать нельзя

Выкинуть исключения в функциях json_encode/json_decode то можно, но возвращаемое значение от этого корректным не станет. Ну поменяли незначительно алгоритм работы

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

О боже, да 5-ке багов тоже полно: https://www.php.net/ChangeLog-5.php - а сколько там неисправленного, потому что не поддерживают?


Квадратные скобочки уже навороты? Кстати, они появились в 5.4, так что квадратные скобочки будут работать в 5.4+: https://www.php.net/releases/5_4_0.php
Конечно я могу заморочиться и написать код, который будет работать в 9-ти версиях PHP, но я не буду этого делать в угоду удобства фич в новых версиях языка.


Читаемость кода становится гораздо лучше.


Вот тут уже с тобой не о чем говорить, ты не вышел из уровня джуна, который отлаживает информацию через echo. Что такое дебагер - для тебя вообще наверно открытием будет. Я не без греха и начинал с notepad++ и мне есть с чем сравнивать. Но разрабатывать серьезный продукт в нем - это конечно смех. Программировать в notepad++ можно, но это настолько эффективно, как ехать на велосипеде от Москвы до Питера, а преимущества IDE я даже описывать не буду, их столько, что целую книгу написать можно.


Школьники из notepad++ еще не вышли, используют mysql_, не знают что такое подготавливаемые запросы php, а отладка приложения для них - это echo и var_dump.

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

BaHeK, А что именно ты используешь из IDE для PHP?

PhpStorm

Какой смысл? Мне, как заказчику, пишут, например, на последней версии php. Все это стабильно работает. Зачем мне предыдущие версии? Я могу запустить свой проект одновременно на всех версиях php? Или может ради прикола раз в неделю менять рабочую версию, сегодня мой проект работает на 7.0, завтра 5.6? И сколько по времени у тебя займет написание моего проекта под версию 7.4 или под все сразу используя notepad++? Я не программист, или может я чего не понимаю?

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

sergggzi, Разговор не про единичный продукт написанный на заказ, а про массовый и коммерческий.

teetan, да даже про массовый... сейчас на всех хостингах предлагаются последние версии ОС, версии isp, версии php. в каком случае ты будешь брать centos 6 и ставить там php 5.*? только если ты юзаешь древний , как виндовс хп, продукт, который уже не поддерживается и не обновляется. Да и массовый коммерческий продукт давно написан, еще с ранних версий php. Сейчас, разрабатывая новый продукт с 0, какой смысл его пилить под php 5.6? Мне интересна логика.

Metal Messiah,


Там старая версия PHP поддерживается не потому, что это проекты "гиганты" и пишутся профессиональными разработчиками. А потому что там полно легаси кода и в них поддержка новых версий добавлялась, а не сохранялась поддержка старых версий при разработке под новую. Это важное замечание.
Вордпресс так вообще пишут ***быдлокодеры. Я, в принципе, не удивлён, что для тебя wp, joomla и drupal - "солидные продукты". Они же поддерживают старые версии. А так, да, чтобы писать такие сайты, наверное, достаточно первой версии notepad++. Не удивлюсь, что они верстались в каком-нибудь FrontPage Explorer.

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

sergggzi, Ну допустим было у меня дело когда cms статистики игроков и форума могли работать на версии пыха 5.6 но не могли корректно работать с 7 версией а сам cms сайта не мог корректно работать с 5 версией. Но это были времена когда переходили с 5 на 7. Сейчас допустим у тебя всё работает на 7 версии, но допустим какую-то часть портала надо обновить или установить новую cms а она не поддерживает 7 версию потому что какой-то недочеловек написал её по 8 версию, вот тут-то и вылезет косяк.

пральна! А ещё AMXX 1.8.2 лучше, чем эти сырые, недоделанные AMXX 1.11

Eka,
Спасибо тебе, поднял настроение. Мы тут с ребятами поорали с его проектов. Гит будет уже перебором. Умрем со смеха

Metal Messiah, наткнулся на один из твоих вопросов, не знаю решил ты проблему или нет, но вот тебе решение, на которое потребовалось потратить 2 минуты - нужно правильно называть переменные

Я в вашей каше мало что понимаю, но смысла спора не вижу.

Компании сейчас редко поддерживают старые продукты из-за коммерческой нецелесообразности(особенно новые проекты), прекращают клепать софт под архитектуру x86(какие то инструкции убирают - не шарю). Но так же знаю, что некоторые продукты стараются наоборот поддерживать, вопрос чисто в задачи и ее целесообразности. Но говорить что новье *** при этом даже не пытаться поюзать - не считаю это верным решением, с такой позиции вы быстро вылетите из рынка разработчиков при вашем нежелании продолжать саморазвиваться. Хотя если вам нравится текущие место работы то пожалуйста сидите, но не думаю, что будучи мидлом там - вас возьмут даже джуном в другую компанию

И сколько из них не закрыты за столько лет? И есть ли там настолько критические чтобы были общеизвестными и реально мешали работе сайтов? Нет.

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

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

Да, от табуляций и фигурных скобок, но не от нескольких вложенных в одну строку условий с ? или того хуже ??.

Только если есть попытка изучить что как работает, как лучше или как быстрее, написать определенную функцию (часто громоздкую) отдельно, а когда все будет отлажено - влепить ее в общий код проекта. А так для этого есть логи. И вообще, я больше привык к print_r, чем к var_dump. Я прекрасно знаю что такое отладчик, так как иногда пишу и под винду. Для PHP он, ИМХО, не нужен, ты там что бряки будешь ставить или значения регистров / переменных смотреть? В разное время использовал Delphi for PHP и что-то еще из этой оперы, но в конце концов выпилил все лишнее и вернулся на NPP, потому что так удобнее. А ты - типичный американский солдат, без рулона IDE не выживешь :)

У тебя приватная разработка, которая будет крутиться только на одном сервере, и на этом сервере ничего другого не будет. Действительно, никакого смысла. А потом захочешь лет через 5 перенести это все на другой сервер, а там не запустится или какая-то функциональность отвалится по известным только разработчикам причинам (прямо как в easy-mon при попытке переноса на более новые версии Linux).

Мониторинг серверов с тривиальным функционалом по типу SVV с интеграцией нескольких платежных систем - за неделю осилю если ни на что не отвлекаться. Плюс отладка пару дней, а то мало ли, особенно по оплате в реальных условиях. И NPP здесь ни при чём, просто кто-то считают что в нем работают только школьники.

Вот сразу видно что человек мысль понял сразу. Описываешь абсолютно реальную проблему большинства проектов, где, например, портал и форум - это разные движки, интеграции никогда не было, версии разные, одно захотел обновить а второе обновить невозможно / затратно и получается конфликт системных требований. Разносить на разные сервера - не вариант по расходам. Держать 2 разных PHP на одном сервере, один как модуль Apache, второй как FPM, или еще каким-то образом их разделять.

Для того чтобы развернуть древний продукт, не нужно ставить старую ОС. Можно на последний Debian / Centos установить тот же PHP 5.6 + ionCube, например, для того же AMX Monitoring, который больше ни под чем не пойдет "благодаря" ionCube. Рядом будет стоять другой FPM с последней версией еще под какой-то сайт, если он с высокой нагрузкой или не работает на 5.6.

Фишка то в том, что (пардон, это писалось прямым текстом, но не в этой теме а в соседней, и касалось WinAPI и .NET, а не PHP) правильно написанный код будет работать автоматически и под 7.4 и под 5.6, на это не нужны никакие дополнительные затраты (хотя протестировать не помешает). Разрабатывайте под 7.4.

Соглашусь, это особенность всех проектов, которые не первый год на рынке. Придумали вот в PHP 8 сравнение строк с числами переделать - окей, проверим а как оно себя ведет в нашем старом коде, как задумано или наоборот. Если как задумано - пишем что 8.0 поддерживается, если нет - правим чтобы работало, не нарушая совместимость, и опять пишем что 8.0 поддерживается. Не переписывать же весь код с нуля только потому что массивы скобочками теперь можно объявлять?

Сколько людей, столько и мнений. Я все то же могу сказать про Joomla, так как имел много проблем с сайтами, основанными на ней. Абсолютно неудобная админка, чрезмерная нагрузка на систему, и дырок как в дуршлаге. У Wordpress, на мой взгляд, один явный минус: засорение базы данных версиями постов, которые большинству сайтов даром не нужны. У меня абсолютно никаких претензий к разработчикам DLE, не было с тех пор как я наклепал не один десяток варезников под заказ разным людям в эпоху расцвета сайтов данной тематики и нет сейчас. Бывает проблематично обновить движок, который был сильно модифицирован под определенную задачу, потому тут либо плати за апдейт кодеру, либо оставайся на той версии, которая покупалась (что тоже не самое худшее решение, дырок в нем нет). В разные годы были разные движки для сайтов, но многие из них ушли в историю, а некоторые, почему-то, до сих пор являются основой чуть менее чем всех не-самописных сайтов. Почему так? Видимо, потому что они удовлетворяют требования потребителей (покупателей, пользователей, разработчиков которые на них готовые сайты клепают).

Eka, ты нашел заброшенные раритеты, один из которых вообще на бесплатном хостинге припаркован. Да, бложек надо восстановить, спасибо за напоминание.

О, уважаемые люди в треде. Хотя и оффтоп, но отвечу. Нет, лучше 1.9.0 :) А вообще да, один сервер я с 1.8.2 на него так и не перевел по одной простой причине. После рекомпиляции всех AMXX плагинов сервер падает с сегментацией. Все обновленное, а AMXX старый стоит. Будет время - займусь, а пока - главный принцип разработчика: не трогай, пока работает.

Благодарю, решил в тот же день, зайдя с другого ракурса. Но картинку сохраню на будущее.

В общем, тест из 1 поста я таки повторю на чистых php-cli без лишнего на сервере + добавлю функции из GD, mbstring и еще нескольких модулей в цикл. Уверен, что результат будет все тот же: существенный прирост производительности 7.4 над 5.6 и последующее падение 8.0 по сравнению с 7.4, но нужны точные и воспроизводимые цифры.

Metal Messiah,

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

Metal Messiah,
https://gist.github.com/yidas/5da6a02444775...a81298be6ef630c