Comments 85
А почему не выкинули apache в пользу php-fpm?
+48
Кстати nginx был бы гораздо лучшим решением, там хотя бы можно было бы использовать крутое кеширование, да и вообще там затюнить многое можно. после можно было бы принимать еще больше посетителей,
+3
Дело в том, что сервер не имеет прямого подключения к глобальной сети, а выходит в нее через специальное сетевое оборудование. Я пробовал ngnix+php-fpm, но быть может моих знаний в настройке этой связки не хватило или может еще каких-либо нюансов я не учел, но у меня сложилась такая ситуация, что описанные мной настройки показали больший прирост производительности, нежели связка ngnix+php-fpm. Но я продолжаю анализировать причины такого поведения и как только их обнаружу, то непременно поделюсь ими.
+1
Странно. Мне кажется связка nginx+php-fpm гораздо понятнее и удобнее в настройке, к тому же к этой связке такая куча мануалов, можно почти бездумно копипастить и будет работать отлично
+3
Кстати, вместо 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
Ну и самое главное: слабым местом всегда остаётся само веб-приложение, каким бы ни был сервер…
+1
Добавлю, что WordPress проявляет тормозность только когда он основательно набит контентом (вероятно, там есть как минимум линейная зависимость числа неких громоздких операций от количества постов и страниц), поэтому и тестирование нужно проводить при условии, что на сайте будет достаточно много контента. К тому же, наличие контента может поспособствовать тому, что слабым местом как бы внезапно станет не сервер, а интернет-подключение.
0
А что самое прикольное — uWSGI можно настроить на использование namespaces, чтобы свести к минимуму последствия взлома какого-то vhost.
+1
UFO just landed and posted this here
Ой, а можно подробности о «фризится»? Сломал весь мозг от того, что он иногда подвисает. Как отлавливать?
0
UFO just landed and posted this here
monit давно написан (=
0
Форк не умирает после обработки запроса.
Один процесс может обработать несколько запросов, пока не достигнет лимита из переменной pm.max_requests.
Время исполнения скрипта в php ограничено настройками php, как и количество памяти, которое он может захавать.
При ликах памяти он просто жрет память.
Фризиться он может, если залезет в своп.
Один процесс может обработать несколько запросов, пока не достигнет лимита из переменной pm.max_requests.
Время исполнения скрипта в php ограничено настройками php, как и количество памяти, которое он может захавать.
При ликах памяти он просто жрет память.
Фризиться он может, если залезет в своп.
+2
UFO just landed and posted this here
Как одну из причин, замечал как «виснет» php при обращении к внешним ресурсам.
Через, curl, fopen и т.д.
Это можно отследить через strace.
Или у уже зависшего процесса посмотреть /proc//fd, там файлы типа socket с номером.
ls -of | grep <номер> покажет, какое подключение сейчас установлено.
Все не доходят руки написать статью на эту тему.
Через, curl, fopen и т.д.
Это можно отследить через strace.
Или у уже зависшего процесса посмотреть /proc//fd, там файлы типа socket с номером.
ls -of | grep <номер> покажет, какое подключение сейчас установлено.
Все не доходят руки написать статью на эту тему.
0
При дефиците памяти может помочь установка pm в ondemand.
0
Есть риск что автор не автор.
+2
Да ладно, из того, что, например, раздел по apache полон кривого перевода с imperialwicket.com/tuning-apache-for-a-low-memory-server-like-aws-micro-ec2-instances/ не следует, что тут плагиат. Этот перевод — уникален в рунете.
//хотя ссылки на первоисточники не помешала бы
//хотя ссылки на первоисточники не помешала бы
0
И почему не выкинули WP в пользу чего-то менее прожорливого по внутреннему строению? :)
0
Пример менее прожорливого можете привести? ВП удобен огромным количеством плагинов, можно совершенно не владеть php для вменяемой разработки сайтов на нем.
0
Вменяемой — не совсем чтобы. Быстрый в создании из кирпичиков — да. Но вот это кирпичестроение требует куда больше ресурсов, как ни крути. Тем более если плагины низкого качества (что не сразу заметно, благо даже дешевый дроплет на 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, но это разные движки, да и любой другой так же.
0
UFO just landed and posted this here
После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:
# service apache2 restart
Не надо рестартить сервис там, где это не нужно.
Иногда достаточно сделать reload:
service apache2 reload
+5
Да, вы абсолютно правы! Почему в статье написал именно так, сейчас постараюсь объяснить. Был у меня один случай очень давно. Тогда настраивал apache еще под управление freebsd то ли 6.4, то ли 7.1. И долго не мог разобраться, почему измененный параметр в конфигурации веб-сервера не вступает в силу. Убил на решение проблемы порядка 5-и часов. После перезагрузил сервер и проблема решилась. Начал играться с опциями и обнаружил, что reload не перечитывает конфигурацию, а restart/stop-start выполняется успешно, причем, в логах тоже ничего не было подозрительного. С тех пор выработалась привычка, что когда что-то с нуля подымаю использую, исключительно, опцию restart, а когда в продуктивной среде необходимо что-то изменить в конфигурации на высоконагруженном проекте, то конечно же, использую reload и только reload.
+6
А что вы конкретно тестировали? Заглавную страницу веб-сервера, которая отображается по умолчанию? Судя по приведенной статистике, размер отданной страницы составил 20.69 / 28650 * 1024 ≈ 0.74 кб
+4
В последней табличке: 20 мегабайт и 28650 хитов. Это сколько отдаётся/принимается на один хит? Не слишком ли цифры далеки от реальных приложений?
Смотрю у этого blitz.io нету бесплатного плана, так бы свой не потимизированый ВП для интересу померял.
Смотрю у этого blitz.io нету бесплатного плана, так бы свой не потимизированый ВП для интересу померял.
+2
Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.
Блевать? Буэээ
+2
UFO just landed and posted this here
Не запускайте 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/
+25
А что за хостер? И какие диски на вашем ВПС?
0
Zend Opcache вошел в код Php 5.5 который на тестах лучшее APC
+4
Не подскажете, нет ли для него удобной веб-морды как у APC чтобы мониторить попадания в кэш?
0
например вот rtcamp.com/tutorials/php/zend-opcache/
+3
А, это синтетические тесты. Я то уж подумал что у вас реально 40M хитов в день и все это как то живет на слабенькой VPS, а владелец сайта настолько жмется =)
Ради интереса проделывал похожие вещи на еще более слабой VPS, но там я сразу отказался от Apache поставив вместо него nginx и скомпилировав на той же машине php 5.7
По сути подобные тесты будут показывать довольно высокую производительность когда все запросы падают на одну страничку и совершенно другая картина будет с реальными пользователями. В случае с плагинами типа W3 cache или надстройками типа Varnish то настройки php и mysql вообще на тест влиять не будут т.к. сервер будет тупо отдавать статичную страничку.
Ради интереса проделывал похожие вещи на еще более слабой VPS, но там я сразу отказался от Apache поставив вместо него nginx и скомпилировав на той же машине php 5.7
По сути подобные тесты будут показывать довольно высокую производительность когда все запросы падают на одну страничку и совершенно другая картина будет с реальными пользователями. В случае с плагинами типа W3 cache или надстройками типа Varnish то настройки php и mysql вообще на тест влиять не будут т.к. сервер будет тупо отдавать статичную страничку.
+13
Советуете переделать InnoDB в MyIsam???!!!
+9
Как только не изощряются люди, лишь бы nginx + php-fpm не использовать. :)
+12
Over 400 RPS на WordPress. Шикарно. На каком контенте и запросах? Допустим, страница статьи с деревом комментариев на 300 штук различной вложенности, которые периодически пополняются. Тоже > 400 rps держит? Было бы прекрасно, но верится с трудом.
+2
UFO just landed and posted this here
UFO just landed and posted this here
Да обычно все сводится к банальному кешированию.
redis, memcache, proxy_cache, fastcgi_cache.
redis, memcache, proxy_cache, fastcgi_cache.
0
UFO just landed and posted this here
На 512 — гуляй не хочу
вот на 128 все гораздо веселее…
вот на 128 все гораздо веселее…
+1
Имею десятка полтора слабеньких VPS под 256 МБ ОЗУ. Для большинства клиентов хватает с головой. Но вот как поместиться на 128 МБ представляю с трудом. Там ведь никакого резерва не будет. Разве что заранее решить, что ничего кроме статики :)
0
Раньше 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
Не, не при такой конфигурации естественно.
На действительно нагруженных сайтах все ок с оперативкой, но сама по себе куча оперативки скорости не прибавляет.
Имхо, не бывает нагруженных сайтов (> 1кк уников в сутки) на серверах с 0,5 ГБ оперативки.
На действительно нагруженных сайтах все ок с оперативкой, но сама по себе куча оперативки скорости не прибавляет.
Имхо, не бывает нагруженных сайтов (> 1кк уников в сутки) на серверах с 0,5 ГБ оперативки.
0
UFO just landed and posted this here
Да, но я не столько про БД, сколько про сервера логики, где выполняется код.
Грубо говоря, php скриптов на диске может лежать на 100-200(-500?) МБ.
Естественно, они быстро окажутся в кеше файловой системы.
Ну и оперативка тратится на код скриптов во время выполнения.
Ну а дальше все.
Если сервер логики не упирался в оперативку ранее, то увеличение, скажем с 16 до 32 ГБ не даст какого-то прироста.
На серверах БД, конечно, больше оперативки позволит запихать в неё больше данных.
Про уников я писал 1кк — это 1 млн, это несколько синтетическая величина с точки зрения нагрузки, согласен.
Грубо говоря, php скриптов на диске может лежать на 100-200(-500?) МБ.
Естественно, они быстро окажутся в кеше файловой системы.
Ну и оперативка тратится на код скриптов во время выполнения.
Ну а дальше все.
Если сервер логики не упирался в оперативку ранее, то увеличение, скажем с 16 до 32 ГБ не даст какого-то прироста.
На серверах БД, конечно, больше оперативки позволит запихать в неё больше данных.
Про уников я писал 1кк — это 1 млн, это несколько синтетическая величина с точки зрения нагрузки, согласен.
0
безусловно интересные советы, спасибо.
Очень хотелось бы посмотреть как соб-но изменилась производительность «до» и «после». В идеале — при изменении каждого параметра каждого сервиса. Еще хорошо бы посмотреть как меняется load внутри системы. У вас же синтетические тесты, легко их прогнать.
Если этого нет, то неясно что мы теряем и что получаем. А интуиция при подкручивание разных опций может и обмануть.
Очень хотелось бы посмотреть как соб-но изменилась производительность «до» и «после». В идеале — при изменении каждого параметра каждого сервиса. Еще хорошо бы посмотреть как меняется load внутри системы. У вас же синтетические тесты, легко их прогнать.
Если этого нет, то неясно что мы теряем и что получаем. А интуиция при подкручивание разных опций может и обмануть.
0
А не синтетический тест провести довольно просто — давайте ссылку на Ваш сайт здесь и через часик, если все еще будете иметь доступ к нему, выкладывайте уже картинку красивую.
+16
UFO just landed and posted this here
Казалось бы при чем тут wordpress? )
Ни слова про плагин w3tc, который при правильной настройке позволяет отдавать статику напрямую через nginx. В зависимости от типа контента этот кеш может жить очень долго, единственный неприятный момент — перестанут работать счетчики просмотров постов (для некоторых актуально), лечится использованием JSON счетчиков.
Ни слова про плагин w3tc, который при правильной настройке позволяет отдавать статику напрямую через nginx. В зависимости от типа контента этот кеш может жить очень долго, единственный неприятный момент — перестанут работать счетчики просмотров постов (для некоторых актуально), лечится использованием JSON счетчиков.
0
Тепличные тесты сферического сайта в вакууме.
Blitz.io не покажет реального положения вещей, танк более-менее покажет реальную нагрузку на тестовом стенде.
У реального сайта с такой посещаемостью будут проблемы совсем другого уровня, ибо будет накручена куча модулей и корявого кода, в котором никто не шарит ибо сменилось 10 поколений разрабов. С этими проблемами в первую очередь и придется столкнуться.
Где кеширование nginx'ом, memcache, XtraDB?
С такой посещалкой экономия на сервере — глупость. Не вводите пользователей в заблуждение, доверяйте профессионалам работу с HL.
Картинка по запросу «Выдуманный Мир»
Blitz.io не покажет реального положения вещей, танк более-менее покажет реальную нагрузку на тестовом стенде.
У реального сайта с такой посещаемостью будут проблемы совсем другого уровня, ибо будет накручена куча модулей и корявого кода, в котором никто не шарит ибо сменилось 10 поколений разрабов. С этими проблемами в первую очередь и придется столкнуться.
Где кеширование nginx'ом, memcache, XtraDB?
С такой посещалкой экономия на сервере — глупость. Не вводите пользователей в заблуждение, доверяйте профессионалам работу с HL.
Картинка по запросу «Выдуманный Мир»
+2
Хм, а ради интереса можете Яндекс Танком шарахнуть по вашему ВП? У меня php-fpm + nginx держал 25 одновременных юзверей, второй тариф на ДО.
0
Оптимизация для любого веб-сервера начинается с использования nginx + php5-fpm + opcache и настройке кеширования на nginx там где только можно.
Также рекомендую больше внимания всё-таки уделить отключению лишнего в php5-fpm.
А тесты Вам стоит проводить, направив нагрузку на самые тяжелые в плане вычислений места.
Ну и конечно же, отключение логов при малейшем DDoS или попытках взлома Вам обойдутся дорого.
За статью спасибо, но если уж оптимизировать, то по максимуму.
Также рекомендую больше внимания всё-таки уделить отключению лишнего в php5-fpm.
А тесты Вам стоит проводить, направив нагрузку на самые тяжелые в плане вычислений места.
Ну и конечно же, отключение логов при малейшем DDoS или попытках взлома Вам обойдутся дорого.
За статью спасибо, но если уж оптимизировать, то по максимуму.
0
Какой смысл такого теста? До WordPress даже ничего не дошло, всё тупо из кэша отдалось. Можно и просто странички на html положить и удивляться скорости отдачи сервера за 5$.
+1
А почему в списке включенных модулей нет mod_php?
0
Тест Varnish'а получился, не?
Переходя на MyISAM помните, что выдергивание сервера из розетки с большой вероятностью даст ручное восстановление данных с потерей некоторой части оных — MyISAM не контролирует свою целостность в отличии от InnoDB. Ну транзакционная целостность… не нужна?
В Apache можете еще обработку .htaccess отключить, а вообще nginx.
Переходя на MyISAM помните, что выдергивание сервера из розетки с большой вероятностью даст ручное восстановление данных с потерей некоторой части оных — MyISAM не контролирует свою целостность в отличии от InnoDB. Ну транзакционная целостность… не нужна?
В Apache можете еще обработку .htaccess отключить, а вообще nginx.
0
может устроим такой конкурс?
0
UFO just landed and posted this here
UFO just landed and posted this here
Я думал, что будет рассказано о mod_pagespeed, есть опыт использования mod_pagespeed?
0
Хотелось бы еще увидеть сайты, которые лежат на серваке. Так как разница между корпоративной визиткой и порталом, как Вы понимаете…
0
Sign up to leave a comment.
Оптимизируем VPS за 5$ (512MB RAM / 1 CPU) так, что сайт на wordpress выдерживает нагрузку в 42,735,587 хитов в день