Comments 85
А почему не выкинули apache в пользу php-fpm?
Кстати nginx был бы гораздо лучшим решением, там хотя бы можно было бы использовать крутое кеширование, да и вообще там затюнить многое можно. после можно было бы принимать еще больше посетителей,
Дело в том, что сервер не имеет прямого подключения к глобальной сети, а выходит в нее через специальное сетевое оборудование. Я пробовал ngnix+php-fpm, но быть может моих знаний в настройке этой связки не хватило или может еще каких-либо нюансов я не учел, но у меня сложилась такая ситуация, что описанные мной настройки показали больший прирост производительности, нежели связка ngnix+php-fpm. Но я продолжаю анализировать причины такого поведения и как только их обнаружу, то непременно поделюсь ими.
Странно. Мне кажется связка nginx+php-fpm гораздо понятнее и удобнее в настройке, к тому же к этой связке такая куча мануалов, можно почти бездумно копипастить и будет работать отлично
Кстати, вместо php-fpm давно уже можно использовать uWSGI. По сути тот же php-fpm, но ещё позволит запускать Python/WSGI, Ruby/rack, Lua/WSAPI и другие приложения :)
Бонусом к такому варианту идёт доступность из PHP функций для работы с кешем uWSGI, к инструментарию RPC, другим «рюшечкам», также можно назначить session.save_handler=uwsgi
Ну и самое главное: слабым местом всегда остаётся само веб-приложение, каким бы ни был сервер…
Бонусом к такому варианту идёт доступность из PHP функций для работы с кешем uWSGI, к инструментарию RPC, другим «рюшечкам», также можно назначить session.save_handler=uwsgi
Ну и самое главное: слабым местом всегда остаётся само веб-приложение, каким бы ни был сервер…
Добавлю, что WordPress проявляет тормозность только когда он основательно набит контентом (вероятно, там есть как минимум линейная зависимость числа неких громоздких операций от количества постов и страниц), поэтому и тестирование нужно проводить при условии, что на сайте будет достаточно много контента. К тому же, наличие контента может поспособствовать тому, что слабым местом как бы внезапно станет не сервер, а интернет-подключение.
А что самое прикольное — uWSGI можно настроить на использование namespaces, чтобы свести к минимуму последствия взлома какого-то vhost.
Ой, а можно подробности о «фризится»? Сломал весь мозг от того, что он иногда подвисает. Как отлавливать?
monit давно написан (=
Форк не умирает после обработки запроса.
Один процесс может обработать несколько запросов, пока не достигнет лимита из переменной pm.max_requests.
Время исполнения скрипта в php ограничено настройками php, как и количество памяти, которое он может захавать.
При ликах памяти он просто жрет память.
Фризиться он может, если залезет в своп.
Один процесс может обработать несколько запросов, пока не достигнет лимита из переменной pm.max_requests.
Время исполнения скрипта в php ограничено настройками php, как и количество памяти, которое он может захавать.
При ликах памяти он просто жрет память.
Фризиться он может, если залезет в своп.
Как одну из причин, замечал как «виснет» php при обращении к внешним ресурсам.
Через, curl, fopen и т.д.
Это можно отследить через strace.
Или у уже зависшего процесса посмотреть /proc//fd, там файлы типа socket с номером.
ls -of | grep <номер> покажет, какое подключение сейчас установлено.
Все не доходят руки написать статью на эту тему.
Через, curl, fopen и т.д.
Это можно отследить через strace.
Или у уже зависшего процесса посмотреть /proc//fd, там файлы типа socket с номером.
ls -of | grep <номер> покажет, какое подключение сейчас установлено.
Все не доходят руки написать статью на эту тему.
При дефиците памяти может помочь установка pm в ondemand.
Есть риск что автор не автор.
Да ладно, из того, что, например, раздел по apache полон кривого перевода с imperialwicket.com/tuning-apache-for-a-low-memory-server-like-aws-micro-ec2-instances/ не следует, что тут плагиат. Этот перевод — уникален в рунете.
//хотя ссылки на первоисточники не помешала бы
//хотя ссылки на первоисточники не помешала бы
И почему не выкинули WP в пользу чего-то менее прожорливого по внутреннему строению? :)
Пример менее прожорливого можете привести? ВП удобен огромным количеством плагинов, можно совершенно не владеть php для вменяемой разработки сайтов на нем.
Вменяемой — не совсем чтобы. Быстрый в создании из кирпичиков — да. Но вот это кирпичестроение требует куда больше ресурсов, как ни крути. Тем более если плагины низкого качества (что не сразу заметно, благо даже дешевый дроплет на DO отлично взлетает и летит, пока не нагрузка не превысит что-то там), то лететь сайту недалеко.
Грубо: сайт у вас меняется редко. Значит, его можно закешировать и держать в виде html-страниц. Но, скажем, кеш можно сбрасывать по таймеру, можно от событий в отношении страницы, можно от вообще любого события на сайте. Как себя поведет тот плагин, что вы поставили как кешер — честно, не скажу точно, но эти три варианта дадут разный уровень нагрузки. А если кеш при этом сложить в БД, или сложить его в файлы на диске, или если сложить его в памяти (что тоже дает свои варианты) — то получим еще набор разных задержек.
Скажем, делаете так: настраиваете отдачу страниц сайта через nginx из файловой системы в ОЗУ (я рассуждаю, что сайт у вас не дикий по размеру), по 404 ошибке nginx дергает ваш второй веб-сервер (что угодно, хоть апач), а тот уже рендерит страницу и записывает ее на нужное место в docroot nginx-а, плюс отдает nginx-у эту же страницу в этот раз. Получается, что nginx шустро будет отдавать страницы, даже если апач у вас упадет. И, если страницы не нужно менять, вы просто выключаете апач+php+mysql, и наслаждаетесь тем, что сайт летает и память пуста. Но вот как вы будете сбрасывать кеш — это, видимо, можно сделать hook-ом внутри WP, отследить изменение страниц, и переписывать их в docroot nginx-а.
P.S. А менее прожорливый — возьмите ModX Evo, но это разные движки, да и любой другой так же.
Грубо: сайт у вас меняется редко. Значит, его можно закешировать и держать в виде html-страниц. Но, скажем, кеш можно сбрасывать по таймеру, можно от событий в отношении страницы, можно от вообще любого события на сайте. Как себя поведет тот плагин, что вы поставили как кешер — честно, не скажу точно, но эти три варианта дадут разный уровень нагрузки. А если кеш при этом сложить в БД, или сложить его в файлы на диске, или если сложить его в памяти (что тоже дает свои варианты) — то получим еще набор разных задержек.
Скажем, делаете так: настраиваете отдачу страниц сайта через nginx из файловой системы в ОЗУ (я рассуждаю, что сайт у вас не дикий по размеру), по 404 ошибке nginx дергает ваш второй веб-сервер (что угодно, хоть апач), а тот уже рендерит страницу и записывает ее на нужное место в docroot nginx-а, плюс отдает nginx-у эту же страницу в этот раз. Получается, что nginx шустро будет отдавать страницы, даже если апач у вас упадет. И, если страницы не нужно менять, вы просто выключаете апач+php+mysql, и наслаждаетесь тем, что сайт летает и память пуста. Но вот как вы будете сбрасывать кеш — это, видимо, можно сделать hook-ом внутри WP, отследить изменение страниц, и переписывать их в docroot nginx-а.
P.S. А менее прожорливый — возьмите ModX Evo, но это разные движки, да и любой другой так же.
После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:
# service apache2 restart
Не надо рестартить сервис там, где это не нужно.
Иногда достаточно сделать reload:
service apache2 reload
Да, вы абсолютно правы! Почему в статье написал именно так, сейчас постараюсь объяснить. Был у меня один случай очень давно. Тогда настраивал apache еще под управление freebsd то ли 6.4, то ли 7.1. И долго не мог разобраться, почему измененный параметр в конфигурации веб-сервера не вступает в силу. Убил на решение проблемы порядка 5-и часов. После перезагрузил сервер и проблема решилась. Начал играться с опциями и обнаружил, что reload не перечитывает конфигурацию, а restart/stop-start выполняется успешно, причем, в логах тоже ничего не было подозрительного. С тех пор выработалась привычка, что когда что-то с нуля подымаю использую, исключительно, опцию restart, а когда в продуктивной среде необходимо что-то изменить в конфигурации на высоконагруженном проекте, то конечно же, использую reload и только reload.
А что вы конкретно тестировали? Заглавную страницу веб-сервера, которая отображается по умолчанию? Судя по приведенной статистике, размер отданной страницы составил 20.69 / 28650 * 1024 ≈ 0.74 кб
В последней табличке: 20 мегабайт и 28650 хитов. Это сколько отдаётся/принимается на один хит? Не слишком ли цифры далеки от реальных приложений?
Смотрю у этого blitz.io нету бесплатного плана, так бы свой не потимизированый ВП для интересу померял.
Смотрю у этого blitz.io нету бесплатного плана, так бы свой не потимизированый ВП для интересу померял.
Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.
Блевать? Буэээ
Не запускайте X-серверYou made my day!
PHP не очень интенсивно использует память, поэтому я не думаю, что нужно сильно беспокоится о потреблении памяти этим процессовTwice!
Советы:
* apache+mod_php -> nginx+php-fpm
Иначе это очень странная борьба за экономию памяти и оптимизацию.
* Главное, чтобы ваш сайт не валился с ошибкой, что php не хватает оперативки.
Ибо 48 метров маловато.
* apc.shm_size=128M в вашем случае это дофига.
Там же в комменте строкой выше указано: ";32M per WordPress install"
* max_connections в mysql — это очень важный параметр, т.к. mysql выделяет кучу памяти на каждое соединение.
С одной стороны, его нельзя делать маленьким — сайт будет выдавать ошибку.
С другой стороны, в целях экономии оперативки его нельзя делать слишком большим.
* Грубо говоря, в key_buffer лежат индексы myisam таблиц.
Поэтому в идеале он должен быть не меньше размера всех индексов myisam таблиц.
Иначе база будет упираться в IO.
* Поставьте самый простой кеширующий dns сервер (dnsmasq, nscd).
Сайт может делать dns запросы на каждый чих.
Делать запрос на dns хостера куда дольше. чем брать из кеша.
Ну и глюканет dns у хостера — у вас все встанет (а такое изредка бывает).
По mysql прочитайте краткое описание важных параметров habrahabr.ru/post/66684/
А что за хостер? И какие диски на вашем ВПС?
Zend Opcache вошел в код Php 5.5 который на тестах лучшее APC
Не подскажете, нет ли для него удобной веб-морды как у APC чтобы мониторить попадания в кэш?
например вот rtcamp.com/tutorials/php/zend-opcache/
А, это синтетические тесты. Я то уж подумал что у вас реально 40M хитов в день и все это как то живет на слабенькой VPS, а владелец сайта настолько жмется =)
Ради интереса проделывал похожие вещи на еще более слабой VPS, но там я сразу отказался от Apache поставив вместо него nginx и скомпилировав на той же машине php 5.7
По сути подобные тесты будут показывать довольно высокую производительность когда все запросы падают на одну страничку и совершенно другая картина будет с реальными пользователями. В случае с плагинами типа W3 cache или надстройками типа Varnish то настройки php и mysql вообще на тест влиять не будут т.к. сервер будет тупо отдавать статичную страничку.
Ради интереса проделывал похожие вещи на еще более слабой VPS, но там я сразу отказался от Apache поставив вместо него nginx и скомпилировав на той же машине php 5.7
По сути подобные тесты будут показывать довольно высокую производительность когда все запросы падают на одну страничку и совершенно другая картина будет с реальными пользователями. В случае с плагинами типа W3 cache или надстройками типа Varnish то настройки php и mysql вообще на тест влиять не будут т.к. сервер будет тупо отдавать статичную страничку.
Советуете переделать InnoDB в MyIsam???!!!
Как только не изощряются люди, лишь бы nginx + php-fpm не использовать. :)
Over 400 RPS на WordPress. Шикарно. На каком контенте и запросах? Допустим, страница статьи с деревом комментариев на 300 штук различной вложенности, которые периодически пополняются. Тоже > 400 rps держит? Было бы прекрасно, но верится с трудом.
Да обычно все сводится к банальному кешированию.
redis, memcache, proxy_cache, fastcgi_cache.
redis, memcache, proxy_cache, fastcgi_cache.
На 512 — гуляй не хочу
вот на 128 все гораздо веселее…
вот на 128 все гораздо веселее…
Имею десятка полтора слабеньких VPS под 256 МБ ОЗУ. Для большинства клиентов хватает с головой. Но вот как поместиться на 128 МБ представляю с трудом. Там ведь никакого резерва не будет. Разве что заранее решить, что ничего кроме статики :)
Раньше vdsplanet по тарифу луна (сейчас у них минимум 256) выдавали 128 оперативки.
Разумеется никакого резерва не было, но хотелось покрасноглазить и запустить.
Сервером понятное дело nginx, для mysql выставил все размеры по 4 метра — на дефолтных настройках ее убивало при старте. PHP вместо fpm использовал php-cgi -b и скрипт в кроне проверки наличия процесса.
Собственно все — в таком состоянии легкие динамические запросы отрабатывались, даже хватало на второй запуск php по крону, правда во время выполнения крона по ssh зайти было нельзя :)
Еще пришлось очень весело генерить локали — sshfs + chroot
Разумеется никакого резерва не было, но хотелось покрасноглазить и запустить.
Сервером понятное дело nginx, для mysql выставил все размеры по 4 метра — на дефолтных настройках ее убивало при старте. PHP вместо fpm использовал php-cgi -b и скрипт в кроне проверки наличия процесса.
Собственно все — в таком состоянии легкие динамические запросы отрабатывались, даже хватало на второй запуск php по крону, правда во время выполнения крона по ssh зайти было нельзя :)
Еще пришлось очень весело генерить локали — sshfs + chroot
Не, не при такой конфигурации естественно.
На действительно нагруженных сайтах все ок с оперативкой, но сама по себе куча оперативки скорости не прибавляет.
Имхо, не бывает нагруженных сайтов (> 1кк уников в сутки) на серверах с 0,5 ГБ оперативки.
На действительно нагруженных сайтах все ок с оперативкой, но сама по себе куча оперативки скорости не прибавляет.
Имхо, не бывает нагруженных сайтов (> 1кк уников в сутки) на серверах с 0,5 ГБ оперативки.
Да, но я не столько про БД, сколько про сервера логики, где выполняется код.
Грубо говоря, php скриптов на диске может лежать на 100-200(-500?) МБ.
Естественно, они быстро окажутся в кеше файловой системы.
Ну и оперативка тратится на код скриптов во время выполнения.
Ну а дальше все.
Если сервер логики не упирался в оперативку ранее, то увеличение, скажем с 16 до 32 ГБ не даст какого-то прироста.
На серверах БД, конечно, больше оперативки позволит запихать в неё больше данных.
Про уников я писал 1кк — это 1 млн, это несколько синтетическая величина с точки зрения нагрузки, согласен.
Грубо говоря, php скриптов на диске может лежать на 100-200(-500?) МБ.
Естественно, они быстро окажутся в кеше файловой системы.
Ну и оперативка тратится на код скриптов во время выполнения.
Ну а дальше все.
Если сервер логики не упирался в оперативку ранее, то увеличение, скажем с 16 до 32 ГБ не даст какого-то прироста.
На серверах БД, конечно, больше оперативки позволит запихать в неё больше данных.
Про уников я писал 1кк — это 1 млн, это несколько синтетическая величина с точки зрения нагрузки, согласен.
безусловно интересные советы, спасибо.
Очень хотелось бы посмотреть как соб-но изменилась производительность «до» и «после». В идеале — при изменении каждого параметра каждого сервиса. Еще хорошо бы посмотреть как меняется load внутри системы. У вас же синтетические тесты, легко их прогнать.
Если этого нет, то неясно что мы теряем и что получаем. А интуиция при подкручивание разных опций может и обмануть.
Очень хотелось бы посмотреть как соб-но изменилась производительность «до» и «после». В идеале — при изменении каждого параметра каждого сервиса. Еще хорошо бы посмотреть как меняется load внутри системы. У вас же синтетические тесты, легко их прогнать.
Если этого нет, то неясно что мы теряем и что получаем. А интуиция при подкручивание разных опций может и обмануть.
А не синтетический тест провести довольно просто — давайте ссылку на Ваш сайт здесь и через часик, если все еще будете иметь доступ к нему, выкладывайте уже картинку красивую.
Казалось бы при чем тут wordpress? )
Ни слова про плагин w3tc, который при правильной настройке позволяет отдавать статику напрямую через nginx. В зависимости от типа контента этот кеш может жить очень долго, единственный неприятный момент — перестанут работать счетчики просмотров постов (для некоторых актуально), лечится использованием JSON счетчиков.
Ни слова про плагин w3tc, который при правильной настройке позволяет отдавать статику напрямую через nginx. В зависимости от типа контента этот кеш может жить очень долго, единственный неприятный момент — перестанут работать счетчики просмотров постов (для некоторых актуально), лечится использованием JSON счетчиков.
Тепличные тесты сферического сайта в вакууме.
Blitz.io не покажет реального положения вещей, танк более-менее покажет реальную нагрузку на тестовом стенде.
У реального сайта с такой посещаемостью будут проблемы совсем другого уровня, ибо будет накручена куча модулей и корявого кода, в котором никто не шарит ибо сменилось 10 поколений разрабов. С этими проблемами в первую очередь и придется столкнуться.
Где кеширование nginx'ом, memcache, XtraDB?
С такой посещалкой экономия на сервере — глупость. Не вводите пользователей в заблуждение, доверяйте профессионалам работу с HL.
Картинка по запросу «Выдуманный Мир»
Blitz.io не покажет реального положения вещей, танк более-менее покажет реальную нагрузку на тестовом стенде.
У реального сайта с такой посещаемостью будут проблемы совсем другого уровня, ибо будет накручена куча модулей и корявого кода, в котором никто не шарит ибо сменилось 10 поколений разрабов. С этими проблемами в первую очередь и придется столкнуться.
Где кеширование nginx'ом, memcache, XtraDB?
С такой посещалкой экономия на сервере — глупость. Не вводите пользователей в заблуждение, доверяйте профессионалам работу с HL.
Картинка по запросу «Выдуманный Мир»
Хм, а ради интереса можете Яндекс Танком шарахнуть по вашему ВП? У меня php-fpm + nginx держал 25 одновременных юзверей, второй тариф на ДО.
Оптимизация для любого веб-сервера начинается с использования nginx + php5-fpm + opcache и настройке кеширования на nginx там где только можно.
Также рекомендую больше внимания всё-таки уделить отключению лишнего в php5-fpm.
А тесты Вам стоит проводить, направив нагрузку на самые тяжелые в плане вычислений места.
Ну и конечно же, отключение логов при малейшем DDoS или попытках взлома Вам обойдутся дорого.
За статью спасибо, но если уж оптимизировать, то по максимуму.
Также рекомендую больше внимания всё-таки уделить отключению лишнего в php5-fpm.
А тесты Вам стоит проводить, направив нагрузку на самые тяжелые в плане вычислений места.
Ну и конечно же, отключение логов при малейшем DDoS или попытках взлома Вам обойдутся дорого.
За статью спасибо, но если уж оптимизировать, то по максимуму.
Какой смысл такого теста? До WordPress даже ничего не дошло, всё тупо из кэша отдалось. Можно и просто странички на html положить и удивляться скорости отдачи сервера за 5$.
А почему в списке включенных модулей нет mod_php?
Тест Varnish'а получился, не?
Переходя на MyISAM помните, что выдергивание сервера из розетки с большой вероятностью даст ручное восстановление данных с потерей некоторой части оных — MyISAM не контролирует свою целостность в отличии от InnoDB. Ну транзакционная целостность… не нужна?
В Apache можете еще обработку .htaccess отключить, а вообще nginx.
Переходя на MyISAM помните, что выдергивание сервера из розетки с большой вероятностью даст ручное восстановление данных с потерей некоторой части оных — MyISAM не контролирует свою целостность в отличии от InnoDB. Ну транзакционная целостность… не нужна?
В Apache можете еще обработку .htaccess отключить, а вообще nginx.
может устроим такой конкурс?
Я думал, что будет рассказано о mod_pagespeed, есть опыт использования mod_pagespeed?
Хотелось бы еще увидеть сайты, которые лежат на серваке. Так как разница между корпоративной визиткой и порталом, как Вы понимаете…
Sign up to leave a comment.
Оптимизируем VPS за 5$ (512MB RAM / 1 CPU) так, что сайт на wordpress выдерживает нагрузку в 42,735,587 хитов в день