Скорости работы ЛС vs Конфигурация сервера

Здравствуйте уважаемые знатоки. перечитал весь сайт по тегам «скорость и livestreet»
Но ситуация вынудила меня поднять эту тему снова.
На пустом сервере с включенным мемкешем и всяческими оптимизациями движка найденными на просторах этого сайта загрузка 1-й страницы занимает 0.5-0.6сек и выглядит следующим образом:

Раз:

Два:


Теперь если в онлайне будут постоянно 30-40чел то скорость работы проседает до 0.9-1сек
Раз:

Два:


Теперь собственно вопрос. Что и где надо увеличить для того чтобы
1. Скорость загрузки первой страницы уменьшилась до приемлемых для клиента 0.2сек
2. Скорость не проседала более чем до 0.5сек при онлайне в 40-50чел.

Ну и вопрос номер 2.
Поделитесь пожалуйста у кого какая конфигурация сервера\сколько людей держит в онлайне и какой отклик при загрузке в первой страницы, чтоб можно было аргументировать увеличение количества процессоров\ОЗУ\ДИСКА и т.д.
Заранее благодарен

52 комментария

avatar
Как настраивать? — любой приём оптимизации работающий для PHP и/или веб сайта, работает и для LS, и тут нет никаких особых секретов:
1. используйтe nginx
2. используйте кэширование данных в памяти (memcached, а лучше XCache), и не используете file caching
3. используйте как можно более свежую, стабильную версию PHP
4. используйте php-fpm
5. используйте php opt-cacher (в PHP 5.5 оно уже встроено, для более старых версий есть APC или тот же XCache)
6. Тюнинг файловой системы (noatime, tmpfs для всяких «временных» файлов/папок и прочие трюки)
7. Тюнинг MySQL (Тут огромное поле для оптимизаций, начиная с того что можно пробовать собственно не с MySQL, а продвинутыми «форками» (Percona или MariaDB). Грамотной настройкой многие операции с базой можно ускорить в разы )

Подчеркну, что всё вышеперечисленное справедливо для любого PHP приложения, LS не является чем-то уникальным.

Ну и особо отмечу — вообще не связывайтесь с «шаред» хостингом, и по возможности не связывайтесь с VPS. Первое вообще не предсказуемо и не оптимизируемо. Второе — относительно.

Скорость LS зависит главным образом от количества комментариев у топика. Т.е. страница топика с большим количеством комментариев (несколько сотен) — это единственная проблема. Чем больше комментариев тем дольше будет генерироваться страница и сделать с этим ничего нельзя.

Все остальные типы страницы можно вогнать в стабильное время. Т.е. главная или всякие разные списки генерируются, в принципе, с одинаковой примерно константной скоростью.
avatar
Сразу ставлю плюс за такой полный ответ НО:
1. nginx — используется (с senfile-ами, gzip_static-ами и т.д.) а последний месяц картинки все идут на амазон
2.
используйте кэширование данных в памяти (memcached, а лучше XCache), и не используете file caching
memcache — используется. по поводу xcache — писали что он не очень стабилен. Как вы смотрите на это утверждение
3. PHP Version 5.3.3-7+squeeze13
4. используйте php-fpm
вот это еще не пробовал. Вы предлагаете обойтись без апача вообще? или через апач fastcgi использовать?
5. используйте php opt-cacher (в PHP 5.5 оно уже встроено, для более старых версий есть APC или тот же XCache)
APC используется
6. Тюнинг файловой системы (noatime, tmpfs для всяких «временных» файлов/папок и прочие трюки)
Насколько это будет ефективным на Xen-овской VPS-ке?
avatar
php-fpm это фундаментальный прирост скорости, особенно под нагрузкой. Apache (mpm-worker + fastcgi + php+fpm) или nginx напрямую — не столь важно, дело вкуса. Второе, однако, в теории быстрее.

тюнинг файловой системы всегда имеет смысл. В конце концов веб сайт — это огромное количество работы с файлами и если вы научите свой сервер быстрее и эффективнее работать с файлами вы выиграете во всех аспектах. И VPS или нет — вопрос второй. Поле для деятельности там большое, начиная с выбора файловой системы там же есть не только ext4, но, например, XFS или Reiser4 — интересные штуки. Ну а использовать оперативную память для временных фалйов (tmpfs) это очевидно отличная идея, если память есть. А временные файлы активно создаются и nginx-ом и MySQL-ом и даже, самим LS. Однако, игры с файловой системой требуют определенной, админской квалификации.
avatar
memcache — используется. по поводу xcache — писали что он не очень стабилен. Как вы смотрите на это утверждение
xcache действительно менее стабилен, но проявляется это в достаточно малом количестве случаев. С другой стороны как «кешер» данных он очень существенно быстрее memcached — выигрыш в 10-ки процентов производительности. Мораль из этого такая — пробовать XCache, и если работает без проблем — на нем и оставаться.
avatar
поддержу уже поставил и тестю
avatar
Gmugra а вот насчет перехода с php 5.3 на более новые версии что нибудь посоветуете? Я имею ввиду переходить на 5.4 или может лучше сразу на 5.5?
avatar
С 5.3 надо уходить однозначно — эта версия официально мертва. тут сомнений нет. Я лично перевел наш сервер пока на 5.4, ибо это тупо проще :) — В 5.5 с opt cacher новым надо разбираться, как минимум, а мне пока что лень :)
avatar
Итак, после 3-х часов експериментов
php5-fpm не сильно увеличил производительность
где-то на 20-30%
Но СИЛЬНО помог(0.1-0.2сек) nginx fastcgi_cache настроенный по ману: habrahabr.ru/post/71501/
но пока на боевой сервер не ставил… еще експериментирую
avatar
20-30% — это, простите, дофига. :) И надо держать в уме, что с php5-fpm выигрыш тем больше, чем больше нагрузки на сервер. В силу природы fast cgi.

Кеширование nginx-а штука классная, но там море тонкостей, осторожно с этим — много тестить под разными пользователями. И внимание — там tmpfs для fastcgi_temp_path настроить — святое дело.
avatar
С разными юзерами по тому мануалу в принципе проблем быть не может. Только сомнительна польза в некоторых случаях.
avatar
Сомнительна польза в целом. ну т.е. оно работает — да, но у каждой сессии свой кеш. Ну т.е. мне кажется, не особенно эффективно оно. Конвершн рейт в среднем-то несколько страниц на юника, т.е. средняя эффективность кеша будет по идее очень низкой. Вот если бы все не залогиненные пользователи один и тот же кеш использовали — тогда был бы эффект ого-го… а так… смысла imho не очень много.
avatar
Хорошо но если у меня на проекте 90% анонимусов?
avatar
Как вариант, сделать хук или плагин выставляющий куку is_loggedin=1 — для всех залогенных, а для всех остальных is_loggedin=0.
Далее на nginx по этой куке в map смотреть, подставлять ли в качестве ключа (fastcgi_cache_key) строку с sessionid или без.
Не знаю, на сколько верным будет данное решение. Нок как вариант.
avatar
вот какраз над этим и думаю
avatar
Я не очень представляю: а можно ли так конфигурацию для nginx сделать, чтобы кешировало только те запросы у которых только вот твкой «is_loggedin=0» в куках ( и без разницы какая сессия )? — тогда вот, мне кажется, взлетит как надо.
avatar
Думаю можно
avatar
Можно.
avatar
Ну тогда, осталось только плагинчик «Microcache Ready» написать. Полезно получится весьма :)
avatar
ага думаю над этим. Но вопрос в другом. Кеш то какбы обновлять надо. Вот где проблема
avatar
Кеш то какбы обновлять надо. Вот где проблема
Зачем? Он валидный несколько секунд (в примера с хабра — 10 сек). Если вы кешируете контент только для не залогиненых, то что там для них критического может за 10 сек изменится? — Да ничего.
avatar
С кэшами вообще забавно. Дизайнеров послушайте и становится грустно. Там где динамика — закэшировано так что не сотрешь. А в футере где могла быть одна статика по хорошему всей динамики раз в год когда бьют куранты на сервере — чутко мгновенно отражаются все правки. Я к тому, что присмотритесь к своим темплейтам.
avatar
Бляха кеш не хочет писаться :(
avatar
Итак, после нескольких часов мытарств результат пока удовлетворяет
1. Кешируется для каждого пользователя отдельно в т.ч залогиненого
2. Нормально работает вход\выход пользователя и можно ставить кеш не 10сек как в статье на хабре, а сколько угодно (требует доп.тестов)
Теперь думаю над принудительной очисткой кеша т.к. если он будет жит 2-3 или даже 24часа то надо будет принудительно чистить. Пока что конфиг такой:
<------>if ($request_uri ~* ".*kcaptcha.*" ) {
<------><------>set $skip_cache 1;
<------>}

<------>if ($request_uri ~* "/login/|/logout/|/ajax/|/kcaptcha/|/ajax-login|/topic/|/event/|/photoset/|/link/"){
<------><------>set $skip_cache 1;
<------>}

<------>location ~ \.php$ {

#<-----><------>add_header "X-Debug-cachekey"  $request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid;
#<-----><------>add_header "X-Debug-skipcache" $skip_cache;
<------><------>fastcgi_index index.php;
<------><------>fastcgi_pass 127.0.0.1:9000;
<------><------>fastcgi_cache_bypass $skip_cache;
<------><------>fastcgi_cache gk;
<------><------>fastcgi_cache_valid 200 301 302 304 30s;
<------><------>fastcgi_cache_min_uses 1;
<------><------>#fastcgi_hide_header "Set-Cookie";
<------><------>fastcgi_pass_header Cookie;
<------><------>fastcgi_ignore_headers "Cache-Control" "Expires" "Set-Cookie";
<------><------>fastcgi_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri|$cookie_key|$cookie_phpsessid";

<------><------>include fastcgi_params;

<------><------>fastcgi_param  DOCUMENT_ROOT    $document_root;
<------><------>fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
<------><------>fastcgi_param  PATH_TRANSLATED  $document_root$fastcgi_script_name;
<------><------>fastcgi_param  PATH_INFO        $fastcgi_path_info;
<------><------>fastcgi_param  QUERY_STRING     $query_string;
<------><------>fastcgi_param  REQUEST_METHOD   $request_method;
<------><------>fastcgi_param  CONTENT_TYPE     $content_type;
<------><------>fastcgi_param  CONTENT_LENGTH   $content_length;
<------><------>fastcgi_intercept_errors        on;
<------><------>fastcgi_ignore_client_abort     off;
<------><------>fastcgi_connect_timeout 60;
<------><------>fastcgi_send_timeout 180;
<------><------>fastcgi_read_timeout 180;
<------><------>fastcgi_buffer_size 128k;
<------><------>fastcgi_buffers 4 256k;
<------><------>fastcgi_busy_buffers_size 256k;
<------><------>fastcgi_temp_file_write_size 256k;

<------>}

avatar
Ещё раз, не стоит в cachekey подсовывать $cookie_phpsessid. Это сильно убивает смысл использования кеша.
avatar
надо будет посмотреть что с капчей тогда будет. она же вроде в эту ессию пишется
avatar
Ну и да, раз вы для дебага делаете заголовки, вам ещё пригодится наверно:
add_header X-Cache-Status $upstream_cache_status;
avatar
Ну и увеличение времени кеширования тоже идея плохая — изменений никто же видеть не будет. Представьте ситуацию когда у вас, скажем, новый комментарий к какой-то заметке появляется каждую минуту, а заметка с комментариями в кеше на 24 часа — это как то не очень хорошо, мягко говоря.
avatar
Правильно поэтому я ж и написал
Теперь думаю над принудительной очисткой кеша
avatar
Ну есть, например, модуль ngx_cache_purge для этого. Но с моей точки зрения это изврат. Чем 10 сек не устраивают? — при высокой нагрузке это проблему решит, при низкой нагрузке это вообще и не надо особо должно быть. Как-то так.
avatar
Ну есть, например, модуль ngx_cache_purge для этого.
знаю но его нет в стандартной сборке
avatar
ну, дык. в стандартной сборке много чего нет. и много чего лишнего. пересобирать надо, да :)
avatar
в принципе лучше конечно написать кешер самому чтоб он так как и в ЛСе по тегам дропал ресурсы…
а кстати @Gmugra. Может ответите на 2-ю половину моего вопроса?
Поделитесь пожалуйста у кого какая конфигурация сервера\сколько людей держит в онлайне и какой отклик при загрузке в первой страницы, чтоб можно было аргументировать увеличение количества процессоров\ОЗУ\ДИСКА и т.д.
можно в личку если что
avatar
в принципе лучше конечно написать кешер самому чтоб он так как и в ЛСе по тегам дропал ресурсы…
Точно не лучше. Nginx уж очень крут. Вообще, на данный момент, верно утверждение «всё что можно сделать nginx-ом, должно быть сделано nginx-ом».
avatar
Поделитесь пожалуйста у кого какая конфигурация сервера\сколько людей держит в онлайне и какой отклик при загрузке в первой страницы, чтоб можно было аргументировать увеличение количества процессоров\ОЗУ\ДИСКА и т.д.
У нас физический сервер — CPU Intel I7-2600 Quadcore, 16GB, 2 x 3 TB SATA 6 Gb/s HDD 7200 rpm (Software-RAID 1).

На сервере только один сайт на LS (1.0.3, 16 плагинов, шаблон основанный на Synio )

Генерация главной 0.15-0.25. Генерация топика с 200 комментариями — 0.45. Сервер загружен, в среднем, на 2% по CPU и на 20% по памяти.

Софт: nginx, Percona, apachе+php-fpm, PHP 5.4, memcached, APC

кешинг nginx не используем.

Нагрузки озвучить не могу, но скажем так — средненько.

На самом деле, у нас не в полной мере идеально, многое можно было бы ещё оптимизировать, но, честно говоря, оно и так летает. Большой нужды что-то сильно менять пока нет.
avatar
Нагрузки озвучить не могу, но скажем так — средненько.
В онлайне больше 100 людей или меньше?
avatar
что имеется в виду под человеком в онлайне?
avatar
avatar
Понятно. Нельзя мне разглашать эту информацию, извините :)
avatar
Это понятно просто скажите больше 100 или меньше 100
avatar
иногда — больше. иногда — нет. зависит от времени суток и того что происходит на сайте. в среднем, наверное, меньше.
avatar
Спасибо это я и хотел услышать
avatar
Точно не лучше. Nginx уж очень крут. Вообще, на данный момент, верно утверждение «всё что можно сделать nginx-ом, должно быть сделано nginx-ом».
я ме в виду модуль кеширования дл джинкса. А с Вашим утверждением я полностью согласен.
avatar
Извиняюсь, что встрял в ваш разговор.
Выбирая сервер для совсем домашней LS я по вашему доброму совету поменял апача на nginx и не нарадуюсь. Спасибо за совет. Без всяких там настроек и адаптаций я теперь в упор не вижу что бы он проседал даже в пиковые часы до 12 % чпу и 18 памяти :) фантастика1
avatar
Дык никто ж и не спорит что nginx в этом случае какраз то что надо. Вопрос в цифрах 0.2сек
avatar
спорить и не будем.Против цифры не попрешь. Просто мого- много лет я не заморачивался с серваками и nginx стал для меня приятным открытием. Еще раз спасибо. И по поводу цифорок… У меня физически все это хозяйство крутится на планшетке с треснутым экраном 4 ядра 1.2 гц 1гиг рама. Цифры на выходе приблизительно как у вас и нагрузки особой нет в плане посетителей и загрузки проц и памяти. Нет времени чтот ковырять и тестировать. Но вопросом, что будет если посетители попрут я озадачился и смоделлировал это дело банальным до безобразия способом а именно стал грабить свою ЛСку парсерами изображая бурную акивность посетителей… В результате нашёл то, из-за чего огорчился livestreet.ru/blog/bugreport/16383.html местный авторитет, но сервак практически не сильно проседает под нагрузкой если не идет активная запись в базу… а посколку читателей всегда больше, чем писателей, я успокоился. Для практических нужд за глаза хватает.
avatar
физически… на планшетке с треснутым экраном 4 ядра 1.2 гц 1гиг рама.
Т.е. у вас сервер на планшете?
avatar
:) угу. Тормоза только при обращении к одному из старых насов где в основном домашний видиоархив.
одбираю сейчас новые винты чтобы быстрые но тихие.
До завтра. пошел спать
avatar
винты для планшета? :)
avatar
:)))) было бы здорово!!! Но к сожалению нет. винты для этого старья без поддержки гигабитного etherneta где у меня поначалу ютилась лс на usb медиаплеер abigs с гигабитом. Винты для них. )
avatar
Базу тоже очень сильно можно «пнуть». MySQL с параметрами по умолчанию работает медленно. но очень надежно. но медленно. А надежность такая не нужна для CMS. Много там можно сделать. много. :)
avatar
Я смотрел вашу школу по базам, достойно похвалы…
Каждый смотрит на проблему под углом своей профессиональной рефлексии. А вот взгляда с точки зрения программирования интерфейса я пока не нашёл. Все шкурки построены «на базе..» там есть простор для тюнинга
★ писал и публиковал wordpress api для android
avatar
У меня переход с одного VPS на аналогичный сервер, но с дисками SSD, увеличил скорость генерации страниц почти в 2 раза (с 400 мс до 250 мс). Остальные параметры сервера примерно такие же, как на пред. сервере, разве что оперативки побольше, но это не играет особой роли.
На серверах в обоих случаях стоит Debian 7, Apache + fastcgi + php+fpm + nginx, БД Percona, PHP 5.4, xCache
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.