Открыть список
Как стать автором
Обновить

Комментарии 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

Ну и самое главное: слабым местом всегда остаётся само веб-приложение, каким бы ни был сервер…
Добавлю, что WordPress проявляет тормозность только когда он основательно набит контентом (вероятно, там есть как минимум линейная зависимость числа неких громоздких операций от количества постов и страниц), поэтому и тестирование нужно проводить при условии, что на сайте будет достаточно много контента. К тому же, наличие контента может поспособствовать тому, что слабым местом как бы внезапно станет не сервер, а интернет-подключение.
эта зависимость проявляется в запросах вида:
SELECT * FROM table LIMIT 1000, 20
А что самое прикольное — uWSGI можно настроить на использование namespaces, чтобы свести к минимуму последствия взлома какого-то vhost.
НЛО прилетело и опубликовало эту надпись здесь
Ой, а можно подробности о «фризится»? Сломал весь мозг от того, что он иногда подвисает. Как отлавливать?
НЛО прилетело и опубликовало эту надпись здесь
Форк не умирает после обработки запроса.
Один процесс может обработать несколько запросов, пока не достигнет лимита из переменной pm.max_requests.
Время исполнения скрипта в php ограничено настройками php, как и количество памяти, которое он может захавать.
При ликах памяти он просто жрет память.
Фризиться он может, если залезет в своп.
НЛО прилетело и опубликовало эту надпись здесь
Как одну из причин, замечал как «виснет» php при обращении к внешним ресурсам.
Через, 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, но это разные движки, да и любой другой так же.
Спасибо за ответ, modx конечно крут, но я больше люблю ВП :)
Кстати, кэширование на ВП легко выполняется с помощью плагинов ;)
Вменяемой, в данном контексте означало, что просто работает (как это уже второй вопрос).
НЛО прилетело и опубликовало эту надпись здесь
После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:

# service apache2 restart

Не надо рестартить сервис там, где это не нужно.
Иногда достаточно сделать reload:
service apache2 reload

Да, вы абсолютно правы! Почему в статье написал именно так, сейчас постараюсь объяснить. Был у меня один случай очень давно. Тогда настраивал apache еще под управление freebsd то ли 6.4, то ли 7.1. И долго не мог разобраться, почему измененный параметр в конфигурации веб-сервера не вступает в силу. Убил на решение проблемы порядка 5-и часов. После перезагрузил сервер и проблема решилась. Начал играться с опциями и обнаружил, что reload не перечитывает конфигурацию, а restart/stop-start выполняется успешно, причем, в логах тоже ничего не было подозрительного. С тех пор выработалась привычка, что когда что-то с нуля подымаю использую, исключительно, опцию restart, а когда в продуктивной среде необходимо что-то изменить в конфигурации на высоконагруженном проекте, то конечно же, использую reload и только reload.
apachectl для этих целей более универсальное решение.
С freebsd 6.4 много воды утекло, особенно в linux.
Но я вижу, вы в курсе насчет restart на хайлоаде :)
А что вы конкретно тестировали? Заглавную страницу веб-сервера, которая отображается по умолчанию? Судя по приведенной статистике, размер отданной страницы составил 20.69 / 28650 * 1024 ≈ 0.74 кб
Для примера, главная одного из моих сайтов генерирует следующие результаты
Скриншот
image
судя по Response Time 16-37 ms — все запросы обработал Varnish, и до апача с php дело не дошло ни разу.
НЛО прилетело и опубликовало эту надпись здесь
В последней табличке: 20 мегабайт и 28650 хитов. Это сколько отдаётся/принимается на один хит? Не слишком ли цифры далеки от реальных приложений?
Смотрю у этого blitz.io нету бесплатного плана, так бы свой не потимизированый ВП для интересу померял.
Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.

Блевать? Буэээ
nginx + php-fpm намного меньше апача будут есть
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
в статье не написано, что нельзя заменять тяжеловесные приложения более оптимальными.
п.с. как же надо ненавидеть nginx, чтоб слить мне за этот камент карму в — ;)
хабр такой хабр.
> п.с. как же надо ненавидеть nginx, чтоб слить мне за этот камент карму в — ;)

oh wait, зря я написал коммент ниже :(
<удалено во имя справедливости>
Не запускайте 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/
Забыл сказать про кеширование на уровне веб сервера.
Если у вас не особо динамичный сайт, nginx + fastcgi_cache разгонят его до скорости отдачи простой статики.
Да с этого, по сути, надо было начинать, в свете перехода на майисам
А что за хостер? И какие диски на вашем ВПС?
Zend Opcache вошел в код Php 5.5 который на тестах лучшее APC

Не подскажете, нет ли для него удобной веб-морды как у APC чтобы мониторить попадания в кэш?
Благодарю. Как раз то что нужно!
А, это синтетические тесты. Я то уж подумал что у вас реально 40M хитов в день и все это как то живет на слабенькой VPS, а владелец сайта настолько жмется =)

Ради интереса проделывал похожие вещи на еще более слабой VPS, но там я сразу отказался от Apache поставив вместо него nginx и скомпилировав на той же машине php 5.7
По сути подобные тесты будут показывать довольно высокую производительность когда все запросы падают на одну страничку и совершенно другая картина будет с реальными пользователями. В случае с плагинами типа W3 cache или надстройками типа Varnish то настройки php и mysql вообще на тест влиять не будут т.к. сервер будет тупо отдавать статичную страничку.
Советуете переделать InnoDB в MyIsam???!!!
Ага, скриптом их всех. Ну, там foreign key да триггеры пропали, пофиг.
А что с триггерами в myisam?
Я использую триггеры в myisam.
В некоторых случаях myisam работает значительно быстрее, чем InnoDB.
Тут я подумал, что автор знает, что MyISAM использует меньше памяти.
НЛО прилетело и опубликовало эту надпись здесь
Как только не изощряются люди, лишь бы nginx + php-fpm не использовать. :)
Over 400 RPS на WordPress. Шикарно. На каком контенте и запросах? Допустим, страница статьи с деревом комментариев на 300 штук различной вложенности, которые периодически пополняются. Тоже > 400 rps держит? Было бы прекрасно, но верится с трудом.
Да там slowest request 37ms, весь тест на 100% в кеш попадал, никакого wp/apache/mysql.
О том и речь. Самый простой способ раскачать wordpress — отключить wp/apache/mysql
А в чем сложность дерева комментариев на 300 запросов? 1 запрос к БД с выборкой по индексу.
PS. например алгоритм nested sets
НЛО прилетело и опубликовало эту надпись здесь
еще можно в my.cnf

thread_cache = 5

# Query Cache Configuration
query_cache_limit = 4M
query_cache_min_res_unit = 8
query_cache_size = 8M
query_cache_type = 1

будет кешировать запросы и держать несколько тредов префоркнутыми
НЛО прилетело и опубликовало эту надпись здесь
Да обычно все сводится к банальному кешированию.
redis, memcache, proxy_cache, fastcgi_cache.
НЛО прилетело и опубликовало эту надпись здесь
На 512 — гуляй не хочу
вот на 128 все гораздо веселее…
Имею десятка полтора слабеньких VPS под 256 МБ ОЗУ. Для большинства клиентов хватает с головой. Но вот как поместиться на 128 МБ представляю с трудом. Там ведь никакого резерва не будет. Разве что заранее решить, что ничего кроме статики :)
Раньше vdsplanet по тарифу луна (сейчас у них минимум 256) выдавали 128 оперативки.
Разумеется никакого резерва не было, но хотелось покрасноглазить и запустить.
Сервером понятное дело nginx, для mysql выставил все размеры по 4 метра — на дефолтных настройках ее убивало при старте. PHP вместо fpm использовал php-cgi -b и скрипт в кроне проверки наличия процесса.
Собственно все — в таком состоянии легкие динамические запросы отрабатывались, даже хватало на второй запуск php по крону, правда во время выполнения крона по ssh зайти было нельзя :)
Еще пришлось очень весело генерить локали — sshfs + chroot
Не, не при такой конфигурации естественно.
На действительно нагруженных сайтах все ок с оперативкой, но сама по себе куча оперативки скорости не прибавляет.
Имхо, не бывает нагруженных сайтов (> 1кк уников в сутки) на серверах с 0,5 ГБ оперативки.
НЛО прилетело и опубликовало эту надпись здесь
Да, но я не столько про БД, сколько про сервера логики, где выполняется код.
Грубо говоря, php скриптов на диске может лежать на 100-200(-500?) МБ.
Естественно, они быстро окажутся в кеше файловой системы.
Ну и оперативка тратится на код скриптов во время выполнения.
Ну а дальше все.
Если сервер логики не упирался в оперативку ранее, то увеличение, скажем с 16 до 32 ГБ не даст какого-то прироста.
На серверах БД, конечно, больше оперативки позволит запихать в неё больше данных.
Про уников я писал 1кк — это 1 млн, это несколько синтетическая величина с точки зрения нагрузки, согласен.
безусловно интересные советы, спасибо.

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

Если этого нет, то неясно что мы теряем и что получаем. А интуиция при подкручивание разных опций может и обмануть.
А не синтетический тест провести довольно просто — давайте ссылку на Ваш сайт здесь и через часик, если все еще будете иметь доступ к нему, выкладывайте уже картинку красивую.
НЛО прилетело и опубликовало эту надпись здесь
Казалось бы при чем тут wordpress? )
Ни слова про плагин w3tc, который при правильной настройке позволяет отдавать статику напрямую через nginx. В зависимости от типа контента этот кеш может жить очень долго, единственный неприятный момент — перестанут работать счетчики просмотров постов (для некоторых актуально), лечится использованием JSON счетчиков.
Тепличные тесты сферического сайта в вакууме.
Blitz.io не покажет реального положения вещей, танк более-менее покажет реальную нагрузку на тестовом стенде.
У реального сайта с такой посещаемостью будут проблемы совсем другого уровня, ибо будет накручена куча модулей и корявого кода, в котором никто не шарит ибо сменилось 10 поколений разрабов. С этими проблемами в первую очередь и придется столкнуться.
Где кеширование nginx'ом, memcache, XtraDB?

С такой посещалкой экономия на сервере — глупость. Не вводите пользователей в заблуждение, доверяйте профессионалам работу с HL.
Картинка по запросу «Выдуманный Мир»
image
Хм, а ради интереса можете Яндекс Танком шарахнуть по вашему ВП? У меня php-fpm + nginx держал 25 одновременных юзверей, второй тариф на ДО.
Оптимизация для любого веб-сервера начинается с использования nginx + php5-fpm + opcache и настройке кеширования на nginx там где только можно.
Также рекомендую больше внимания всё-таки уделить отключению лишнего в php5-fpm.
А тесты Вам стоит проводить, направив нагрузку на самые тяжелые в плане вычислений места.
Ну и конечно же, отключение логов при малейшем DDoS или попытках взлома Вам обойдутся дорого.

За статью спасибо, но если уж оптимизировать, то по максимуму.
Какой смысл такого теста? До WordPress даже ничего не дошло, всё тупо из кэша отдалось. Можно и просто странички на html положить и удивляться скорости отдачи сервера за 5$.
А почему в списке включенных модулей нет mod_php?
Тест Varnish'а получился, не?
Переходя на MyISAM помните, что выдергивание сервера из розетки с большой вероятностью даст ручное восстановление данных с потерей некоторой части оных — MyISAM не контролирует свою целостность в отличии от InnoDB. Ну транзакционная целостность… не нужна?
В Apache можете еще обработку .htaccess отключить, а вообще nginx.
может устроим такой конкурс?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я думал, что будет рассказано о mod_pagespeed, есть опыт использования mod_pagespeed?
При разработке софта может быть полезен. А так, только увеличивает время генерации страницы. На High-load проектах увеличивает очень сильно.
Хотелось бы еще увидеть сайты, которые лежат на серваке. Так как разница между корпоративной визиткой и порталом, как Вы понимаете…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.