Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:
- Как оптимизировать сайт и ускорить его работу?
- С какой скоростью будет и может работать сайт, в соответствии с теми технологиями на которых он будет запущен?
- Какие технологии следует использовать настраивая сервер или VPS?
Типичная проблема:
В какой-то момент сайт начинает открываться и работать слишком медленно. Бывает, что хостинговая компания блокирует сайт за превышение нагрузки или перерасход ресурсов. Что же делать в такой ситуации?
Может быть, сайт стал пользоваться слишком высокой посещаемостью или был установлен какой-то ресурсоёмкий модуль, совершается атака или сайт заражен вирусом. Так или иначе, но у всех этих случаев есть кое-что общее и это проблема всех сайтов на всех хостингах.
И если говорить о серверах для PHP, то такой проблемой является способ исполнения php кода, ровно как и другие значимые настройки окружения на сервере.
Не зависимо от того, есть ли проблема в вашем коде или её нет, высокая у вас посещаемость или нет, от настроек сервера зависит очень многое. Что бы все сказанное не звучало пустыми словами и была написана эта статья.
В этом обзоре я протестирую только что установленный сайт на одном из самых распространённых движков управления контентом Drupal 7.33.
Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2, модули mod_php и php-fpm, версии php php53 и php56, посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.
Конечно, эти параметры лишь часть настроек от которых зависит скорость сайта. Но мы умышлено
ограничиваемся этим, что бы не делать обзор бесконечным.
Продолжение этой статьи: Сравнение скорости исполнения кода Drupal для PHP 5.3-5.6 и 7.0. «Битва оптимизаторов кода» apc vs xcache vs opcache
Так же вы можете прочитать другие мои публикации на тему «Идеального» кластера
- «Идеальный» кластер. Часть 3.1 Внедрение MySQL Multi-Master кластера
- «Идеальный» кластер. Часть 2.2: Высокодоступный и масштабируемый web-сервер, лучшие технологии на страже вашего бизнеса
- О виртуальном кластере на hetzner
- Frontend: NGINX + Keepalived (vrrp) на CentOS
- HAPRoxy для Percona или Galera на CentOS. Его настройка и мониторинг в Zabbix
- Zabbix 2.2 верхом на nginx + php-fpm и mariadb
Дано:
- Операционная система Centos 6.7
- Сервер баз данных: MariaDB 10.21
- Все сессии сайтов хранятся в memcache, чтобы убрать влияние скорости установки сессии на скорость работы сайта.
- На всех тестах в качестве frontend выступает web-server nginx 1.93. В случае с Apache2, Nginx выступает в качестве балансировщика, а также для отдачи статики. В конфигурациях без использования Apache2 — непосредственным web-сервером является Nginx
- Конфигурация Nginx и MariaDB содержат множество оптимизаций, направленных на достижение максимальной производительности, но для всех участников теста эти настройки одинаковые и поэтому их влиянием следует пренебречь
- Параметры opcache и apc взяты из рекомендаций Bitrix, так как они оптимальны и универсальны для большинства сайтов
Как будем тестировать?
В локальной сети есть сервер zabbix и его задачи каждую минуту:
- Открывать главную страницу испытуемого сайта, дожидаться определенного содержимого на странице, убеждаться, что ответ от сервера — код 200.
- Следующим шагом идет авторизация в админку сайта, это происходит отправкой соответсвующего POST запроса. Сверка текста и кода ответа на странице с заложенным эталоном. Этот шаг касается почти всех подсистем web-сервера, и во многом его скорость зависит от скорости взаимодействия с базой данных
- Последним шагом является выход из админки сайта, сверка кода ответа и текста на странице выхода
- По итогам каждого шага, zabbix будет скрупулезно замерять и записывать скорость рендеринга php-кода в html понятный браузеру и демонстрировать нам графики полученных результатов
- Для каждого испытуемого будут записываться значения в течение одного часа и в качестве результата будет выступать средние значения за этот час
- Тестирование будет происходить внутри локальной сети, так что влияние на результат скорости интернет-соединения исключено
- Для удобства восприятия, все результаты показываю в порядке возрастания. Т.е. самый первый результат — это самый медленный. Все конфигурации были вынесены под условный номер, это позволит лучше ориентироваться в результатах
- Верхние графики — скорость генерации кода, чем выше значение, тем лучше. Нижние графики — время ответа сервера и чем ниже значение, тем лучше
- Тестируемые сайты живут своей жизнью, в них происходят регулярные операции с базами данных и выполняются задания по расписанию, именно поэтому кривая на графиках может иметь взлеты и падения
Тестирование:
1. Nginx + php-fpm56 без оптимизатора opcache
По архитектуре — это один из самых передовых вариантов. По производительности — наибольшее разочарование.
Производительность оставляет желать лучшего, но нагрузку такой вариант будет выдерживать гораздо лучше чем вариант №2 с Apache2. Так же, такой вариант будет расходовать оперативную память существенно эффективнее.
2. Apache2 + mod_php53 без оптимизатора apc
Cамый типичный для хостингов вариант. 90% популярных хостинг-провайдеров используют этот вариант. Хоть php53 давно не поддерживается разработчиками, но в интернете очень много сайтов, до сих пор работающих на этой версии.
Такой вариант не только очень медленный, но и быстро падает под небольшой нагрузкой из-за нехватки рабочих процессов Apache2, либо из-за нехватки оперативной памяти на сервере.
3. Балансировка и статика через Nginx, динамическая часть Apache2 + mod_php56 без оптимизатора opcache
Этот вариант создан как решение для современных сайтов. Его предлагают хостинги, которые стремятся предоставлять свежую версию PHP. Согласно бытующему мнению, эта версия PHP должна быть более быстрой и безопасной, чем предыдущие.
К сожалению, далеко не все сайты могут работать полноценно c этой версией. Почти каждая новая версия PHP перестает поддерживать некоторые устаревшие и «небезопасные» функции, нарушая работу «старого» кода.
Сам по себе php56 без оптимизатора довольно медленный, а mod_php склонен падать и занимать всю память на сервере под нагрузкой.
4. Nginx + php-fpm53 без оптимизатора apc
Достаточно передовая конфигурация, для тех кто не желает иметь проблемы из-за ошибок с оптимизатором кода. При этом используется «совместимая» версия интерпретатора PHP, а также из связки убирается ресурсоемкий Apache2.
5. Балансировка и статика через Nginx, динамическая часть Apache2 + mod_php53 + apc
Еще одна распространенная вариация. Очень многие хостинги применяют именно её, при этом либо используют по умолчанию, либо дают возможность включать оптимизатор в своих панелях управления.
Обычно Apache2 оставляют для работы .htaccess-правил, таких как преобразование ссылок и ЧПУ.
Получаем прирост скорости в 3,5 раза, по сравнению с вариантом без использования оптимизатора.
Сам по себе Apache (при использовании его собственного модуля mod_php) расходует для свой работы гораздо больше ресурсов, чем вариант с php-fpm. Apache2 склонен падать, если в одном из его модулей случается сбой или заполнять собой всю оперативную память сервера.
6. Nginx + php-fpm53 + apc
Отличный вариант для сайтов на старых движках, не требующих сложных .htaccess
Именно такой вариант я использую, когда необходимо поднять устаревший сайт, добиться от него удовлетворительной скорости и надежной работы при высоких нагрузках.
7. Балансировка и статика через Nginx, динамическая часть Apache2 + php-fpm53 + apc
Вариант для устаревших сайтов со сложными .htaccess. Например — старые инсталляции Bitrix.
Это идеальный вариант для устаревших сайтов. Данная конфигурация устойчива к высоким нагрузкам, совместима и достаточно производительна.
Отлично подходит, когда нужны правила .htaccess и дополнительные модули Apache2.
Из недостатков — устаревшая и не обновляемая версия php, но если нет выбора — это самый лучший вариант. Отлично подходит для старой версий Bitrix, Joomla и других распространенных CMS не самых свежих версий.
8. Балансировка и статика через Nginx, динамическая часть Apache2 + mod_php56 + opcache
Достаточно производительная, но ресурсоёмкая конфигурация со всеми недостатками mod_php.
Достаточно быстро, но под нагрузкой у сервера может закончится память, а скорость существенно упадет.
9. Nginx + php-fpm56 + opcache
Самый производительный вариант.
Это самый лучший вариант для всех современных сайтов. Хорошо держит нагрузку, показывает самый лучший результат с точки зрения производительности. Именно такой вариант я использую, когда стоит задача оптимизировать производительность сайта и увеличить скорость его работы.
Единственный недостаток — это то, что мы не сможем использовать .htaccess и все правила mod_rewrite нужно переписать на синтаксис Nginx.
Также не будут работать модули Apache2. Если таковые используются, то этот вариант не подойдёт.
10. Балансировка и статика через Nginx, динамическая часть Apache2 + php-fpm56+ opcache
Самый лучший вариант для сайтов, где нужен .htaccess. Идеально подходит для свежих версий Bitrix.
Хорошо держит нагрузку за счет php-fpm. Активно использую этот вариант для большинства сайтов.
| Главная страница тестового сайта | |||
| Номер конфигурации | Архитектура | Средняя скорость загрузки кб. | Средний отклик мс. |
| 1 | Nginx + php-fpm56 без оптимизатора opcache | 77,04 | 103,6 |
| 2 | Apache2 + mod_php53 без оптимизатора apc | 78,79 | 103,98 |
| 3 | Apache2 + mod_php56 без оптимизатора opcache | 78,85 | 102,38 |
| 4 | Nginx + php-fpm53 без оптимизатора apc | 81,55 | 97,88 |
| 5 | Apache2 + mod_php53 + apc | 303,37 | 29,36 |
| 6. | Nginx + php-fpm53 + apc | 312,33 | 24,73 |
| 7. | Apache2 + php-fpm53 + apc | 339,63 | 23,32 |
| 8. | Apache2 + mod_php56 + opcache | 484,96 | 16,91 |
| 9. | Nginx + php-fpm56 + opcache | 546,34 | 14,08 |
| 10. | Apache2 + php-fpm56+ opcache | 571,14 | 13,78 |
| Авторизация в админке тестового сайта | |||
| Номер конфигурации | Архитектура | Средняя скорость загрузки кб. | Средний отклик мс. |
| 1 | Nginx + php-fpm56 без оптимизатора opcache | 67,51 | 239,01 |
| 2 | Apache2 + mod_php53 без оптимизатора apc | 64,61 | 257,51 |
| 3 | Apache2 + mod_php56 без оптимизатора opcache | 66,75 | 242,42 |
| 4 | Nginx + php-fpm53 без оптимизатора apc | 68.79 | 233.15 |
| 5 | Apache2 + mod_php53 + apc | 173,81 | 94,26 |
| 6. | Nginx + php-fpm53 + apc | 173,3 | 91,3 |
| 7. | Apache2 + php-fpm53 + apc | 182,1 | 90,5 |
| 8. | Apache2 + mod_php56 + opcache | 218,35 | 77,55 |
| 9. | Nginx + php-fpm56 + opcache | 252,83 | 62,25 |
| 10. | Apache2 + php-fpm56+ opcache | 262,8 | 60,85 |
| Выход из админки тестового сайта | |||
| Номер конфигурации | Архитектура | Средняя скорость загрузки кб. | Средний отклик мс. |
| 1 | Nginx + php-fpm56 без оптимизатора opcache | 41,01 | 184,49 |
| 2 | Apache2 + mod_php53 без оптимизатора apc | 42,42 | 188,97 |
| 3 | Apache2 + mod_php56 без оптимизатора opcache | 42,06 | 188,37 |
| 4 | Nginx + php-fpm53 без оптимизатора apc | 45,48 | 169,15 |
| 5 | Apache2 + mod_php53 + apc | 190,1 | 41,87 |
| 6. | Nginx + php-fpm53 + apc | 185,92 | 41,24 |
| 7. | Apache2 + php-fpm53 + apc | 202,78 | 39,21 |
| 8. | Apache2 + mod_php56 + opcache | 315,56 | 26,23 |
| 9. | Nginx + php-fpm56 + opcache | 373,19 | 20,43 |
| 10. | Apache2 + php-fpm56+ opcache | 381,21 | 20,57 |
В качестве итогов:
- В реальной жизни, все варианты с Apache2 могут быть медленней, так как в своих тестах я умышленно передал отдачу статики Nginx. Это сделано, чтобы исключить влияние скорости отдачи статики на результаты замера скорости работы интерпретатора PHP. Одной из наиболее слабой стороной Apache2 и при этом сильной Nginx — является скорость отдачи статики. Особенно, это заметно на высоких нагрузках. Кроме того, Nginx менее подвержен атаке «медленных соединений»
- mod_php очень быстро занимает всю доступную память сервера и теряет производительность на нагрузках
- php-fpm расходует память значительно эффективнее, безопаснее и гибче в настройках. В ряде случаев он быстрее и без высоких нагрузок.
- Тест имеет узкую специфику, тут мы увидели особенности работы движка Drupal, другие могут вести себя иначе, но общая тенденция будет такой же.
И главное — от конфигурации вашего сервера или хостинга, зависит скорость вашего сайта. Подобрав верную архитектуру, вы можете получить пятикратное увеличение скорости работы сайта.
Если у вас возникнут вопросы, трудности или потребуется совет:
Мои контакты в профиле
Комментарии (59)
andrew_tch
11.08.2015 10:28+5Хабр? APC? 5.3? Настройки, которые не то что админы умеют делать, а программисты? Об этом надо было писать? )
la0
11.08.2015 10:34Может быть, сайт стал пользоваться слишком высокой посещаемостью или был установлен какой-то ресурсоёмкий модуль, совершается атака или сайт заражен вирусом. Так или иначе, но у всех этих случаев есть кое-что общее и это проблема всех сайтов на всех хостингах.
Как человек с бекграундом поддержки сервиса бесплатного хостинга заявляю вот что: в 80% случаев виноваты некоторые внутренности CMS(модули, плагины и т.д.), которые инициируют исходящие соединения.
К примеру:
— курсы валют
— обновление CMS
— SAPE и прочее
А теперь представьте, что по какой-то нелепой случайности иногда это происходит без кеширования, т.е. при каждой загрузке страницы.
Когда внешний ресурс отрабатывает быстро — проблемы нет. Когда не очень (таймаут >1-2 секунд) начинаются массовые проблемы. Посто потребления процессов PHP и т.д.
В самый пик роста популярности CMS даже был скрипт который раз в пару минут проверял доступность серверов обновлений и прочих, к которым пользовательские сайты часто обращились, и, если они лежали, делал блокировку через iptables (при востановлении работы блокировка снималась также автоматически).
Однако, это нискольно не уменьшает значимость статьи. Спасибо за подробное описание методики и результатов!
SyCraft
11.08.2015 10:38Блокировать так же стоит с умом) если будет ожидание по сетевому таймауту то ничем хорошим это не закончится.
Самый простой способ быстро справится с этой проблемой — прописать целевой домен, который лег в локальный hosts файл сервера, до тех пор пока сайт не продолжит свою работу.
Если с чем то возникают частые проблемы, то можно так же с локального сервера проксировать запрос по средству nginx. И если целевой proxy_pass не доступен, отдавать что то локальное.
Вариантов множество, но тут вопрос немного о другом.la0
11.08.2015 10:50+1имейте ввиду, что там не только HTTP и в те времена nginx был не очень популярен.
Да, действительно, задача как раз таки в том, чтобы был connection_refused (iptables:reject), a не timeout(drop).
Но мой комментарий к чему: смена технологии может не дать эффект, если никто не знает, что происходит внутри CMS.SyCraft
11.08.2015 10:52Согласен, частный случай, когда сайт пытается получить удаленный ресурс и упирается в скорость этого ресурса или в сетевой таймаут, выходит за рамки статьи.
В этом случай сперва придется поработать с ltrace или strace.la0
11.08.2015 11:03На моей памяти это самая массовая причина тормозов. И, к счастью, довольно просто диагностируемая.
В ситуации с открытым исходным кодом (и с закрытым, но частично) помогают логи резолвера (DNS) и grep -nr «domain.zone»
achekalin
11.08.2015 18:00Однажды наблюдал проект на хостинге nic.ru, где страница создавалась 30-60 сек (!) Подозревали все и всех, оказалось просто — диск сервера дико тормозил. Причем ТП механически отписывалась, мол, оптимизируйте код.
Тупая смена хостинга на самый обычный VPS (даже без SSD) дала генерацию страницы в 0.5 сек, дальнейшая мелкая настройка (APC, подстройка кешей БД) — еще раза в 3-4 ускорила генерацию.
Думал до того, что «уже все в жизни видел», но такого от мегакомпании nic.ru не ожидал. Тариф причем был самый дорогой из их хостинговых тарифов. Что любопытно, VPS-ка была взята людьми тоже в России (им нужна была бух. отчетность), обошлась если и дороже, то не намного, но — небо и земля.
В общем, рекомендации по оптимизации сайта на «php 5.3 + APC» (чес-слово, вы бы просто на 5.5 перевели бы сайт, если можете позволить — результат бы и без APC сильно порадовал, причем был бы «из коробки») нужно начинать, увы, с простой мысли — «до начала работ решите, быстр ли ваш хостинг».
yaak
11.08.2015 11:40+1Полезная статья! Скажите, а почему вы предпочитаете именно MariaDB? Сильно ли повлияет на производительность подобных решений использование Mysql?
E_STRICT
11.08.2015 14:20Почему бы PHP 7 не добавить в сравнение?
SyCraft
11.08.2015 14:22Его имеет смысл сравнивать с hhvm
Думаю о подобном сравнении, когда PHP7 будет стабилен.E_STRICT
11.08.2015 14:29+1Уже через недельку RC планируется.
wiki.php.net/todo/php70#timetableSyCraft
11.08.2015 14:31Нет смысла торопится. Достаточно одной серьезной уязвимости после релиза, что бы всерьез пожалеть о спешке. В продакшене это использовать, пока что, точно нет смысла.
qRoC
11.08.2015 16:12+1Его имеет смысл сравнивать с hhvm
Почему только с ним? Сравнивать с php5 вполне корректно.SyCraft
11.08.2015 16:23Поправьте меня, если я ошибаюсь. Но он менее совместим с существующими сайтами на php, чем любой из серии 5
Кроме того, он все еще не стабилен и от релиза к релизу результаты могут меняться.qRoC
11.08.2015 16:26Совместимость с прошлыми версиями — одно из основных правил php.
Насчёт стабильности — нам же не в продакшн пускать, а только для тестов.SyCraft
11.08.2015 16:28Хорошая мысль! думаю имеет смысл попробовать.
qRoC
11.08.2015 16:46+1Результаты работы старых скриптов должны быть намного лучше. Скрипты под php7, которые используют скалярные типы должны выдавать результаты на уровне php5 или немного медленней.
SyCraft
11.08.2015 16:52я видел ряд тестов, в которых сайты работает в 2 раза быстрее чем на php5
Интересно попробовать, видимо с RC что то буду делать.
haskel
11.08.2015 16:43> 1. Nginx + php-fpm56 без оптимизатора opcache
> По архитектуре — это один из самых передовых вариантов
В этом месте не очень понятно, что передового в сборке php без opcache?SyCraft
11.08.2015 16:51Очень редко кто заморачивается с отказом от Apache2 в пользу чистого Nginx, это накладывает ряд дополнительных задач по адаптации .htaccess
кроме того, наличие устаноленного php56 говорит о том, что скорее всего используются сторонние репозитории php. Что так же указывает на дополнительную работу со стороны оперейшенс. Те по сути то все сделано классно, но что бы было отлично, не хватает 1 детали.
Те между 1 и 9 вариантом разница лишь в оптимизаторе, который умышленно или случайно забыли включить.
m0Ray
11.08.2015 17:46Удивительно, что все сильно любят nginx и совершенно не упоминают lighttpd, а ведь он весьма прост в настройке и имеет неплохую производительность. У меня все сайты работают на связке lighttpd+php-fcgi и не жужжат. У lighttpd встроенный менеджер процессов FastCGI, кстати.
VSOP_juDGe
11.08.2015 22:15А bitrixvm какой вариант использует?
SyCraft
11.08.2015 23:30CentOS 6.6
NGINX + Apache2
MySQL5 with InnoDB support
Обновление ПО:
php — 5.4
mysql — 5.5
nginx — 1.6.2
DjOnline
11.08.2015 23:28-2Зачем эти громоздкие графики скорости скачивания для исполняемых файлов? Кого это волнует, если время генерации намного важнее?
Зачем вообще тестировать без apc/opcache? Таких дебилов вроде не осталось, вроде все знают что будет в 3-5 раз медленнее.
Где сравнение с mod_fastcgi/mod_fcgid? Ведь никто же в здравом уме не будет использовать mod_php, если на сервере более одного проекта/пользователя.
>>Сам по себе Apache (при использовании его собственного модуля mod_php) расходует для свой работы гораздо больше ресурсов, чем вариант с php-fpm.
Где графики, подверждающие это? Где сравнение разных воркеров апача?
Главная страница и авторизация в варианте 10 (Apache2 + php-fpm56+ opcache) получилась быстрее чем 9 (Nginx + php-fpm56 + opcache), что и требовалось доказать для голословных любителей кричать «Nginx ускорит ваш php в разы!». Нет, если у вас миллион медленных клиентов, то nginx будет лучше по потреблению памяти.
Выводы про apache/nginx в плане статики нельзя приводить без графиков и без сравнения разных воркеров в apache. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).SyCraft
11.08.2015 23:36Зачем эти громоздкие графики скорости скачивания для исполняемых файлов? Кого это волнует, если время генерации намного важнее?
Никто не скачивает исполняемые файлы. На графиках скорость генерации кода, об этом написано в тексте.
Зачем вообще тестировать без apc/opcache? Таких дебилов вроде не осталось, вроде все знают что будет в 3-5 раз медленнее.
99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache
Где сравнение с mod_fastcgi/mod_fcgid?
Если вы сделаете такую статью, то она будет.
Где графики, подверждающие это? Где сравнение разных воркеров апача?
В других тестах, которых тысячи в интернете
«Nginx ускорит ваш php в разы!».
Вы не правы. В этом тесте все равно в качестве фронтенда стоит Nginx. Об этом написано, если замерять скорость голого apache vs nginx то порядок цифр будет другим. Об этом тоже написано.
Выводы про apache/nginx в плане статики нельзя приводить без графиков и без сравнения разных воркеров в apache. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).
Порадуйте нас своим сравнением, думаю что это было бы интересно для многих.DjOnline
25.08.2015 22:19-2>>На графиках скорость генерации кода, об этом написано в тексте.
На графиках download speed в kbps. Зачем засорять статью этим ненужным мусором? Статику что ли отдаёшь через php?
>>99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache
Ну значит не надо использовать 99% хостингов, которые не используют APC. В заголовке же не сказано «выбираем говнохостинг», речь вроде как о своём сервере или VPS.
>>Если вы сделаете такую статью, то она будет.
Это ваша задача, приводить все сравнения в статье, и не делать голословных выводов. Тем более если упомянуты «говнохостинги» без APC, то там не будет идиотов, использующих mod_php, который не умеет разделать пользователей.
>>В других тестах, которых тысячи в интернете
Если в статье этого нет, то и не надо об этом писать.
>>Об этом тоже написано.
Что написано? Причём тут статика? Речь PHP, конкретно в твоей таблице apache2 быстрее nginx.
Вообщем внизу правильно написано, непонятен вообще смысл этой статьи с очевидными вещами, тестирования mod_php вместо mod_fastcgi и рассуждениях о говнохостингах без apc.
zoonman
12.08.2015 16:25PHP 5.3 уже почти год, как не поддерживается. Советую всем познакомиться с этой страницей php.net/supported-versions.php
SyCraft
12.08.2015 17:57Это известный факт. Но старых сайтов очень много. И не всякий имеет желание тратить на их адаптацию.
zoonman
12.08.2015 18:39До первого взлома с лежащим сайтом и потерянной репутацией.
SyCraft
12.08.2015 18:52Именно так, но люди не всегда делают все правильно.
Если провести анализ, с целью собрать статистику версий php, то окажется что большинство php53zoonman
12.08.2015 19:09-1Я знаю и с этим нужно что-то делать. Сейчас твою статью прочтет «школьник» и купит хостинг со старым софтом. Поэтому нельзя в таких статьях писать про устаревшее и заброшенное ПО.
Новые версии CMS не работают на старом PHP, но в них исправлены ошибки. На старом PHP работают старые версии и с дырами. Потом через них спамят и ддосят нормальные системы, воруют личные данные. А из этого складывается негативная репутация для технологии в целом. А еще начинают строить всякие SQL фильтры для серверов, которые якобы защищают, но из-за которых статью с примерами SQL-запросов не добавить в базу.
Даже если новая версия PHP работает медленнее, это лучше, т.к. в ней добавлены необходимые проверки, исправлены баги. В конце концов есть сообщество, которое обращает внимание на существующие проблемы.SyCraft
12.08.2015 19:35Не вижу связи между 90% хостингов с php53 в качестве интерпретатора и статьей.
Скорее люди будут стремится использовать современный софт и будут предметно понимать суть вопроса.
Надеюсь так же хостеры, будут обновлять свои сервера но это от меня никак не зависит.
igordata
12.08.2015 18:31+1Стоит определиться сразу, что если человек сидит на хостинге, где нет возможности включить или настроить что-то, то это его личная проблема, и рассматривать этот случай вообще не нужно.
Во всех остальных случаях максимальная скорость работы php-сайта достигается через правильное количество потоков (по одному на ядро) nginx+gzip (со статик-модулем конечно же), и через правильное количество потоков php-fpm, естественно с акселератором.
Тут даже писать не о чем. Это очевидно и доступно любому человеку на любом уровне знакомства с сервером, кроме полного нуля — в этом случае стоит обратиться к специалисту.
Про кеширование в мемкеше. Сессии на файлах, которые дефолтны в php для сессий, и которые с лёгкой руки автора были исключены из рассмотрения, будут быстрее в случае, если в системе есть свободная память. Современные системы кешируют файловые операции в свободной оперативке. Поэтому комп нельзя просто выдернуть из розетки ещё со времён 95-й Винды. Это тоже должно быть очевидно любому специалисту, или тому, кто хотел бы им стать. Операции с этим кешем очень быстрые, они происходят, если не ошибаюсь, чуть ли не на уровне ядра. Они молниеносные. Правда только до тех пор, пока есть свободная память.
Далее.
Тестирование скорости и отзывчивости сайта производится один раз в минуту(!) 60 раз в час (всего!) Заббиксом! И на основании этих данных строятся какие-то выводы. Как будто никто и никогда до автора не содавал никаких инструментов и иметодик тестирования.
Автор говорит о том, что Заббикс-де загружает только страницу. Но при этом в тестировании участвует конфигурация, в которой статика отдаётся через nginx. Какое отношение статика имеет к тестированию php? Если никакого, то зачем об этом вообще писать?
Также не учтено время путешествия сетевого пакета до сервера. Какое оно? Когда мы видим цифры 200мс, а потом 100мс, то как можно судить на сколько сократилось время генерации страницы средствами php? Если пинг был 90мс, то по факту мы имеем не двухкратный, а двадцатикратный(!) прирост производительности.
По факту статья — гадание на кофейной гуще.
Тесты с Apache, тесты с nginx, тесты с акселераторами — всё покрыто туманом. Какой конфиг? Какая машина? Сколько ядер? Что ещё работало в момент тестирования? При 60 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.
Это не для Хабра статья, а для школьного журнала. Такое моё мнение.SyCraft
12.08.2015 18:50-1Стоит определиться сразу, что если человек сидит на хостинге, где нет возможности включить или настроить что-то, то это его личная проблема, и рассматривать этот случай вообще не нужно
Очевидно что такой хостинг нужно поменять на что то более производительное за аналогичные деньги.
Во всех остальных случаях максимальная скорость работы php-сайта достигается через правильное количество потоков (по одному на ядро) nginx+gzip (со статик-модулем конечно же), и через правильное количество потоков php-fpm, естественно с акселератором.
При чем тут gzip? о каком количестве потоков php-fpm идет речь? вы знакомы с тем как работает php-fpm?
Тут даже писать не о чем. Это очевидно и доступно любому человеку на любом уровне знакомства с сервером, кроме полного нуля — в этом случае стоит обратиться к специалисту.
На каком основании вы сделали этот вывод? И да если человек обращается, то как правило к программисту а не к оперейшенс. А именно на уровне оперейшенс происходит настройка производительного окружения. И цель статьи доказать, что оптимизацию сайта нужно начинать с оптимизации окружения, для доказательства этого были приведены цифры.
Про кеширование в мемкеше. Сессии на файлах, которые дефолтны в php для сессий, и которые с лёгкой руки автора были исключены из рассмотрения, будут быстрее в случае, если в системе есть свободная память. Современные системы кешируют файловые операции в свободной оперативке. Поэтому комп нельзя просто выдернуть из розетки ещё со времён 95-й Винды. Это тоже должно быть очевидно любому специалисту, или тому, кто хотел бы им стать. Операции с этим кешем очень быстрые, они происходят, если не ошибаюсь, чуть ли не на уровне ядра. Они молниеносные. Правда только до тех пор, пока есть свободная память.
Вы знаете как работает memcache? он выделяется установленным блоком, он не динамический и сессии занимают довольно мало места. Любые сессии на диске, даже если это SSD, зависят от неравномерной скорости создания файлов сессий, кешируются только часто используемые файлы, как кеширование поможет скорости установки сессии из ваших слов не очевидно. Что значит молниеностные? те скорость создание файла на диске = скорости записи в мемкеш? что с фактором повторяемости результата?
Тестирование скорости и отзывчивости сайта производится один раз в минуту(!) 60 раз в час (всего!) Заббиксом! И на основании этих данных строятся какие-то выводы. Как будто никто и никогда до автора не содавал никаких инструментов и иметодик тестирования.
Как раз по сравнению с синтетическими тестами, я замеряю реальную скорость работы сайта на протяжении продолжительного количества времени. Те у результатов хорошая повторяемость и воспроизводимость.
Автор говорит о том, что Заббикс-де загружает только страницу. Но при этом в тестировании участвует конфигурация, в которой статика отдаётся через nginx. Какое отношение статика имеет к тестированию php? Если никакого, то зачем об этом вообще писать?
Страница html содержит ссылки на объекты css, js и различную графику, которую заббикс так же пытается загрузить. Что бы исключить потенциальное отставание в скорости apache2 по сравнению с nginx, и ставится nginx для статики на всех конфигурациях. Как раз, что бы сделать фокус на php.
Также не учтено время путешествия сетевого пакета до сервера. Какое оно? Когда мы видим цифры 200мс, а потом 100мс, то как можно судить на сколько сократилось время генерации страницы средствами php? Если пинг был 90мс, то по факту мы имеем не двухкратный, а двадцатикратный(!) прирост производительности.
Тестирование происходит локально, через zabbix-proxy на том же сервере. Те localhost
По факту статья — гадание на кофейной гуще.
Тесты с Apache, тесты с nginx, тесты с акселераторами — всё покрыто туманом. Какой конфиг? Какая машина? Сколько ядер? Что ещё работало в момент тестирования? При 60 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.
Это не для Хабра статья, а для школьного журнала. Такое моё мнение.
Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания. Конфигурацию я приводил выше в одном из комментариев, но и конфигурация общая для всех испытуемых.igordata
12.08.2015 21:54+2> При чем тут gzip?
Это влияет на время отдачи контента, которое вы меряли в сумме со временем генерации контента. Зачем вы так делали — это вам видней.
> о каком количестве потоков php-fpm идет речь?
Процессов, а не потоков, простите. Теперь хорошо?
> вы знакомы с тем как работает php-fpm?
Да. Если процессов будет слишком мало, то сервер будет отдавать меньше страниц в секунду, чем мог бы. Вы этот вопрос вообще не затрагивали, почему-то. А стоило бы. Если слишком много — будет проседать производительность опять же на большом числе запросов.
> На каком основании вы сделали этот вывод?
На основании много чего, включая практику и такие же статьи и тестирования, только нормальные. По факту в XXI Апач вообще не нужен.
> Вы знаете как работает memcache? он выделяется установленным блоком
Это очень круто, но ядро ОС круче полюбас. Это я даже не касаюсь вопроса, как именно вы лазили в мемкеш, ибо если через TCP, то это феил, и эти операции никак не могут быть быстрее файлового кеша ОС. Ну никак. Ну прости. Так устроены современные ОС. На это было пложено куча сил, и результат прекрасен.
> как кеширование поможет скорости установки сессии из ваших слов не очевидно
А из ваших очевидно? Вы упоминули логин. При логине *обычно* нужна сессия. Создание сессии или её чтение из какого-либо источника однозначно влияют на скорость генерации контента, т.к. явлюятся блокирующей операцией при выполнении кода, который и генерирует контент. Ускоряя этот этап, мы напрямую ускоряем и отдачу страницы. Если вам это неочевидно — опять же стот подтянуть базис. Сейчас он у вас проседает по всем фронтам.
> Что значит молниеностные?
Прям такие: вжиууу! И готово. Ещё раз. С некоторых пор ОС рапортует о завершении фаловых операций ещё до их начала. А данные помещает в кеш в свободной оперативной памяти. Это касается всех современных систем. И да, частые файлы это и есть файлы сайта, по той простой причине, что сервер зачастую не перезапускается годами, а обращения к файлам происходят именно с файлами вашего сайта и с сессиями. =) Которые в свою очередь отлично помещаются в кеш, т.к. маленькие. Иногда даже просто малюсенькие.
> Как раз по сравнению с синтетическими тестами
Наверное Заббикс пользуется огнелисом и замеряет время ручным секундомером. На фотке случайно не его рука?
> что с фактором повторяемости результата?
> Те у результатов хорошая повторяемость и воспроизводимость.
Наверное, прекрасная. Повторяемость результата, который ничего не значит. =) Поздравляю. Один раз в минуту понятет любой хостинг с любыми настройками. Если у вас такая бешенная плотность запросов — стоит остановиться на шаред хостинге и успокоиться. Учитывая, что ещё происходили некие неосвещённые статьёй запросы в БД, то время, которое вы намеряли — оно никак не связано с темой статьи.
> Страница html содержит ссылки на объекты css, js и различную графику, которую заббикс так же пытается загрузить.
Зачем? Как это связано со временем генерации страницы силами php? Как он это делает? В сколько потоков? Как у вас размещён этот контент? На одном домене или в CDN? Удаётся ли ему загрузить всё-всё до последней капельки без проблем, или он где-то может залипать на таймаутах? Зачем вообще вы это меряли, если это никак, ну никак не связано со временем генерации HTML-кода?
>Что бы исключить
Что бы выпить, чтобы напиться. Это просто удобный способ запомнить, когда слитно, а когда нет.
> Тестирование происходит локально, через zabbix-proxy на том же сервере. Те localhost
Жесть какая. Т.е. по факту, у вас само тестирование может влиять на тестируемое время генерации контента. Так делать нельзя.
> Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания.
Не может. Нельзя так делать. Вы должны показывать людям всё, что имеет отношение к исследованию. Вы можете о чем-то не знать, ошибаться, или ещё чего. Кто-то может неожиданно сообщить вам что-то новое и важное. Все такие действия нарушают чистоту эксперимента, и напускают ненужного туману. И вообще как так у Апача и нгинкса могут быть одинаковые конфиги. Этого не может быть, потому что этого не может быть никогда. =)
> но и конфигурация общая для всех испытуемых.
Это видимо крайне секретная конфигурация. Более того, стоит оговаривать, на виртуалке ли вдруг и какой вы это делаете, т.к. процессы хоста могут влиять на гостя.
Про количество замеров. Шесть десятков — это мало. Тыщёнка-другая — ещё куда ни шло. Лучше, если будет по 60 тысяч на каждый тест. С указанием числа конкурентных запросов.
Вообщем, похоже, что ты намерял хрень. Без обид. Лучше не обижаться, а написать статью с нормальными замерами нормальными средствами типа ab или siege. Я люблю siege. Удачи.SyCraft
12.08.2015 22:08-1Прошу прощения, пробежался по вашему ответу глазами, мне кажется у вас горячая кровь но маловато знаний и опыта. Это поправимо, все такими были и до сих пор есть. Ничего по существу я не нашел. Предлагаю, если у вас есть какие то дельные пожелания или вопросы, пишите мне в скайп. С радостью Вам все разъясню.
Тем ни менее, спасибо больше за критику и участие, это очень полезно, в будущем все разумные мысли которые я вынес из ваших слов, я обязательно реализую в новых статьях.
PS +1 вашему посту за проявленное старание.
SergeyD
19.08.2015 03:55Попробую немного прояснить претензии igordata
1. gzip
Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.
Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.
И это зависит от настроек серверов.
2. ping
Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.
Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).
3. Zabbix
Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.
4. Конфиги
Их лучше выложить, чтобы другие люди смогли проверить, потестировать сами. И после этого конструктивно спорить.
5. Тестирование
Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.
Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.
А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.SyCraft
19.08.2015 11:04Попробую немного прояснить претензии igordata
1. gzip
Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.
Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.
И это зависит от настроек серверов.
2. ping
Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.
Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).
мы тестируем на локальной машине
3. Zabbix
Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.
мы тестируем скорость генерации кода
4. Конфиги
Их лучше выложить, чтобы другие люди смогли проверить, потестировать сами. И после этого конструктивно спорить.
в продолжении я выложил их
5. Тестирование
Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.
Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.
А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.
мы замеряем быстроту а не производительностьSergeyD
19.08.2015 18:09Понятно.
Тогда меня ввел в заблуждение «громкий» заголовок статьи.
Ожидал большего. Или большого исследования.SyCraft
19.08.2015 20:33тестов производительности очень много в интернете, ничего нового я бы не написал
продолжение habrahabr.ru/post/264775
baltazorbest
Можно более подробнее о вашем «SSD-хостинг на серверах ovh.com» — какой тарифный план?
Так же хотелось бы увидеть настройки nginx и mariadb.
Хотелось бы еще сравнения opcache с xcache.
SyCraft
Постараюсь написать об этом в будущих статьях. По вопросам хостинга, можем обсудить в skype. Мы не конкурируем с хостинговыми компаниями. Хостинг под конкретные проекты, которые беремся ускорять.
baltazorbest
Тут вопрос был скорее не сколько платите, а на каком железе проводились тесты. Я просто не работал с ovh и уже давно не работаю с хостингами, вот и стало интересно.
SyCraft
Конкретное тестирование проводилось на www.ovh.ie/dedicated_servers/enterprise/2014-SP-64.xml