Senior System Administrator & LiveLinux.ru
0,0
рейтинг
11 августа 2015 в 08:48

Разработка → Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP



Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов 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




Так же вы можете прочитать другие мои публикации на тему «Идеального» кластера






Дано:


  • Операционная система 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, другие могут вести себя иначе, но общая тенденция будет такой же.





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




Если у вас возникнут вопросы, трудности или потребуется совет:
Мои контакты в профиле
Aleksey Zhadan @SyCraft
карма
33,0
рейтинг 0,0
Senior System Administrator & LiveLinux.ru
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (59)

  • 0
    Можно более подробнее о вашем «SSD-хостинг на серверах ovh.com» — какой тарифный план?
    Так же хотелось бы увидеть настройки nginx и mariadb.
    Хотелось бы еще сравнения opcache с xcache.
    • 0
      Постараюсь написать об этом в будущих статьях. По вопросам хостинга, можем обсудить в skype. Мы не конкурируем с хостинговыми компаниями. Хостинг под конкретные проекты, которые беремся ускорять.
      • 0
        Тут вопрос был скорее не сколько платите, а на каком железе проводились тесты. Я просто не работал с ovh и уже давно не работаю с хостингами, вот и стало интересно.
  • +5
    Хабр? APC? 5.3? Настройки, которые не то что админы умеют делать, а программисты? Об этом надо было писать? )
    • 0
      соглашусь, детский сад…
  • 0
    Может быть, сайт стал пользоваться слишком высокой посещаемостью или был установлен какой-то ресурсоёмкий модуль, совершается атака или сайт заражен вирусом. Так или иначе, но у всех этих случаев есть кое-что общее и это проблема всех сайтов на всех хостингах.


    Как человек с бекграундом поддержки сервиса бесплатного хостинга заявляю вот что: в 80% случаев виноваты некоторые внутренности CMS(модули, плагины и т.д.), которые инициируют исходящие соединения.
    К примеру:
    — курсы валют
    — обновление CMS
    — SAPE и прочее

    А теперь представьте, что по какой-то нелепой случайности иногда это происходит без кеширования, т.е. при каждой загрузке страницы.
    Когда внешний ресурс отрабатывает быстро — проблемы нет. Когда не очень (таймаут >1-2 секунд) начинаются массовые проблемы. Посто потребления процессов PHP и т.д.

    В самый пик роста популярности CMS даже был скрипт который раз в пару минут проверял доступность серверов обновлений и прочих, к которым пользовательские сайты часто обращились, и, если они лежали, делал блокировку через iptables (при востановлении работы блокировка снималась также автоматически).

    Однако, это нискольно не уменьшает значимость статьи. Спасибо за подробное описание методики и результатов!
    • 0
      Блокировать так же стоит с умом) если будет ожидание по сетевому таймауту то ничем хорошим это не закончится.
      Самый простой способ быстро справится с этой проблемой — прописать целевой домен, который лег в локальный hosts файл сервера, до тех пор пока сайт не продолжит свою работу.
      Если с чем то возникают частые проблемы, то можно так же с локального сервера проксировать запрос по средству nginx. И если целевой proxy_pass не доступен, отдавать что то локальное.
      Вариантов множество, но тут вопрос немного о другом.
      • +1
        имейте ввиду, что там не только HTTP и в те времена nginx был не очень популярен.
        Да, действительно, задача как раз таки в том, чтобы был connection_refused (iptables:reject), a не timeout(drop).

        Но мой комментарий к чему: смена технологии может не дать эффект, если никто не знает, что происходит внутри CMS.
        • 0
          Согласен, частный случай, когда сайт пытается получить удаленный ресурс и упирается в скорость этого ресурса или в сетевой таймаут, выходит за рамки статьи.
          В этом случай сперва придется поработать с ltrace или strace.
          • 0
            На моей памяти это самая массовая причина тормозов. И, к счастью, довольно просто диагностируемая.
            В ситуации с открытым исходным кодом (и с закрытым, но частично) помогают логи резолвера (DNS) и grep -nr «domain.zone»
            • 0
              Мне всегда помогает ltrace. Покажет всю правду о том, что происходит в коде.
    • 0
      Однажды наблюдал проект на хостинге nic.ru, где страница создавалась 30-60 сек (!) Подозревали все и всех, оказалось просто — диск сервера дико тормозил. Причем ТП механически отписывалась, мол, оптимизируйте код.

      Тупая смена хостинга на самый обычный VPS (даже без SSD) дала генерацию страницы в 0.5 сек, дальнейшая мелкая настройка (APC, подстройка кешей БД) — еще раза в 3-4 ускорила генерацию.

      Думал до того, что «уже все в жизни видел», но такого от мегакомпании nic.ru не ожидал. Тариф причем был самый дорогой из их хостинговых тарифов. Что любопытно, VPS-ка была взята людьми тоже в России (им нужна была бух. отчетность), обошлась если и дороже, то не намного, но — небо и земля.

      В общем, рекомендации по оптимизации сайта на «php 5.3 + APC» (чес-слово, вы бы просто на 5.5 перевели бы сайт, если можете позволить — результат бы и без APC сильно порадовал, причем был бы «из коробки») нужно начинать, увы, с простой мысли — «до начала работ решите, быстр ли ваш хостинг».
      • 0
        Да это одна из главных причин. Но эта причина как бы рядом.
  • +1
    Полезная статья! Скажите, а почему вы предпочитаете именно MariaDB? Сильно ли повлияет на производительность подобных решений использование Mysql?
  • 0
    Почему бы PHP 7 не добавить в сравнение?
    • 0
      Его имеет смысл сравнивать с hhvm
      Думаю о подобном сравнении, когда PHP7 будет стабилен.
      • +1
        Уже через недельку RC планируется.
        wiki.php.net/todo/php70#timetable
        • 0
          Нет смысла торопится. Достаточно одной серьезной уязвимости после релиза, что бы всерьез пожалеть о спешке. В продакшене это использовать, пока что, точно нет смысла.
      • +1
        Его имеет смысл сравнивать с hhvm

        Почему только с ним? Сравнивать с php5 вполне корректно.
        • 0
          Поправьте меня, если я ошибаюсь. Но он менее совместим с существующими сайтами на php, чем любой из серии 5
          Кроме того, он все еще не стабилен и от релиза к релизу результаты могут меняться.
          • 0
            Совместимость с прошлыми версиями — одно из основных правил php.
            Насчёт стабильности — нам же не в продакшн пускать, а только для тестов.
            • 0
              Хорошая мысль! думаю имеет смысл попробовать.
              • +1
                Результаты работы старых скриптов должны быть намного лучше. Скрипты под php7, которые используют скалярные типы должны выдавать результаты на уровне php5 или немного медленней.
                • 0
                  я видел ряд тестов, в которых сайты работает в 2 раза быстрее чем на php5
                  Интересно попробовать, видимо с RC что то буду делать.
  • 0
    > 1. Nginx + php-fpm56 без оптимизатора opcache
    > По архитектуре — это один из самых передовых вариантов

    В этом месте не очень понятно, что передового в сборке php без opcache?
    • 0
      Очень редко кто заморачивается с отказом от Apache2 в пользу чистого Nginx, это накладывает ряд дополнительных задач по адаптации .htaccess
      кроме того, наличие устаноленного php56 говорит о том, что скорее всего используются сторонние репозитории php. Что так же указывает на дополнительную работу со стороны оперейшенс. Те по сути то все сделано классно, но что бы было отлично, не хватает 1 детали.
      Те между 1 и 9 вариантом разница лишь в оптимизаторе, который умышленно или случайно забыли включить.
  • 0
    Удивительно, что все сильно любят nginx и совершенно не упоминают lighttpd, а ведь он весьма прост в настройке и имеет неплохую производительность. У меня все сайты работают на связке lighttpd+php-fcgi и не жужжат. У lighttpd встроенный менеджер процессов FastCGI, кстати.
  • 0
    А bitrixvm какой вариант использует?
    • 0
      К сожалению, у них пятный вариант. nginx front + Apache2 + mod_php53 + apc или Apache2 + mod_php54+ opcache
      в зависимости от версии
      • 0
        или apc, opcache скорее только c php55. Для php54 — apc
    • 0
      CentOS 6.6
      NGINX + Apache2
      MySQL5 with InnoDB support
      Обновление ПО:
      php — 5.4
      mysql — 5.5
      nginx — 1.6.2
  • –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. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).
    • 0
      Зачем эти громоздкие графики скорости скачивания для исполняемых файлов? Кого это волнует, если время генерации намного важнее?

      Никто не скачивает исполняемые файлы. На графиках скорость генерации кода, об этом написано в тексте.

      Зачем вообще тестировать без apc/opcache? Таких дебилов вроде не осталось, вроде все знают что будет в 3-5 раз медленнее.

      99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache

      Где сравнение с mod_fastcgi/mod_fcgid?

      Если вы сделаете такую статью, то она будет.

      Где графики, подверждающие это? Где сравнение разных воркеров апача?

      В других тестах, которых тысячи в интернете

      «Nginx ускорит ваш php в разы!».

      Вы не правы. В этом тесте все равно в качестве фронтенда стоит Nginx. Об этом написано, если замерять скорость голого apache vs nginx то порядок цифр будет другим. Об этом тоже написано.

      Выводы про apache/nginx в плане статики нельзя приводить без графиков и без сравнения разных воркеров в apache. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).

      Порадуйте нас своим сравнением, думаю что это было бы интересно для многих.
      • –2
        >>На графиках скорость генерации кода, об этом написано в тексте.
        На графиках download speed в kbps. Зачем засорять статью этим ненужным мусором? Статику что ли отдаёшь через php?

        >>99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache
        Ну значит не надо использовать 99% хостингов, которые не используют APC. В заголовке же не сказано «выбираем говнохостинг», речь вроде как о своём сервере или VPS.

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

        >>В других тестах, которых тысячи в интернете
        Если в статье этого нет, то и не надо об этом писать.

        >>Об этом тоже написано.
        Что написано? Причём тут статика? Речь PHP, конкретно в твоей таблице apache2 быстрее nginx.

        Вообщем внизу правильно написано, непонятен вообще смысл этой статьи с очевидными вещами, тестирования mod_php вместо mod_fastcgi и рассуждениях о говнохостингах без apc.
        • 0
          Ваша карма полностью отражает качество и суть ваших комментариев.
          • –3
            Ну если нечего ответить по существу, то слив принимается.
  • 0
    Спасибо за сравнительный анализ!
    Конфиги бы :)
    • 0
      А какие конфиги интересуют?
  • 0
    Спасибо.
    Использую связку nginx+apache+php-fpm/mod_php+opcache.
  • 0
    PHP 5.3 уже почти год, как не поддерживается. Советую всем познакомиться с этой страницей php.net/supported-versions.php
    • 0
      Это известный факт. Но старых сайтов очень много. И не всякий имеет желание тратить на их адаптацию.
      • 0
        До первого взлома с лежащим сайтом и потерянной репутацией.
        • 0
          Именно так, но люди не всегда делают все правильно.
          Если провести анализ, с целью собрать статистику версий php, то окажется что большинство php53
          • –1
            Я знаю и с этим нужно что-то делать. Сейчас твою статью прочтет «школьник» и купит хостинг со старым софтом. Поэтому нельзя в таких статьях писать про устаревшее и заброшенное ПО.
            Новые версии CMS не работают на старом PHP, но в них исправлены ошибки. На старом PHP работают старые версии и с дырами. Потом через них спамят и ддосят нормальные системы, воруют личные данные. А из этого складывается негативная репутация для технологии в целом. А еще начинают строить всякие SQL фильтры для серверов, которые якобы защищают, но из-за которых статью с примерами SQL-запросов не добавить в базу.
            Даже если новая версия PHP работает медленнее, это лучше, т.к. в ней добавлены необходимые проверки, исправлены баги. В конце концов есть сообщество, которое обращает внимание на существующие проблемы.
            • 0
              Не вижу связи между 90% хостингов с php53 в качестве интерпретатора и статьей.
              Скорее люди будут стремится использовать современный софт и будут предметно понимать суть вопроса.
              Надеюсь так же хостеры, будут обновлять свои сервера но это от меня никак не зависит.
  • +1
    Стоит определиться сразу, что если человек сидит на хостинге, где нет возможности включить или настроить что-то, то это его личная проблема, и рассматривать этот случай вообще не нужно.

    Во всех остальных случаях максимальная скорость работы php-сайта достигается через правильное количество потоков (по одному на ядро) nginx+gzip (со статик-модулем конечно же), и через правильное количество потоков php-fpm, естественно с акселератором.

    Тут даже писать не о чем. Это очевидно и доступно любому человеку на любом уровне знакомства с сервером, кроме полного нуля — в этом случае стоит обратиться к специалисту.

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

    Далее.

    Тестирование скорости и отзывчивости сайта производится один раз в минуту(!) 60 раз в час (всего!) Заббиксом! И на основании этих данных строятся какие-то выводы. Как будто никто и никогда до автора не содавал никаких инструментов и иметодик тестирования.

    Автор говорит о том, что Заббикс-де загружает только страницу. Но при этом в тестировании участвует конфигурация, в которой статика отдаётся через nginx. Какое отношение статика имеет к тестированию php? Если никакого, то зачем об этом вообще писать?

    Также не учтено время путешествия сетевого пакета до сервера. Какое оно? Когда мы видим цифры 200мс, а потом 100мс, то как можно судить на сколько сократилось время генерации страницы средствами php? Если пинг был 90мс, то по факту мы имеем не двухкратный, а двадцатикратный(!) прирост производительности.

    По факту статья — гадание на кофейной гуще.

    Тесты с Apache, тесты с nginx, тесты с акселераторами — всё покрыто туманом. Какой конфиг? Какая машина? Сколько ядер? Что ещё работало в момент тестирования? При 60 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.

    Это не для Хабра статья, а для школьного журнала. Такое моё мнение.
    • –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 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.

      Это не для Хабра статья, а для школьного журнала. Такое моё мнение.

      Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания. Конфигурацию я приводил выше в одном из комментариев, но и конфигурация общая для всех испытуемых.
      • +2
        > При чем тут gzip?
        Это влияет на время отдачи контента, которое вы меряли в сумме со временем генерации контента. Зачем вы так делали — это вам видней.

        > о каком количестве потоков php-fpm идет речь?
        Процессов, а не потоков, простите. Теперь хорошо?

        > вы знакомы с тем как работает php-fpm?
        Да. Если процессов будет слишком мало, то сервер будет отдавать меньше страниц в секунду, чем мог бы. Вы этот вопрос вообще не затрагивали, почему-то. А стоило бы. Если слишком много — будет проседать производительность опять же на большом числе запросов.

        > На каком основании вы сделали этот вывод?
        На основании много чего, включая практику и такие же статьи и тестирования, только нормальные. По факту в XXI Апач вообще не нужен.

        > Вы знаете как работает memcache? он выделяется установленным блоком
        Это очень круто, но ядро ОС круче полюбас. Это я даже не касаюсь вопроса, как именно вы лазили в мемкеш, ибо если через TCP, то это феил, и эти операции никак не могут быть быстрее файлового кеша ОС. Ну никак. Ну прости. Так устроены современные ОС. На это было пложено куча сил, и результат прекрасен.

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

        > Что значит молниеностные?
        Прям такие: вжиууу! И готово. Ещё раз. С некоторых пор ОС рапортует о завершении фаловых операций ещё до их начала. А данные помещает в кеш в свободной оперативной памяти. Это касается всех современных систем. И да, частые файлы это и есть файлы сайта, по той простой причине, что сервер зачастую не перезапускается годами, а обращения к файлам происходят именно с файлами вашего сайта и с сессиями. =) Которые в свою очередь отлично помещаются в кеш, т.к. маленькие. Иногда даже просто малюсенькие.

        > Как раз по сравнению с синтетическими тестами
        Наверное Заббикс пользуется огнелисом и замеряет время ручным секундомером. На фотке случайно не его рука?

        > что с фактором повторяемости результата?
        > Те у результатов хорошая повторяемость и воспроизводимость.
        Наверное, прекрасная. Повторяемость результата, который ничего не значит. =) Поздравляю. Один раз в минуту понятет любой хостинг с любыми настройками. Если у вас такая бешенная плотность запросов — стоит остановиться на шаред хостинге и успокоиться. Учитывая, что ещё происходили некие неосвещённые статьёй запросы в БД, то время, которое вы намеряли — оно никак не связано с темой статьи.

        > Страница html содержит ссылки на объекты css, js и различную графику, которую заббикс так же пытается загрузить.
        Зачем? Как это связано со временем генерации страницы силами php? Как он это делает? В сколько потоков? Как у вас размещён этот контент? На одном домене или в CDN? Удаётся ли ему загрузить всё-всё до последней капельки без проблем, или он где-то может залипать на таймаутах? Зачем вообще вы это меряли, если это никак, ну никак не связано со временем генерации HTML-кода?

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

        > Тестирование происходит локально, через zabbix-proxy на том же сервере. Те localhost
        Жесть какая. Т.е. по факту, у вас само тестирование может влиять на тестируемое время генерации контента. Так делать нельзя.

        > Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания.
        Не может. Нельзя так делать. Вы должны показывать людям всё, что имеет отношение к исследованию. Вы можете о чем-то не знать, ошибаться, или ещё чего. Кто-то может неожиданно сообщить вам что-то новое и важное. Все такие действия нарушают чистоту эксперимента, и напускают ненужного туману. И вообще как так у Апача и нгинкса могут быть одинаковые конфиги. Этого не может быть, потому что этого не может быть никогда. =)

        > но и конфигурация общая для всех испытуемых.
        Это видимо крайне секретная конфигурация. Более того, стоит оговаривать, на виртуалке ли вдруг и какой вы это делаете, т.к. процессы хоста могут влиять на гостя.

        Про количество замеров. Шесть десятков — это мало. Тыщёнка-другая — ещё куда ни шло. Лучше, если будет по 60 тысяч на каждый тест. С указанием числа конкурентных запросов.

        Вообщем, похоже, что ты намерял хрень. Без обид. Лучше не обижаться, а написать статью с нормальными замерами нормальными средствами типа ab или siege. Я люблю siege. Удачи.
        • –1
          Прошу прощения, пробежался по вашему ответу глазами, мне кажется у вас горячая кровь но маловато знаний и опыта. Это поправимо, все такими были и до сих пор есть. Ничего по существу я не нашел. Предлагаю, если у вас есть какие то дельные пожелания или вопросы, пишите мне в скайп. С радостью Вам все разъясню.
          Тем ни менее, спасибо больше за критику и участие, это очень полезно, в будущем все разумные мысли которые я вынес из ваших слов, я обязательно реализую в новых статьях.
          PS +1 вашему посту за проявленное старание.
          • 0
            слив засчитан
          • 0
            Попробую немного прояснить претензии igordata

            1. gzip

            Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.

            Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.

            И это зависит от настроек серверов.

            2. ping

            Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.

            Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).

            3. Zabbix

            Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.

            4. Конфиги

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

            5. Тестирование

            Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.

            Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.

            А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.
            • 0
              SyCraft частично учёл мои претензии в следующей статье, но всё равно это всё ещё очень далеко от настоящего эксперимента.
              http://habrahabr.ru/post/264775/
              • 0
                в ваших сообщениях не хватает imho
            • 0
              Попробую немного прояснить претензии igordata

              1. gzip

              Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.

              Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.

              И это зависит от настроек серверов.


              2. ping

              Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.

              Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).


              мы тестируем на локальной машине

              3. Zabbix

              Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.

              мы тестируем скорость генерации кода

              4. Конфиги

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


              в продолжении я выложил их

              5. Тестирование

              Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.

              Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.

              А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.

              мы замеряем быстроту а не производительность
              • 0
                Понятно.

                Тогда меня ввел в заблуждение «громкий» заголовок статьи.
                Ожидал большего. Или большого исследования.
                • 0
                  тестов производительности очень много в интернете, ничего нового я бы не написал
                  продолжение habrahabr.ru/post/264775
  • 0
    не туда

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