Комментарии 41
Исследование подтверждает мысль о том, что можно пользоваться любым поддерживаемым PHP. По скорости они примерно одинаковы.
Ну как бы да, вот только поддержка 5,4 заканчивается через месяц.
Это повод экстренно заняться адаптацией своих приложений на 5.5. :)
PHP 5.5 обрато совместим с PHP 5.4 (почти). Да и PHP 5.6 тоже не далеко ушёл.
Статья оформлена на голову лучше, чем предыдущая, хотя конечно я всё равно остаюсь при мнении, что Zabbix ни разу не писькомерка, а 60 запросов — мало, а единицы измерения не указаны ни на одном из графиков.
А что такое показатель «интерпретации страницы и времени отклика… Чем выше результат, тем лучше»? Это что за попугаи?
Также прошу автора пояснить причины особенности своей методики проведения замеров, которые заставляю его делать 60 замеров в час. Откуда эта странная идея? Чем она вызывана?
А что такое показатель «интерпретации страницы и времени отклика… Чем выше результат, тем лучше»? Это что за попугаи?
Также прошу автора пояснить причины особенности своей методики проведения замеров, которые заставляю его делать 60 замеров в час. Откуда эта странная идея? Чем она вызывана?
Свой сайт попробовали запустить на PHP7 вместо HHVM (в версии под последнюю багу искали).
результат — на чистом ПХП7 с кэшами сайт уделал версию на HHVM почти в 2 раза по всем параметрам…
Посещаемость сайта — в среднем 11к уникальных пользователей, около 60Гб исходящего траффика и 90к посещений страниц в сутки.
результат — на чистом ПХП7 с кэшами сайт уделал версию на HHVM почти в 2 раза по всем параметрам…
Посещаемость сайта — в среднем 11к уникальных пользователей, около 60Гб исходящего траффика и 90к посещений страниц в сутки.
уделал версию на HHVM почти в 2 раза по всем параметрам…
Как-то сомнительно
Но факт…
Переписки с тестами сайта, к сожалению, не осталось :(
Тестирование проводилось siege объемом 10к запросов (по примерно 300 случайных линков).
Переписки с тестами сайта, к сожалению, не осталось :(
Тестирование проводилось siege объемом 10к запросов (по примерно 300 случайных линков).
что-то как-то очень сомнительно, PHP7 кое-как догоняет по производительности HHVM только, если он его рвет в нагрузочных тестах, стало быть у нас был хреново настроенный HHVM против настроенного PHP-FPM. Я с HHVM не особо работал (только для cli юзаю иногда) и не вкурсе как там чего с настройками… в голову приходит только то что в fpm больше воркеров стало и утилизировать ресурсы системы стало лучше.
Примерно совпадает с этими бенчмарками.
www.zend.com/en/resources/php7_infographic
www.zend.com/en/resources/php7_infographic
Я правильно понимаю, что мерили ту самую CMS-ку, у которой главная страница изкоробки делает 80-сколько-то-там запросов в базу?
Она довольно активно работает с базой, но про 80 запросов из коробки не уверен.
Есть где почитать?
судя по трейсу кода, это не так. Кроме того, запросы к базе происходят через модуль mysql или mysqli
Они так же часть php и скорость их работы в фокусе этого теста.
Есть где почитать?
судя по трейсу кода, это не так. Кроме того, запросы к базе происходят через модуль mysql или mysqli
Они так же часть php и скорость их работы в фокусе этого теста.
drupal разве не через PDO работает? Там свои драйвера над mysqli?
а pdo это не модуль php?
PHP Data Objects (PDO) – расширение, определяющее облегченный, единый интерфейс для доступа к базам данных в PHP. Каждый драйвер базы данных, который реализует интерфейс PDO, может предоставить определенные для базы данных функции как обычные функции расширения. Обратите внимание, что Вы не можете выполнить функции базы данных, используя расширение PDO отдельно; Вы должны использовать определенный для базы данных драйвер PDO, чтобы обратиться к серверу базы данных.
ну кроме того что существует огромная разница между pdo и mysqli… Ибо если рассуждать без учета различий — все есть php модуль на определенном уровне реализации.
А не всё ли равно?
Неясно, зачем мерять производительность PHP на проекте, который заведомо при росте нагрузки упирается в базу, а не фронт.
Что ты изменить скорость php, а не проекта )
В любом случае если выполнение PHP занимает 50% времени и php7 почти в 2 раза быстрее, мы всеравно получаем приблизительно 30% прирост производительности, что как по мне не мало. Да и в рамках тестов взаимодействие с базой все же было, так что все учтено.
Прирост производительности 30% при конкретном тестовом размере базы.
Сколько он будет на реальном нагруженном проекте? Хорошо если 3% наберётся.
Сколько он будет на реальном нагруженном проекте? Хорошо если 3% наберётся.
При равном размере баз и прочих условиях, отичаются только интерпретаторы php
те на скорость в тесте влияют только испытуемые.
те на скорость в тесте влияют только испытуемые.
Хорошо если 3% наберётся.
Да, давайте кидаться цифрами из головы. Для среднестатистического проекта на друпале не будет такой нагрузки на базу что работа СУБД займет более 50% времени обработки запроса.
Если такой найдется, то явно никакая магия и смена php проекту не поможет.
Обычно на этих проектах есть разработчики, которые думаю догадаются оптимизировать базу (возможно памяти для индексов не хватает или кривой плагин не добавил эти самые индексы), добавить кэш и т.д. Не все люди тупые (надеюсь). А показать что PHP7 быстрее и сильно быстрее PHP5.6 — это полезная информация. Возможно статья и сомнительна но доводы вроде «на больших нагрузках все будет плохо если брать инструменты для этого не предназначенные as is» это глупо.
Уже задавал этот вопрос в комментариях да ошибся топиком, тот топик что то 2008 года… наверное здесь нужно было спросить:) Ребята подскажите пожалуйста есть ли понятие совместимости в работе одновременно нескольких кешеров? Что то ничего не нагуглил на эту тему. Служба поддержки хостинга долго пыталась настроить, но в итоге вырубила мне opcache и оставила только xcache, объяснив, что они совместно не работают. Это правда что можно использовать только один кешер на сервере иначе будут конфликты? Вообще у меня довольно тяжеловатые сайты на VPS и я хотел немного ускориться. Стоит apache+nginx php 5.6. Вот и интересуюсь может можно как то настроить совместную работу кешеров, Насчет opcache насколько я понял он кеширует только сами php скрипты а пользовательские данные не кеширует. Т.е. в конфиге движка указано какой кеш использовать file, memory, xcache. Если укажем file то понятно, что проблем не будет, а вот насчет memory и xcache непонятно что и как. Уважаемые гуру помогите пожалуйста разобраться в этом вопросе. Спасибо.
объяснив, что они совместно не работают
да, они не будут работать вместе. Да и нет смысла, opcache работает лучше, дает больший прирост производительности. Еще один кешер никакого прироста не даст так как будет делать ровно то же но хуже.
и я хотел немного ускориться
Тут как со скидками, если у вас есть накопительная скидка в 20% и сегодня по акции 30%, вы всеравно получите скиду 30%. Если вы хоть 10 опкешеров заставите работать вместе вы не получите тот же прирост производительности который дает один opcache.
а пользовательские данные не кеширует.
для этих целей (хранение данных в разделяемой памяти) придумали apcu. А для хранения данных в файлах лучше использовать doctrine/cache.
Спасибо большое за ответ. Получается либо один xcache либо opcache+apcu… Вот здесь прочитал, что можно в настройках xcache вырубить кеширование opcode. toster.ru/q/67398 Кстати Fesor Вы тоже там участвуете:)
В общем немного разобрался, работа двух акселераторов одновременно будет приводить к ошибкам. Поэтому оставил родной opcache и Memcache.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache