Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Можно более подробнее о вашем «SSD-хостинг на серверах ovh.com» — какой тарифный план?
Так же хотелось бы увидеть настройки nginx и mariadb.
Хотелось бы еще сравнения opcache с xcache.
Так же хотелось бы увидеть настройки nginx и mariadb.
Хотелось бы еще сравнения opcache с xcache.
Постараюсь написать об этом в будущих статьях. По вопросам хостинга, можем обсудить в skype. Мы не конкурируем с хостинговыми компаниями. Хостинг под конкретные проекты, которые беремся ускорять.
Тут вопрос был скорее не сколько платите, а на каком железе проводились тесты. Я просто не работал с ovh и уже давно не работаю с хостингами, вот и стало интересно.
Конкретное тестирование проводилось на www.ovh.ie/dedicated_servers/enterprise/2014-SP-64.xml
Хабр? APC? 5.3? Настройки, которые не то что админы умеют делать, а программисты? Об этом надо было писать? )
Может быть, сайт стал пользоваться слишком высокой посещаемостью или был установлен какой-то ресурсоёмкий модуль, совершается атака или сайт заражен вирусом. Так или иначе, но у всех этих случаев есть кое-что общее и это проблема всех сайтов на всех хостингах.
Как человек с бекграундом поддержки сервиса бесплатного хостинга заявляю вот что: в 80% случаев виноваты некоторые внутренности CMS(модули, плагины и т.д.), которые инициируют исходящие соединения.
К примеру:
— курсы валют
— обновление CMS
— SAPE и прочее
А теперь представьте, что по какой-то нелепой случайности иногда это происходит без кеширования, т.е. при каждой загрузке страницы.
Когда внешний ресурс отрабатывает быстро — проблемы нет. Когда не очень (таймаут >1-2 секунд) начинаются массовые проблемы. Посто потребления процессов PHP и т.д.
В самый пик роста популярности CMS даже был скрипт который раз в пару минут проверял доступность серверов обновлений и прочих, к которым пользовательские сайты часто обращились, и, если они лежали, делал блокировку через iptables (при востановлении работы блокировка снималась также автоматически).
Однако, это нискольно не уменьшает значимость статьи. Спасибо за подробное описание методики и результатов!
Блокировать так же стоит с умом) если будет ожидание по сетевому таймауту то ничем хорошим это не закончится.
Самый простой способ быстро справится с этой проблемой — прописать целевой домен, который лег в локальный hosts файл сервера, до тех пор пока сайт не продолжит свою работу.
Если с чем то возникают частые проблемы, то можно так же с локального сервера проксировать запрос по средству nginx. И если целевой proxy_pass не доступен, отдавать что то локальное.
Вариантов множество, но тут вопрос немного о другом.
Самый простой способ быстро справится с этой проблемой — прописать целевой домен, который лег в локальный hosts файл сервера, до тех пор пока сайт не продолжит свою работу.
Если с чем то возникают частые проблемы, то можно так же с локального сервера проксировать запрос по средству nginx. И если целевой proxy_pass не доступен, отдавать что то локальное.
Вариантов множество, но тут вопрос немного о другом.
имейте ввиду, что там не только HTTP и в те времена nginx был не очень популярен.
Да, действительно, задача как раз таки в том, чтобы был connection_refused (iptables:reject), a не timeout(drop).
Но мой комментарий к чему: смена технологии может не дать эффект, если никто не знает, что происходит внутри CMS.
Да, действительно, задача как раз таки в том, чтобы был connection_refused (iptables:reject), a не timeout(drop).
Но мой комментарий к чему: смена технологии может не дать эффект, если никто не знает, что происходит внутри CMS.
Однажды наблюдал проект на хостинге nic.ru, где страница создавалась 30-60 сек (!) Подозревали все и всех, оказалось просто — диск сервера дико тормозил. Причем ТП механически отписывалась, мол, оптимизируйте код.
Тупая смена хостинга на самый обычный VPS (даже без SSD) дала генерацию страницы в 0.5 сек, дальнейшая мелкая настройка (APC, подстройка кешей БД) — еще раза в 3-4 ускорила генерацию.
Думал до того, что «уже все в жизни видел», но такого от мегакомпании nic.ru не ожидал. Тариф причем был самый дорогой из их хостинговых тарифов. Что любопытно, VPS-ка была взята людьми тоже в России (им нужна была бух. отчетность), обошлась если и дороже, то не намного, но — небо и земля.
В общем, рекомендации по оптимизации сайта на «php 5.3 + APC» (чес-слово, вы бы просто на 5.5 перевели бы сайт, если можете позволить — результат бы и без APC сильно порадовал, причем был бы «из коробки») нужно начинать, увы, с простой мысли — «до начала работ решите, быстр ли ваш хостинг».
Тупая смена хостинга на самый обычный VPS (даже без SSD) дала генерацию страницы в 0.5 сек, дальнейшая мелкая настройка (APC, подстройка кешей БД) — еще раза в 3-4 ускорила генерацию.
Думал до того, что «уже все в жизни видел», но такого от мегакомпании nic.ru не ожидал. Тариф причем был самый дорогой из их хостинговых тарифов. Что любопытно, VPS-ка была взята людьми тоже в России (им нужна была бух. отчетность), обошлась если и дороже, то не намного, но — небо и земля.
В общем, рекомендации по оптимизации сайта на «php 5.3 + APC» (чес-слово, вы бы просто на 5.5 перевели бы сайт, если можете позволить — результат бы и без APC сильно порадовал, причем был бы «из коробки») нужно начинать, увы, с простой мысли — «до начала работ решите, быстр ли ваш хостинг».
Полезная статья! Скажите, а почему вы предпочитаете именно MariaDB? Сильно ли повлияет на производительность подобных решений использование Mysql?
Спасибо! вот уже как раз писали об этом habrahabr.ru/post/253869
Почему бы PHP 7 не добавить в сравнение?
Его имеет смысл сравнивать с hhvm
Думаю о подобном сравнении, когда PHP7 будет стабилен.
Думаю о подобном сравнении, когда PHP7 будет стабилен.
Уже через недельку RC планируется.
wiki.php.net/todo/php70#timetable
wiki.php.net/todo/php70#timetable
> 1. Nginx + php-fpm56 без оптимизатора opcache
> По архитектуре — это один из самых передовых вариантов
В этом месте не очень понятно, что передового в сборке php без opcache?
> По архитектуре — это один из самых передовых вариантов
В этом месте не очень понятно, что передового в сборке php без opcache?
Очень редко кто заморачивается с отказом от Apache2 в пользу чистого Nginx, это накладывает ряд дополнительных задач по адаптации .htaccess
кроме того, наличие устаноленного php56 говорит о том, что скорее всего используются сторонние репозитории php. Что так же указывает на дополнительную работу со стороны оперейшенс. Те по сути то все сделано классно, но что бы было отлично, не хватает 1 детали.
Те между 1 и 9 вариантом разница лишь в оптимизаторе, который умышленно или случайно забыли включить.
кроме того, наличие устаноленного php56 говорит о том, что скорее всего используются сторонние репозитории php. Что так же указывает на дополнительную работу со стороны оперейшенс. Те по сути то все сделано классно, но что бы было отлично, не хватает 1 детали.
Те между 1 и 9 вариантом разница лишь в оптимизаторе, который умышленно или случайно забыли включить.
А bitrixvm какой вариант использует?
Зачем эти громоздкие графики скорости скачивания для исполняемых файлов? Кого это волнует, если время генерации намного важнее?
Зачем вообще тестировать без 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. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).
Зачем вообще тестировать без 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. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).
Зачем эти громоздкие графики скорости скачивания для исполняемых файлов? Кого это волнует, если время генерации намного важнее?
Никто не скачивает исполняемые файлы. На графиках скорость генерации кода, об этом написано в тексте.
Зачем вообще тестировать без apc/opcache? Таких дебилов вроде не осталось, вроде все знают что будет в 3-5 раз медленнее.
99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache
Где сравнение с mod_fastcgi/mod_fcgid?
Если вы сделаете такую статью, то она будет.
Где графики, подверждающие это? Где сравнение разных воркеров апача?
В других тестах, которых тысячи в интернете
«Nginx ускорит ваш php в разы!».
Вы не правы. В этом тесте все равно в качестве фронтенда стоит Nginx. Об этом написано, если замерять скорость голого apache vs nginx то порядок цифр будет другим. Об этом тоже написано.
Выводы про apache/nginx в плане статики нельзя приводить без графиков и без сравнения разных воркеров в apache. Нельзя тестировать одно, а выводы делать совсем про другое (даже если они верные).
Порадуйте нас своим сравнением, думаю что это было бы интересно для многих.
>>На графиках скорость генерации кода, об этом написано в тексте.
На графиках download speed в kbps. Зачем засорять статью этим ненужным мусором? Статику что ли отдаёшь через php?
>>99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache
Ну значит не надо использовать 99% хостингов, которые не используют APC. В заголовке же не сказано «выбираем говнохостинг», речь вроде как о своём сервере или VPS.
>>Если вы сделаете такую статью, то она будет.
Это ваша задача, приводить все сравнения в статье, и не делать голословных выводов. Тем более если упомянуты «говнохостинги» без APC, то там не будет идиотов, использующих mod_php, который не умеет разделать пользователей.
>>В других тестах, которых тысячи в интернете
Если в статье этого нет, то и не надо об этом писать.
>>Об этом тоже написано.
Что написано? Причём тут статика? Речь PHP, конкретно в твоей таблице apache2 быстрее nginx.
Вообщем внизу правильно написано, непонятен вообще смысл этой статьи с очевидными вещами, тестирования mod_php вместо mod_fastcgi и рассуждениях о говнохостингах без apc.
На графиках download speed в kbps. Зачем засорять статью этим ненужным мусором? Статику что ли отдаёшь через php?
>>99% хостингов не используют его, на плохом коде он убивает модуль оптимизации и тянет за собой весь apache
Ну значит не надо использовать 99% хостингов, которые не используют APC. В заголовке же не сказано «выбираем говнохостинг», речь вроде как о своём сервере или VPS.
>>Если вы сделаете такую статью, то она будет.
Это ваша задача, приводить все сравнения в статье, и не делать голословных выводов. Тем более если упомянуты «говнохостинги» без APC, то там не будет идиотов, использующих mod_php, который не умеет разделать пользователей.
>>В других тестах, которых тысячи в интернете
Если в статье этого нет, то и не надо об этом писать.
>>Об этом тоже написано.
Что написано? Причём тут статика? Речь PHP, конкретно в твоей таблице apache2 быстрее nginx.
Вообщем внизу правильно написано, непонятен вообще смысл этой статьи с очевидными вещами, тестирования mod_php вместо mod_fastcgi и рассуждениях о говнохостингах без apc.
Спасибо за сравнительный анализ!
Конфиги бы :)
Конфиги бы :)
Спасибо.
Использую связку nginx+apache+php-fpm/mod_php+opcache.
Использую связку nginx+apache+php-fpm/mod_php+opcache.
PHP 5.3 уже почти год, как не поддерживается. Советую всем познакомиться с этой страницей php.net/supported-versions.php
Это известный факт. Но старых сайтов очень много. И не всякий имеет желание тратить на их адаптацию.
До первого взлома с лежащим сайтом и потерянной репутацией.
Именно так, но люди не всегда делают все правильно.
Если провести анализ, с целью собрать статистику версий php, то окажется что большинство php53
Если провести анализ, с целью собрать статистику версий php, то окажется что большинство php53
Я знаю и с этим нужно что-то делать. Сейчас твою статью прочтет «школьник» и купит хостинг со старым софтом. Поэтому нельзя в таких статьях писать про устаревшее и заброшенное ПО.
Новые версии CMS не работают на старом PHP, но в них исправлены ошибки. На старом PHP работают старые версии и с дырами. Потом через них спамят и ддосят нормальные системы, воруют личные данные. А из этого складывается негативная репутация для технологии в целом. А еще начинают строить всякие SQL фильтры для серверов, которые якобы защищают, но из-за которых статью с примерами SQL-запросов не добавить в базу.
Даже если новая версия PHP работает медленнее, это лучше, т.к. в ней добавлены необходимые проверки, исправлены баги. В конце концов есть сообщество, которое обращает внимание на существующие проблемы.
Новые версии CMS не работают на старом PHP, но в них исправлены ошибки. На старом PHP работают старые версии и с дырами. Потом через них спамят и ддосят нормальные системы, воруют личные данные. А из этого складывается негативная репутация для технологии в целом. А еще начинают строить всякие SQL фильтры для серверов, которые якобы защищают, но из-за которых статью с примерами SQL-запросов не добавить в базу.
Даже если новая версия PHP работает медленнее, это лучше, т.к. в ней добавлены необходимые проверки, исправлены баги. В конце концов есть сообщество, которое обращает внимание на существующие проблемы.
Стоит определиться сразу, что если человек сидит на хостинге, где нет возможности включить или настроить что-то, то это его личная проблема, и рассматривать этот случай вообще не нужно.
Во всех остальных случаях максимальная скорость работы php-сайта достигается через правильное количество потоков (по одному на ядро) nginx+gzip (со статик-модулем конечно же), и через правильное количество потоков php-fpm, естественно с акселератором.
Тут даже писать не о чем. Это очевидно и доступно любому человеку на любом уровне знакомства с сервером, кроме полного нуля — в этом случае стоит обратиться к специалисту.
Про кеширование в мемкеше. Сессии на файлах, которые дефолтны в php для сессий, и которые с лёгкой руки автора были исключены из рассмотрения, будут быстрее в случае, если в системе есть свободная память. Современные системы кешируют файловые операции в свободной оперативке. Поэтому комп нельзя просто выдернуть из розетки ещё со времён 95-й Винды. Это тоже должно быть очевидно любому специалисту, или тому, кто хотел бы им стать. Операции с этим кешем очень быстрые, они происходят, если не ошибаюсь, чуть ли не на уровне ядра. Они молниеносные. Правда только до тех пор, пока есть свободная память.
Далее.
Тестирование скорости и отзывчивости сайта производится один раз в минуту(!) 60 раз в час (всего!) Заббиксом! И на основании этих данных строятся какие-то выводы. Как будто никто и никогда до автора не содавал никаких инструментов и иметодик тестирования.
Автор говорит о том, что Заббикс-де загружает только страницу. Но при этом в тестировании участвует конфигурация, в которой статика отдаётся через nginx. Какое отношение статика имеет к тестированию php? Если никакого, то зачем об этом вообще писать?
Также не учтено время путешествия сетевого пакета до сервера. Какое оно? Когда мы видим цифры 200мс, а потом 100мс, то как можно судить на сколько сократилось время генерации страницы средствами php? Если пинг был 90мс, то по факту мы имеем не двухкратный, а двадцатикратный(!) прирост производительности.
По факту статья — гадание на кофейной гуще.
Тесты с Apache, тесты с nginx, тесты с акселераторами — всё покрыто туманом. Какой конфиг? Какая машина? Сколько ядер? Что ещё работало в момент тестирования? При 60 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.
Это не для Хабра статья, а для школьного журнала. Такое моё мнение.
Во всех остальных случаях максимальная скорость работы php-сайта достигается через правильное количество потоков (по одному на ядро) nginx+gzip (со статик-модулем конечно же), и через правильное количество потоков php-fpm, естественно с акселератором.
Тут даже писать не о чем. Это очевидно и доступно любому человеку на любом уровне знакомства с сервером, кроме полного нуля — в этом случае стоит обратиться к специалисту.
Про кеширование в мемкеше. Сессии на файлах, которые дефолтны в php для сессий, и которые с лёгкой руки автора были исключены из рассмотрения, будут быстрее в случае, если в системе есть свободная память. Современные системы кешируют файловые операции в свободной оперативке. Поэтому комп нельзя просто выдернуть из розетки ещё со времён 95-й Винды. Это тоже должно быть очевидно любому специалисту, или тому, кто хотел бы им стать. Операции с этим кешем очень быстрые, они происходят, если не ошибаюсь, чуть ли не на уровне ядра. Они молниеносные. Правда только до тех пор, пока есть свободная память.
Далее.
Тестирование скорости и отзывчивости сайта производится один раз в минуту(!) 60 раз в час (всего!) Заббиксом! И на основании этих данных строятся какие-то выводы. Как будто никто и никогда до автора не содавал никаких инструментов и иметодик тестирования.
Автор говорит о том, что Заббикс-де загружает только страницу. Но при этом в тестировании участвует конфигурация, в которой статика отдаётся через nginx. Какое отношение статика имеет к тестированию php? Если никакого, то зачем об этом вообще писать?
Также не учтено время путешествия сетевого пакета до сервера. Какое оно? Когда мы видим цифры 200мс, а потом 100мс, то как можно судить на сколько сократилось время генерации страницы средствами php? Если пинг был 90мс, то по факту мы имеем не двухкратный, а двадцатикратный(!) прирост производительности.
По факту статья — гадание на кофейной гуще.
Тесты с Apache, тесты с nginx, тесты с акселераторами — всё покрыто туманом. Какой конфиг? Какая машина? Сколько ядер? Что ещё работало в момент тестирования? При 60 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.
Это не для Хабра статья, а для школьного журнала. Такое моё мнение.
Стоит определиться сразу, что если человек сидит на хостинге, где нет возможности включить или настроить что-то, то это его личная проблема, и рассматривать этот случай вообще не нужно
Очевидно что такой хостинг нужно поменять на что то более производительное за аналогичные деньги.
Во всех остальных случаях максимальная скорость работы 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 единичных замерах говорить о представлении о производительности просто невозможно. Неясно как поведёт себя вся эта конфигурация, если запросов будет больше определённого порога, и начнутся затыки, какая будет лидировать тогда.
Это не для Хабра статья, а для школьного журнала. Такое моё мнение.
Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания. Конфигурацию я приводил выше в одном из комментариев, но и конфигурация общая для всех испытуемых.
> При чем тут gzip?
Это влияет на время отдачи контента, которое вы меряли в сумме со временем генерации контента. Зачем вы так делали — это вам видней.
> о каком количестве потоков php-fpm идет речь?
Процессов, а не потоков, простите. Теперь хорошо?
> вы знакомы с тем как работает php-fpm?
Да. Если процессов будет слишком мало, то сервер будет отдавать меньше страниц в секунду, чем мог бы. Вы этот вопрос вообще не затрагивали, почему-то. А стоило бы. Если слишком много — будет проседать производительность опять же на большом числе запросов.
> На каком основании вы сделали этот вывод?
На основании много чего, включая практику и такие же статьи и тестирования, только нормальные. По факту в XXI Апач вообще не нужен.
> Вы знаете как работает memcache? он выделяется установленным блоком
Это очень круто, но ядро ОС круче полюбас. Это я даже не касаюсь вопроса, как именно вы лазили в мемкеш, ибо если через TCP, то это феил, и эти операции никак не могут быть быстрее файлового кеша ОС. Ну никак. Ну прости. Так устроены современные ОС. На это было пложено куча сил, и результат прекрасен.
> как кеширование поможет скорости установки сессии из ваших слов не очевидно
А из ваших очевидно? Вы упоминули логин. При логине *обычно* нужна сессия. Создание сессии или её чтение из какого-либо источника однозначно влияют на скорость генерации контента, т.к. явлюятся блокирующей операцией при выполнении кода, который и генерирует контент. Ускоряя этот этап, мы напрямую ускоряем и отдачу страницы. Если вам это неочевидно — опять же стот подтянуть базис. Сейчас он у вас проседает по всем фронтам.
> Что значит молниеностные?
Прям такие: вжиууу! И готово. Ещё раз. С некоторых пор ОС рапортует о завершении фаловых операций ещё до их начала. А данные помещает в кеш в свободной оперативной памяти. Это касается всех современных систем. И да, частые файлы это и есть файлы сайта, по той простой причине, что сервер зачастую не перезапускается годами, а обращения к файлам происходят именно с файлами вашего сайта и с сессиями. =) Которые в свою очередь отлично помещаются в кеш, т.к. маленькие. Иногда даже просто малюсенькие.
> Как раз по сравнению с синтетическими тестами
Наверное Заббикс пользуется огнелисом и замеряет время ручным секундомером. На фотке случайно не его рука?
> что с фактором повторяемости результата?
> Те у результатов хорошая повторяемость и воспроизводимость.
Наверное, прекрасная. Повторяемость результата, который ничего не значит. =) Поздравляю. Один раз в минуту понятет любой хостинг с любыми настройками. Если у вас такая бешенная плотность запросов — стоит остановиться на шаред хостинге и успокоиться. Учитывая, что ещё происходили некие неосвещённые статьёй запросы в БД, то время, которое вы намеряли — оно никак не связано с темой статьи.
> Страница html содержит ссылки на объекты css, js и различную графику, которую заббикс так же пытается загрузить.
Зачем? Как это связано со временем генерации страницы силами php? Как он это делает? В сколько потоков? Как у вас размещён этот контент? На одном домене или в CDN? Удаётся ли ему загрузить всё-всё до последней капельки без проблем, или он где-то может залипать на таймаутах? Зачем вообще вы это меряли, если это никак, ну никак не связано со временем генерации HTML-кода?
>Что бы исключить
Что бы выпить, чтобы напиться. Это просто удобный способ запомнить, когда слитно, а когда нет.
> Тестирование происходит локально, через zabbix-proxy на том же сервере. Те localhost
Жесть какая. Т.е. по факту, у вас само тестирование может влиять на тестируемое время генерации контента. Так делать нельзя.
> Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания.
Не может. Нельзя так делать. Вы должны показывать людям всё, что имеет отношение к исследованию. Вы можете о чем-то не знать, ошибаться, или ещё чего. Кто-то может неожиданно сообщить вам что-то новое и важное. Все такие действия нарушают чистоту эксперимента, и напускают ненужного туману. И вообще как так у Апача и нгинкса могут быть одинаковые конфиги. Этого не может быть, потому что этого не может быть никогда. =)
> но и конфигурация общая для всех испытуемых.
Это видимо крайне секретная конфигурация. Более того, стоит оговаривать, на виртуалке ли вдруг и какой вы это делаете, т.к. процессы хоста могут влиять на гостя.
Про количество замеров. Шесть десятков — это мало. Тыщёнка-другая — ещё куда ни шло. Лучше, если будет по 60 тысяч на каждый тест. С указанием числа конкурентных запросов.
Вообщем, похоже, что ты намерял хрень. Без обид. Лучше не обижаться, а написать статью с нормальными замерами нормальными средствами типа ab или siege. Я люблю siege. Удачи.
Это влияет на время отдачи контента, которое вы меряли в сумме со временем генерации контента. Зачем вы так делали — это вам видней.
> о каком количестве потоков php-fpm идет речь?
Процессов, а не потоков, простите. Теперь хорошо?
> вы знакомы с тем как работает php-fpm?
Да. Если процессов будет слишком мало, то сервер будет отдавать меньше страниц в секунду, чем мог бы. Вы этот вопрос вообще не затрагивали, почему-то. А стоило бы. Если слишком много — будет проседать производительность опять же на большом числе запросов.
> На каком основании вы сделали этот вывод?
На основании много чего, включая практику и такие же статьи и тестирования, только нормальные. По факту в XXI Апач вообще не нужен.
> Вы знаете как работает memcache? он выделяется установленным блоком
Это очень круто, но ядро ОС круче полюбас. Это я даже не касаюсь вопроса, как именно вы лазили в мемкеш, ибо если через TCP, то это феил, и эти операции никак не могут быть быстрее файлового кеша ОС. Ну никак. Ну прости. Так устроены современные ОС. На это было пложено куча сил, и результат прекрасен.
> как кеширование поможет скорости установки сессии из ваших слов не очевидно
А из ваших очевидно? Вы упоминули логин. При логине *обычно* нужна сессия. Создание сессии или её чтение из какого-либо источника однозначно влияют на скорость генерации контента, т.к. явлюятся блокирующей операцией при выполнении кода, который и генерирует контент. Ускоряя этот этап, мы напрямую ускоряем и отдачу страницы. Если вам это неочевидно — опять же стот подтянуть базис. Сейчас он у вас проседает по всем фронтам.
> Что значит молниеностные?
Прям такие: вжиууу! И готово. Ещё раз. С некоторых пор ОС рапортует о завершении фаловых операций ещё до их начала. А данные помещает в кеш в свободной оперативной памяти. Это касается всех современных систем. И да, частые файлы это и есть файлы сайта, по той простой причине, что сервер зачастую не перезапускается годами, а обращения к файлам происходят именно с файлами вашего сайта и с сессиями. =) Которые в свою очередь отлично помещаются в кеш, т.к. маленькие. Иногда даже просто малюсенькие.
> Как раз по сравнению с синтетическими тестами
Наверное Заббикс пользуется огнелисом и замеряет время ручным секундомером. На фотке случайно не его рука?
> что с фактором повторяемости результата?
> Те у результатов хорошая повторяемость и воспроизводимость.
Наверное, прекрасная. Повторяемость результата, который ничего не значит. =) Поздравляю. Один раз в минуту понятет любой хостинг с любыми настройками. Если у вас такая бешенная плотность запросов — стоит остановиться на шаред хостинге и успокоиться. Учитывая, что ещё происходили некие неосвещённые статьёй запросы в БД, то время, которое вы намеряли — оно никак не связано с темой статьи.
> Страница html содержит ссылки на объекты css, js и различную графику, которую заббикс так же пытается загрузить.
Зачем? Как это связано со временем генерации страницы силами php? Как он это делает? В сколько потоков? Как у вас размещён этот контент? На одном домене или в CDN? Удаётся ли ему загрузить всё-всё до последней капельки без проблем, или он где-то может залипать на таймаутах? Зачем вообще вы это меряли, если это никак, ну никак не связано со временем генерации HTML-кода?
>Что бы исключить
Что бы выпить, чтобы напиться. Это просто удобный способ запомнить, когда слитно, а когда нет.
> Тестирование происходит локально, через zabbix-proxy на том же сервере. Те localhost
Жесть какая. Т.е. по факту, у вас само тестирование может влиять на тестируемое время генерации контента. Так делать нельзя.
> Конфиги одинаковые, те все что имеет общий корень, может быть вынесено за пределы описания.
Не может. Нельзя так делать. Вы должны показывать людям всё, что имеет отношение к исследованию. Вы можете о чем-то не знать, ошибаться, или ещё чего. Кто-то может неожиданно сообщить вам что-то новое и важное. Все такие действия нарушают чистоту эксперимента, и напускают ненужного туману. И вообще как так у Апача и нгинкса могут быть одинаковые конфиги. Этого не может быть, потому что этого не может быть никогда. =)
> но и конфигурация общая для всех испытуемых.
Это видимо крайне секретная конфигурация. Более того, стоит оговаривать, на виртуалке ли вдруг и какой вы это делаете, т.к. процессы хоста могут влиять на гостя.
Про количество замеров. Шесть десятков — это мало. Тыщёнка-другая — ещё куда ни шло. Лучше, если будет по 60 тысяч на каждый тест. С указанием числа конкурентных запросов.
Вообщем, похоже, что ты намерял хрень. Без обид. Лучше не обижаться, а написать статью с нормальными замерами нормальными средствами типа ab или siege. Я люблю siege. Удачи.
Прошу прощения, пробежался по вашему ответу глазами, мне кажется у вас горячая кровь но маловато знаний и опыта. Это поправимо, все такими были и до сих пор есть. Ничего по существу я не нашел. Предлагаю, если у вас есть какие то дельные пожелания или вопросы, пишите мне в скайп. С радостью Вам все разъясню.
Тем ни менее, спасибо больше за критику и участие, это очень полезно, в будущем все разумные мысли которые я вынес из ваших слов, я обязательно реализую в новых статьях.
PS +1 вашему посту за проявленное старание.
Тем ни менее, спасибо больше за критику и участие, это очень полезно, в будущем все разумные мысли которые я вынес из ваших слов, я обязательно реализую в новых статьях.
PS +1 вашему посту за проявленное старание.
слив засчитан
Попробую немного прояснить претензии igordata
1. gzip
Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.
Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.
И это зависит от настроек серверов.
2. ping
Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.
Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).
3. Zabbix
Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.
4. Конфиги
Их лучше выложить, чтобы другие люди смогли проверить, потестировать сами. И после этого конструктивно спорить.
5. Тестирование
Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.
Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.
А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.
1. gzip
Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.
Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.
И это зависит от настроек серверов.
2. ping
Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.
Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).
3. Zabbix
Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.
4. Конфиги
Их лучше выложить, чтобы другие люди смогли проверить, потестировать сами. И после этого конструктивно спорить.
5. Тестирование
Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.
Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.
А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.
SyCraft частично учёл мои претензии в следующей статье, но всё равно это всё ещё очень далеко от настоящего эксперимента.
http://habrahabr.ru/post/264775/
http://habrahabr.ru/post/264775/
Попробую немного прояснить претензии igordata
1. gzip
Насколько я помню, Zabbix не умеет запрашивать с веб-серверов страницы, используя сжатие.
Если сервер «далеко», и канал небыстрый — передача меньшего кол-ва данных может «ускорить» результаты.
И это зависит от настроек серверов.
2. ping
Если замеры велись с другого сервера, то хорошо бы учитывать время ответа сервера и пересылки кусочков (chunk) данных. Обычно можно смело отнимать 2*ping миллисекунд от результата.
Т.е. лучше замерять с соседнего сервера или ВМ (если ядерность позволяет).
мы тестируем на локальной машине
3. Zabbix
Zabbix не скачивает js, css и прочую статику из кода html. Совсем. Просто скачивает по URL, смотрит код ответа, время ответа и т.д.
мы тестируем скорость генерации кода
4. Конфиги
Их лучше выложить, чтобы другие люди смогли проверить, потестировать сами. И после этого конструктивно спорить.
в продолжении я выложил их
5. Тестирование
Не хватает самой интересной части — как разные версии кушают память и как справляются с «типовыми» нагрузками.
Память можно померять и zabbix-ом, но очень ограниченно — процессы apache и fpm не будут висеть постоянно.
А вот «типовую» нагрузку, похожую на поведение пользователя с переходами по страницам, можно получить с помощью siege. Чтобы оценить работу php, нужно застравить его поработать, попользовать кеш на 100%, поработать с БД и т.д.
мы замеряем быстроту а не производительность
Понятно.
Тогда меня ввел в заблуждение «громкий» заголовок статьи.
Ожидал большего. Или большого исследования.
Тогда меня ввел в заблуждение «громкий» заголовок статьи.
Ожидал большего. Или большого исследования.
тестов производительности очень много в интернете, ничего нового я бы не написал
продолжение habrahabr.ru/post/264775
продолжение habrahabr.ru/post/264775
не туда
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP