Ускорение сайта на Drupal 7

Главные вкладки

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 2:13

Сайт на Drupal 7.20 не очень посещаемый около 700 посетителей в сутки, кол-во страниц 25 000, база около 500мб, дисковое занято около 2гб.
Для кеширования статики используется модуль: Boost (сброс html/javascript кэша каждые 12 часов)

Хостинг предоставляет: 1024 мб физической памяти, 2048 мб виртуальной памяти, CPU 600 MHZ (1/4 от ядра 2400 MHZ), дисковая квота 10 гб, лимит 20 входящих процессов.

Если запустить тест нагрузки на сайт в 50 одновременных посетителей: http://loadimpact.com/
То сайт становится недоступен, все показатели памяти физической/виртуальной/CPU близки к 100%, и это уже на 35 одновременных посетителях.

Если проверить главную страницу сайта: http://gtmetrix.com/
Page load time: 3.20s
Total page size: 175KB
Total number of requests: 41
Уровень оптимизации: 84%/90%

(опытным путём установлено в php.ini памяти 190 мб, время исполнения php 40 секунд, если меньше чтобы подвисшие php процессы автоматом завершались, на завершение и новое открытие тратиться больше памяти, а если больше то уже при 190 мб, каждый процесс занимает около 300 мб вирт.памяти и 5-6 процесов подвешивают сайт)

Подскажите как можно улучшить производительность сайта, его выносливость, чтобы сайт не уходил в offline ???

Комментарии

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 12:42

Модулей включено 154 из 208 установленных.
Типов материалов: 15
Полей (если смотреть список полей: /admin/reports/fields): 42

APC пробовал, он замедлял работу сайта, в итоге его отключили по моей просьбе для моего аккаунта на сервере и на уровне CMS был удалён, после этого сайт стал быстрее работать.

Данные сервера:
Cpanel: 11.32.2
Apache: 2.2.22
PHP: 5.3.13
MySQL: 5.1.63
Perl: 5.10.1
CloudLinux: 6.3
PHP скрипты запускаются как FastCGI

p.s. На всех страницах сайта используются блоки вывода случайных материалов (views), которых всего 5. Наверняка это создаёт львиную нагрузку на базу данных, но для сайта очень важное значение имеет вывод на каждой странице разных материалов...

Аватар пользователя bismigalis bismigalis 14 марта 2013 в 13:49

>На всех страницах сайта используются блоки вывода случайных материалов (views), которых всего 5
чо за вьюхи, какие запросы делаются? может индексы надо в базе поставить

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 14:01

Представления используются следующие:
1. Случайный вывод цитаты (только блок)
2. Случайный вывод 3-х анонсов статей: картинка + заголовок + 200 знаков содержимого (блок + ссылка на каталог статей)
3. Случайный вывод 5-ти анонсов видео галерей: заголовок + 200 знаков текста (только блок)
4. Случайный вывод 3-х анонсов опубликованных текстов (книг, 1 уровень подшивки): заголовок + картинка + 200 знаков текста (блок + ссылка на каталог книг)
5. Случайный вывод 5-ти анонсов опубликованных текстов (книг, 2-3 уровень подшивки): заголовок + 200 знаков текста (только блок)
6. Статичный вывод 5-ти последних опубликованных на сайте материалов: заголовок + 200 знаков текста (блок + ссылка на каталог материалов).

Соответственное вывод в блоки производится в основном по типу материала: цитаты, статьи, видео галереи, книги, все материалы.
Блоки расположены слева, справа и снизу под содержимым страницы.

Можно подробнее что за индексы и как их поставить и к чему это может привести?

Аватар пользователя natbampo natbampo 14 марта 2013 в 14:32

"astrameridian" wrote:
Можно подробнее что за индексы и как их поставить и к чему это может привести?

да, это к специалистам вам надо обращаться, если вы совсем не в теме такого.

Аватар пользователя astrameridian astrameridian 10 ноября 2015 в 11:49

Вывожу данные Devel при загрузке главной страницы сайта (топ 19 по использованию процессора/памяти), подскажите что они означают, и можно ли на их основе сделать что-то для повышения производительности?

Executed 379 queries in 436.18 ms. Queries exceeding 5 ms are highlighted. Page execution time was 3297.09 ms. XHProf output. Memory used at: devel_boot()=6.43 MB, devel_shutdown()=82.18 MB, PHP peak=98.5 MB.

Function Name Calls Incl. Wall Time IWall% Excl. Wall Time Incl. CPU ICpu% Incl. IMemUse% Incl. IPeakMemUse%
(microsec) (microsec) (microsecs) MemUse PeakMemUse
(bytes) (bytes)
main() 1 2,529,929 100.0% 359 1,483,775 100.0% 78,469,720 100.0% 95,663,576 100.0%
menu_execute_active_handler 1 2,175,083 86.0% 23 1,194,819 80.5% 35,708,432 45.5% 53,016,672 55.4%
drupal_deliver_page 1 2,107,103 83.3% 11 1,143,826 77.1% 30,113,144 38.4% 47,389,288 49.5%
boost_deliver_html_page 1 2,107,039 83.3% 14 1,143,826 77.1% 30,104,872 38.4% 47,388,416 49.5%
drupal_deliver_html_page 1 2,107,023 83.3% 44 1,143,826 77.1% 30,102,088 38.4% 47,387,744 49.5%
drupal_render_page 1 2,106,205 83.3% 85 1,142,826 77.0% 30,093,112 38.3% 47,378,720 49.5%
call_user_func_array 135 1,849,243 73.1% 897 930,86 62.7% 37,713,280 48.1% 58,507,800 61.2%
block_page_build 1 1,729,578 68.4% 93 838,872 56.5% 24,331,080 31.0% 46,940,040 49.1%
block_get_blocks_by_region 20 1,729,214 68.4% 110 838,872 56.5% 24,335,464 31.0% 46,940,040 49.1%
block_list 20 1,728,909 68.3% 137 838,872 56.5% 24,288,680 31.0% 46,940,040 49.1%
_block_render_blocks 6 1,725,099 68.2% 947 834,873 56.3% 24,169,976 30.8% 46,786,856 48.9%
module_invoke 49 1,724,043 68.1% 554 832,874 56.1% 24,447,016 31.2% 46,927,544 49.1%
views_block_view 7 1,444,740 57.1% 363 566,915 38.2% 21,314,128 27.2% 15,960,944 16.7%
view::execute_display 6 1,321,172 52.2% 159 471,928 31.8% 10,714,384 13.7% 6,434,448 6.7%
views_plugin_display_block::execute 6 1,266,344 50.1% 126 419,935 28.3% 7,123,936 9.1% 3,395,824 3.5%
view::render 6 1,264,890 50.0% 909 419,935 28.3% 7,114,320 9.1% 3,395,824 3.5%
view::execute 6 1,111,205 43.9% 363 304,954 20.6% 6,060,048 7.7% 2,593,024 2.7%
cache_set 17 740,514 29.3% 189 55,993 3.8% 2,293,320 2.9% 691,264 0.7%
DrupalDatabaseCache::set 17 740,259 29.3% 646 55,993 3.8% 2,289,424 2.9% 691,264 0.7%

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 15:06

Может можно как то представления сделать кешированными, например чтобы на всех страницах было разное содержимое (эффект случайного вывода), но при обновлении этой же страницы показывалось то же самое.

Реально ли такое сделать, и если да, то как реализовать?

Аватар пользователя chilic chilic 14 марта 2013 в 15:39

"astrameridian" wrote:
APC пробовал, он замедлял работу сайта

Акселератор для php просто необходим, при правильной настройке он не замедляет работу, а даёт прирост.
В разных случаях по разному, однако факт: увеличится скорость работы php, уменьшиться потребление памяти php.

"astrameridian" wrote:
PHP скрипты запускаются как FastCGI

Спорный момент в связке с apache, лучше использовать mod_php. ИМХО.

"astrameridian" wrote:
На всех страницах сайта используются блоки вывода случайных материалов (views)

Если нет возможности отказаться от них, тогда закэшировать.

Проверьте модули apache, включен ли expires?
Возможно ли для статики поставить nginx?

Установка и настройка opcode-кэша, даст Вам хотя-бы вздохнуть спокойно.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 16:34

"astrameridian" wrote:
На всех страницах сайта используются блоки вывода случайных материалов (views)

Если нет возможности отказаться от них, тогда закэшировать.[/quote]

Каким образом правильно закешировать?
Через вьюс, установив время кеширования представлений? Как то пробовал устанавливать, но база слишком разрасталась, +3 ГБ в сутки!
Там есть параметр мин.и макс., может быть что-то типа мин.=0, макс.=1 час ?

Пробовал модуль alter block cache, но эффекта от его работы не было, при обновлении страниц каждый раз показывался новый контент в блоках вывода случайных материалов...

Или речь идёт о другом виде кеширования?

Аватар пользователя chilic chilic 14 марта 2013 в 15:47

Так же замечу, при правильно настроенном модуле Boost, большая часть запросов не должна доходить до php.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 16:02

chilic wrote:
Так же замечу, при правильно настроенном модуле Boost, большая часть запросов не должна доходить до php.

Просмотрите плиз, насколько данная настройка сгенерированных правил Boost для .htaccess правильная?

### BOOST START ###

# Allow for alt paths to be set via htaccess rules; allows for cached variants (future mobile support)
RewriteRule .* - [E=boostpath:normal]

# Caching for anonymous users
# Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server
RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add|comment/reply))|(/(edit|user|user/(login|password|register))$) [OR]
RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule .* - [S=7]

# GZIP
RewriteCond %{HTTP:Accept-encoding} !gzip
RewriteRule .* - [S=3]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html,E=no-gzip:1]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.xml -s
RewriteRule .* cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.xml [L,T=text/xml,E=no-gzip:1]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.json -s
RewriteRule .* cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript,E=no-gzip:1]

# NORMAL
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.html -s
RewriteRule .* cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.xml -s
RewriteRule .* cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.xml [L,T=text/xml]
RewriteCond %{DOCUMENT_ROOT}/cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.json -s
RewriteRule .* cache/%{ENV:boostpath}/www.yandex.ru%{REQUEST_URI}_%{QUERY_STRING}\.json [L,T=text/javascript]

### BOOST END ###

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 16:12

chilic wrote:
Так же замечу, при правильно настроенном модуле Boost, большая часть запросов не должна доходить до php.

Также в настройках BOOST:
1. Cache specific pages: Все страницы, кроме перечисленных: admin/*
2. BOOST CACHE TYPE SETTINGS (расширение, макс и мин время жизни кэша, :
TEXT/HTML, расширение: html, 12 часов/0 сек.,
TEXT/XML, расширение: xml, 5 дней/ 0 сек.,
APPLICATION/XML, расширение: xml, 5 дней/ 0 сек.,
APPLICATION/RSS, расширение: xml, 5 дней/ 0 сек.,
APPLICATION/RSS+XML, расширение: xml, 5 дней/ 0 сек.,
TEXT/JAVASCRIPT, расширение: json, 1 час/0 сек.

Также в настройках CACHE EXPIRATION стоят обе галочки:
1. Игнорировать команду очистки кэша, созданную кроном.
2. Remove old cache files on cron.

Других настроек вроде нету.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 15:56

Так как хостинг виртуальный, врят ли я могу что-то на уровне сервера делать. Насколько я знаю от хостера, используется связка Apache + Nginx.

APC тормозил возможно потому, что для вывода странички требуется (чтобы сайт работал без предупреждений типа "не хватает столько то мб для загрузки такого-то модуля или процесса") около 190 мб, а APC установленный на сервере максимум 50 мб принимал на себя.

В своё время хостер говорил, что если бы php процессы удалялись по крону, например каждые 5 минут, то всё было бы ок, но так как используется fastCGI и права у пользователя недостаточные чтобы запускать по крону kill all php, то пришлось управлять этим параметром только через php.ini снижением времени до 40 сек., через которые PHP процессы должны автоматически завершаться.

По поводу expires. Если смотреть phpinfo, то там в разделе session есть параметр: session.cache_expire 180 180
больше упоминаний данного термина в phpinfo нет.

Аватар пользователя chilic chilic 14 марта 2013 в 15:58

"astrameridian" wrote:
В своё время хостер говорил, что если бы php процессы удалялись по крону

Меняйте хостера.

Аватар пользователя chilic chilic 14 марта 2013 в 16:06

Boost генерирует правила правильно. Вы добавили их в файл .htaccess?
Так же в настройках буста есть опция для отладки. т.е. буст может добавить либо заголовок, либо скрытый текст в конец страницы, о том что он отработал правильно.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 16:14

chilic wrote:
Boost генерирует правила правильно. Вы добавили их в файл .htaccess?
Так же в настройках буста есть опция для отладки. т.е. буст может добавить либо заголовок, либо скрытый текст в конец страницы, о том что он отработал правильно.

Конечно добавил в .htaccess

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 16:20

chilic wrote:
Так же в настройках буста есть опция для отладки. т.е. буст может добавить либо заголовок, либо скрытый текст в конец страницы, о том что он отработал правильно.

Включил режим отладки, пишет в лог, если посмотреть, то в конце лога есть такие строчки:

[menu_item] => Array
(
[page_type] =>
[page_id] =>
[status] => 404
[extra_arguments] =>
)

[is_cacheable] => 1
[cache_this] =>
)

Правильно ли я понимаю что главное здесь параметр: is_cacheable =1, и он означает что кеширование работает?

Аватар пользователя q2_faith q2_faith 14 марта 2013 в 16:07

"astrameridian" wrote:
а APC установленный на сервере максимум 50 мб принимал на себя.

вроде бы при заполнения памяти арс на диск пишет. медленнее, но все равно быстрее, чем без него.

Аватар пользователя chilic chilic 14 марта 2013 в 16:30

"Anton1" wrote:
я бы не советовал APC (именно APC) были у меня с ним глюки на нескольких серваках.

Угу, поэтому разработчики php включили его в ядро.

Аватар пользователя q2_faith q2_faith 14 марта 2013 в 16:40

"astrameridian" wrote:
Через вьюс, установив время кеширования представлений? Как то пробовал устанавливать, но база слишком разрасталась, +3 ГБ в сутки!

крон настроен?
"astrameridian" wrote:
Через вьюс, установив время кеширования представлений?

там можно настроить кэширование запросов, кэширование рендера. плюс еще настройки для блока по кэшированию. устанавливаются исходя исходя из задач. в вашем случае, я бы настроил только кэширование блока по страницам. и опять же настроил крон.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 17:33

q2_faith wrote:
"astrameridian" wrote:
Через вьюс, установив время кеширования представлений? Как то пробовал устанавливать, но база слишком разрасталась, +3 ГБ в сутки!

крон настроен?
"astrameridian" wrote:
Через вьюс, установив время кеширования представлений?

там можно настроить кэширование запросов, кэширование рендера. плюс еще настройки для блока по кэшированию. устанавливаются исходя исходя из задач. в вашем случае, я бы настроил только кэширование блока по страницам. и опять же настроил крон.

Установил в каждом представлении на вкладке Блок, Кеширование: По времени | 5 минут/5 минут, и Кеширование блока: По страницам.

Также в модуле Boost изменил минимальное время с 0 на 10 минут по всем типам.
Вспомнил, что для того, чтобы Boost показывал строчку внизу, нужно активировать блок в подвале сайта, у меня после активации показывает под каким именем и в какой папке страница сохранена на диске, а также строчку: Создан: 2013-03-14T17:04:10+04:00 и кнопку для сброса кеша в ручную отдельной страницы. Т.е. про время истечения не пишет...

Результаты вроде получше стали:
Executed 318 queries in 311.04 ms. Queries exceeding 5 ms are highlighted. Page execution time was 2151.95 ms. XHProf output. Memory used at: devel_boot()=6.42 MB, devel_shutdown()=79.6 MB, PHP peak=96.5 MB.

Но на памяти в итоге не отразилось, я правильно понимаю что эти цифры говорят о том, что на загрузку страницы потребовалось 96,5 мб оперативной памяти?

Аватар пользователя chilic chilic 14 марта 2013 в 16:40

"astrameridian" wrote:
[is_cacheable] => 1

Это значит закэшированно.
При отдаче из кэша на странице можно найти:
<!-- Page cached by Boost @ 2013-03-14 14:38:04, expires @ 2013-03-14 15:38:04, lifetime 1 hour -->

"astrameridian" wrote:
[status] => 404

А вот этот значит что страница не найдена Smile

"astrameridian" wrote:
Там есть параметр мин.и макс., может быть что-то типа мин.=0, макс.=1 час ?

Попробуйте ставить начиная с 10 минут Smile я говорил про это.

Аватар пользователя chilic chilic 14 марта 2013 в 17:39

"astrameridian" wrote:
Кеширование блока: По страницам.

25к нод = 25к разных кэшей одного блока :), вот и размер БД.

"astrameridian" wrote:
96,5 мб оперативной памяти

В принципе да.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 17:46

chilic wrote:
"astrameridian" wrote:
Кеширование блока: По страницам.

25к нод = 25к разных кэшей одного блока :), вот и размер БД.

"astrameridian" wrote:
96,5 мб оперативной памяти

В принципе да.

Предлагаете какое-то другое решение (настройку)?

Может быть отключить кеширование по времени 5 минут/5 минут, это больше пойдёт в плюс или в минус? Ведь получается что каждые 5 минут 25 000 кешей одного блока х 5 блоков = 125 000 кешей будут обновляться, что наверное создаст большую нагрузку, чем если например вообще не устанавливать?

И можно как то вывести из под этого правила, например главную страницу, чтобы там хотя бы каждый час всё было по разному, и при этом без особой нагрзуки?

Аватар пользователя chilic chilic 14 марта 2013 в 18:10

"astrameridian" wrote:
5 минут 25 000 кешей одного блока х 5 блоков = 125 000 кешей будут обновляться

Это не совсем верное утверждение. Обновляться будут только устаревшие по времени т.е. не сразу 125 000. И кэшироваться они будут по очереди.
Я бы предложил кэшировать эти блоки глобально, так можно сэкономить место в БД.

Аватар пользователя astrameridian astrameridian 14 марта 2013 в 18:45

Кстати, когда меняю какие либо настройки в представлениях, то попадаю на белый экран с текстом (видимо это код настроек представления), и приходится возвращаться на страницу назад в браузере и только потом сохранять.

У кого то такое было?
Может из-за кеширования или использования модуля admin menu который на javascript...?

Аватар пользователя astrameridian astrameridian 10 ноября 2015 в 11:49

1. Вообщем установил для всех блоков глобальное кеширование без установки времени.
2. В модуле Boost повысил минимальное время с 10 минут до 30 минут.
3. Установил модуль APC с настройками 4 мб макс. размер файла и 128 мб максимальное использование памяти для APC/

Итоги:
Страница вроде также или чуть быстрее загружается, где-то 332 запроса за 350 мс, загрузка страницы по разному от 2.4 до 4.4 секунд, ощутимый выигрыш в цифрах по памяти 55 мб, вместо 95 мб.

Однако при просмотре загруженности сайта, все параметры близки к 100% при его естественной посещаемости...т.е. перегружена память физ./вирт. и процессор, во вложении основные процессы по Devel и чайлд-процессы Main, когда главная страница грузилась 132 секунды! Может посоветуете что-то на основании этой информации?

Аватар пользователя astrameridian astrameridian 10 ноября 2015 в 11:49

q2_faith wrote:
"astrameridian" wrote:

у вас что на коллбэке дополнительно висит?

Если речь идёт о "call_user_func_array" то скриншот во вложении.
(видимо linkcheker много взял на себя во время запуска крона, он проверяет во всех материалах ссылки на работоспособность)

Аватар пользователя astrameridian astrameridian 15 марта 2013 в 1:47

Да кстати, сайт использует CDN Cloudflare.com, основной плюс которой в том, что страница загружается быстрее и вес её меньше, например без cloudflare вес страницы 440 кб и загрузка в среднем 7-8 секунд, а при подключенном cloudflare вес страницы 170 кб и загрузка страницы за 2-3 секунды.

Но, если в cloudflare отдавать не кешированные ресурсы, то нагрузка на сервер слишком высокая, поэтому получается двойная работа и на сайте сжимать (используется модуль Boost для страниц), а также сжимать javascript и css средствами Drupal и потом через cloudflare дополнительно оптимизировать и отдавать посетителю оптимизированную страницу.

Может быть в такой схеме не всё правильно и её можно улучшить?
И нужен ли при такой схеме APC?

Аватар пользователя maincg maincg 15 марта 2013 в 7:15

Я APC не рассматривал бы в принципе. Сначала поставил eAccelerator, сайты летали, но через сутки начинали жутко тормозить (4-7 с). Как оказалось, в eAccelerator'а отсутствует Cacher. Снес его и установил XCache. Сейчас нет никаких проблем, скорость высочайшая. Не зря же его использует самый популярный хостер для Drupal'а

Аватар пользователя astrameridian astrameridian 16 марта 2013 в 6:39

maincg wrote:
Я APC не рассматривал бы в принципе. Сначала поставил eAccelerator, сайты летали, но через сутки начинали жутко тормозить (4-7 с). Как оказалось, в eAccelerator'а отсутствует Cacher. Снес его и установил XCache. Сейчас нет никаких проблем, скорость высочайшая. Не зря же его использует самый популярный хостер для Drupal'а

К сожалению не очень разбираюсь в установке и настройках на сервер, и даже если хостера просить установить не уверен, что буду знать как настраивать, просматривать эффективность...Так что пока только на уровне модулей для Drupal 7 ориентируюсь...Но если "прижмёт", попробуем: XCache.

Аватар пользователя gorr gorr 15 марта 2013 в 11:55

Если материалы не часто обновляются и комментарии не очень часто новые, то можно закешировать страницы на сутки бустом. Если львиная доля посетителей сайта анонимы, то должно хорошо помочь.

Аватар пользователя astrameridian astrameridian 16 марта 2013 в 6:35

gorr wrote:
Если материалы не часто обновляются и комментарии не очень часто новые, то можно закешировать страницы на сутки бустом. Если львиная доля посетителей сайта анонимы, то должно хорошо помочь.

Спасибо, попробую. Было от 30 минут до 12 часов, сейчас поставил от 30 минут до 1 сутки и для html и для javascript. Посмотрим...

Аватар пользователя q2_faith q2_faith 15 марта 2013 в 15:09

"astrameridian" wrote:
Если речь идёт о "call_user_func_array" то скриншот во вложении.
(видимо linkcheker много взял на себя во время запуска крона, он проверяет во всех материалах ссылки на работоспособность)

установите что то типа http://drupal.org/project/elysia_cron, разведите по времени тяжелые процессы.

Аватар пользователя MainVisor MainVisor 15 марта 2013 в 22:28

1. Берем VPS сервак 1 CPU +1Gb на KVM ядерной виртуализации
2. Ставим nginx как бэкэнд Apache или заменяем всё на Litespeed
3. PHP обязательно как mod_php
4. Переносим cache MySQL в ОЗУ
5. Ставим eAccelerator, а лучше xCache, так как eAccelerator толком уже не развивается.
6. Ставим Zend Optimizer
7. Вырубаем кэш друпала, кроме css сжатия
...
и тыды и тыпы

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 11:19

MainVisor wrote:
1. Берем VPS сервак 1 CPU +1Gb на KVM ядерной виртуализации
2. Ставим nginx как бэкэнд Apache или заменяем всё на Litespeed
3. PHP обязательно как mod_php
4. Переносим cache MySQL в ОЗУ
5. Ставим eAccelerator, а лучше xCache, так как eAccelerator толком уже не развивается.
6. Ставим Zend Optimizer
7. Вырубаем кэш друпала, кроме css сжатия
...
и тыды и тыпы

Есть 2 минуса лично для меня в этом предложении:
1. Цена VPS в среднем в 10 раз дороже при тех же параметрах. Я сейчас плачу 120 р/мес. за 1 гб памяти, 2 гб вирт.памяти и 10 гб диска.
2. Знаний в настройке и администрировании сервера нет совсем.

Поэтому рассматриваю подобное предложение на некоторое отдалённое будущее при росте нагрузки сайта в несколько раз.

Аватар пользователя k_dmitry k_dmitry 15 марта 2013 в 23:55

"astrameridian" wrote:

Модулей включено 154 из 208 установленных.

Сделайте скрин страницы с модулями, интересно посмотреть что вы установили.

Аватар пользователя astrameridian astrameridian 16 марта 2013 в 6:33

multpix wrote:
"k_dmitry" wrote:
Сделайте скрин страницы с модулями

ls sites/all/modules > modulelist.txt

Вот список модулей (SSH есть):

addanother/
admin_menu/
advanced_help/
ajaxblocks/
apc/
boost/
bootstrap_optimizer/
captcha/
checklistapi/
ckeditor/
complete_profile/
composed_field/
contact_attach/
context/
ctools/
date/
devel/
double_field/
dtc/
editablefields/
elf/
elysia_cron/
entity/
entityreference/
expire/
ext_link_page/
extlink/
fast_404/
fbssts/
ffc/
field_delimiter/
field_ellipsis/
field_formatter_settings/
field_permissions/
field_word_boundary/
filecache/
fivestar/
flippy/
forward/
gravatar/
httprl/
image_resize_filter/
job_scheduler/
jquery_update/
l10n_client/
l10n_update/
libraries/
link/
linkchecker/
media/
media_browser_plus/
media_gallery/
media_youtube/
mediaelement/
menu_block/
metatag/
metatags_quick/
module_filter/
multiform/
multiupload_filefield_widget/
node_convert/
node_display_field/
node_field/
page_title/
parser-master/
path_breadcrumbs/
path_memory/
pathauto/
plupload/
profile2/
realname/
redirect/
semiclean/
seo_checker/
seo_checklist/
simple_field_formatter/
smart_paging/
smart_trim/
styles/
teaserimage/
textformatter/
token/
toolbar_admin_menu/
tooltipformatter/
transliteration/
typo/
views/
views_bulk_operations/
views_secondary_row/
votingapi/
yandex-pinger/
youtube/

Сейчас подчистил немного и число модулей активировано 138 из 187.

Аватар пользователя astrameridian astrameridian 16 марта 2013 в 7:02

Провёл сейчас тест по http://loadimpact.com/ итоги неутешительные
уже где-то на 15-ти одновременных посетителях пошла 1 ошибка (сайт был недоступен для этого посетителя).
Также к этому моменту ресурсы загрузки процессора, памяти были близки к 100%.

В итоге из 178 сделанных соединений (транзакций), 165 с кодом 200, 13 были не успешными. Мин время загрузки страницы: 3.33s, максимальное: 49.27s
При попытке загрузить страницу в браузере при 40 одновременных подключений, время отдачи кода 200 в Файрфоксе было 18 секунд (т.е. это отдача html страницы весом в 60 r,)? при попытке загрузить страницу при 47 соединениях, сайт не загрузился (белая пустая страница).

При всём при этом, наблюдая по SSH при нагрузке в 30-50 соединений, кол-во процессов около 20-25, из которых активных 4-7, спящих 10-15...

Аватар пользователя astrameridian astrameridian 10 ноября 2015 в 11:49

Кстати если в phpMyAdmin посмотреть статистику базы данных: localhost -> Состояние -> Текущее состояние MySQL

Сетевой трафик с момента запуска: 554.7 ГБ

Сервер MySQL работает 1 дней, 15 часов, 31 минут и 17 секунд. Запущен Мар 14 2013 г., 12:40.
Трафик ø в час
Принято 28.1 ГБ 727.2 МБ
Отправлено 526.6 ГБ 13.3 ГБ
Всего 554.7 ГБ 14 ГБ

Соединения ø в час %
Максимально одновременных 117 --- ---
Неудачных попыток 5,634 142.56 0.20%
Прерваны 627 15.86 0.02%
Всего 2,766 k 69.99 k 100.00%

Во вложении скрины основных вкладок, интересно что можете посоветовать, на основании этих данных и насколько правильно (безопасно) прибегать к авто советам на последнем скрине?

Аватар пользователя q2_faith q2_faith 16 марта 2013 в 14:13

"astrameridian" wrote:
Провёл сейчас тест по http://loadimpact.com/ итоги неутешительные
уже где-то на 15-ти одновременных посетителях пошла 1 ошибка (сайт был недоступен для этого посетителя).
Также к этому моменту ресурсы загрузки процессора, памяти были близки к 100%.

я думаю вы уперлись в настройку окружения

Аватар пользователя astrameridian astrameridian 16 марта 2013 в 18:58

q2_faith wrote:
я думаю вы уперлись в настройку окружения

А что же можно ещё сделать не со следствием, а с причиной?

1. Возникла идея, можно ли сделать случайный вывод через представления но не среди всех материалов определённого типа, а например последние 100, тем самым сократив размер кэша базы и снизив нагрузку с базы данных по подготовке данного представления. Если это поможет, как это реализовать?

2. Пробовал недавно использовать модуль filecache, который записывает на диск содержимое кэша базы данных и выдаёт его минуя запрос к базе, но по результатам испытаний его работа вызывала большую нагрузку ввод-вывод 1024/1024 и соответственно процессора и памяти также, что приводило к меньшей производительности. Но это было тогда, когда вызов 1 страницы отнимал 98 мб памяти, а так как сейчас около 55 мб, возможно он даст лучший результат? Думаю попробовать в ближайшее время...

Может есть какие ещё идеи по повышению производительности и "стрессоустойчивости" сайта?

Аватар пользователя Jean-Claude Jean-Claude 16 марта 2013 в 19:34

то что на первом скрине phpmyadmin скорее всего относится ко всему mysql, а не именно к одному вашему аккаунту у хостера.

так как у меня тоже виртуальный хостинг с клоудлинуксом
посмотрел эти данные у себя, у меня нормальные работоспособные сайтики без ошибок и зверских нагрузок, но скрин более ужасный чем ваш Smile

у вас 117 максимально одновременных соединений, у меня 331
у вас неудачных попыток 5600, у меня 70 000
у вас 550 гиг общего трафика, у меня 2,7 терабайта

у вас 48 000 000 запросов с запуска - у меня 720 000 000

и у меня все шустренько работает, очень даже хорошо.

Аватар пользователя q2_faith q2_faith 16 марта 2013 в 20:38

"astrameridian" wrote:
А что же можно ещё сделать не со следствием, а с причиной?

причину я особую не вижу. количество запросов не ужасает. но то, что они медленно выполняются как бы намекает на настройку окружения

Аватар пользователя k_dmitry k_dmitry 16 марта 2013 в 20:49

"astrameridian" wrote:
Пробовал недавно использовать модуль filecache

"astrameridian" wrote:
что приводило к меньшей производительности

Может нету доступа к /tmp... получилось что друпал каждый раз сначала создавал кеш и только потом отдавал страницу...

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 7:23

k_dmitry wrote:
"astrameridian" wrote:
Пробовал недавно использовать модуль filecache

"astrameridian" wrote:
что приводило к меньшей производительности

Может нету доступа к /tmp... получилось что друпал каждый раз сначала создавал кеш и только потом отдавал страницу...

Во временной папке .sh.... для записи кеша базы было около 10 000 файлов объёмом около 400 мб....наверное это означает что доступ был, или я что-то не так понимаю?

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 8:13

Кстати при включении модуля filecache и добавления в settings.php строчек:
$conf['cache_backends'] = array('sites/all/modules/filecache/filecache.inc');
$conf['cache_default_class'] = 'DrupalFileCache';

перестал грузится сайт:
Fatal error: Class 'DrupalAPCCache' not found in /home/biopcru/public_html/includes/cache.inc on line 31

Удалив после этого строчки для APC:

/**
* Add APC Caching.
*/
$conf['cache_backends'] = array('sites/all/modules/apc/drupal_apc_cache.inc');
$conf['cache_class_cache'] = 'DrupalAPCCache';
$conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';
//$conf['apc_show_debug'] = TRUE; // Remove the slashes to use debug mode.

Сайт снова стал грузится, при этом на странице: /admin/reports/status пишет что APC работает, также как и filecache.
Это нормально? В смысле без указанных строчек для APC в settings.php, APC всё равно корректно работает? или нужно что-то подправить?

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 8:19

Ущё вопрос по APC, в настройках php.ini выставил для APC 32 mb, при этом за всё время, при просмотре /admin/reports/status занятой памяти для APC показывает обычно 2-3 мб, никогда больше 4 мб не было. APC настройки были сделаны для стандартного режима (а) в описании модуля.

Или лучше сделать режим (б), чтобы максимум из базы данных в оперативной памяти грузилось?

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 8:38

Ура! После подключения filecache и проверки сайта на http://loadimpact.com/
сайт держался до 43 одновременных подключений!

В итоге: 173 соединений, 24 в ошибке.
Мин. скорость загрузки страницы: 3.21s, максимальная: 56.86s.

При этом при 43 соединениях, скорость загрузки была около 18 секунд.

Также стоит отметить, что при тестировании потребление памяти было намного меньше, в середине тестирования не более 400 мб из 1024 мб. И процессы top по SSH в столбце RES были по 50-70 мб, ранее они обычно по 150 мб в среднем были и кол-во активных PHP процессов было больше спящих, 13 активных против 5-7 спящих.

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 8:46

Также есть вопрос, как не сбрасывая кеш Boost, который сейчас копится 24 часа, сбрасывать отдельный блок, например каждый час?
Речь идёт о размещении ссылок в блоке, ссылки периодически покупают на разных страницах, в итоге закешированная страница не отображает ссылки 24 часа.

Вроде стоит модуль ajaxblocks , который вроде должен подгружать данный блок используя ajax, но не знаю как проверить закешировнность/незакешированность отдельной области страницы...

Пробовал ранее модуль Block Cache Alter, но он как то в связке с Boost не работал...

Вообщем пока, кол-во ссылок в статусе Error увеличилось, т.е. они до сброса кеша видимо не обновляются на странице. Как же их всё таки обновлять?

Аватар пользователя MainVisor MainVisor 17 марта 2013 в 11:05

На VPS 1GH и 512Mb простой сайт без включенных кешэй держит 50 одновременных соединений с загрузкой страницы до 5.9 сек. То есть это вообще без кешей и ускорителей, по дефолту.

"q2_faith" wrote:
я думаю вы уперлись в настройку окружения

Аватар пользователя gorr gorr 17 марта 2013 в 15:26

"astrameridian" wrote:
Также есть вопрос, как не сбрасывая кеш Boost, который сейчас копится 24 часа, сбрасывать отдельный блок, например каждый час?
Речь идёт о размещении ссылок в блоке, ссылки периодически покупают на разных страницах, в итоге закешированная страница не отображает ссылки 24 часа.

Если это продаются ссылки через сервис типа сапы, то там только прямые ссылки нужны, так что все, что грузится через ajax не годится. Кроме того, если включится ссылка на день позже по-моему некритично. Их же не раскупают по сто в день наверное. Ну и в крайнем случае, если это так принципиально, то можно сбрасывать вручную кеш через админку или даже просто удалив нужный файл в директории кеша буста.

Аватар пользователя Jean-Claude Jean-Claude 17 марта 2013 в 15:36

"astrameridian" wrote:
Я сейчас плачу 120 р/мес

ёпть, еще и скулит Crazy

нормальный хостинг возьми, баксов за 10-15 хотя бы.
на вирте у тебя все ограничивают, проц например, а на впс нет (к примеру на виртах 3-5% дают всего от ксеона 3000мгц, это всего 100-150 мгц), но согласен - впс это геморрой если ты не умеешь администрировать, либо огромные растраты на админа, проще взять випхостинг с высоким cpu лимитом 10-30% и тп.

Аватар пользователя astrameridian astrameridian 17 марта 2013 в 21:04

Заводской раб wrote:
"astrameridian" wrote:
Я сейчас плачу 120 р/мес

ёпть, еще и скулит Crazy

нормальный хостинг возьми, баксов за 10-15 хотя бы.
на вирте у тебя все ограничивают, проц например, а на впс нет (к примеру на виртах 3-5% дают всего от ксеона 3000мгц, это всего 100-150 мгц), но согласен - впс это геморрой если ты не умеешь администрировать, либо огромные растраты на админа, проще взять випхостинг с высоким cpu лимитом 10-30% и тп.

Если честно, то среагировал на рекламу, типа "Мы надежно разделяем ресурсы сервера за счет Cloudlinux, поэтому нагрузка соседей не будет мешать вашей работе".
По заверениям хостера:

Конфигурация клиентских серверов:
Производитель/модель: Dell R410, Dell R510
Процессор: 2 x E5620
Память: 64 ГБ
Диски: 4 x 600 ГБ SAS
Количество пользователей на одном сервере: не более 200
Доступные ресурсы для одного аккаунта вирутального хостинга:
Доступная мощность процессора: 25% от одного ядра или 600 МГц
Максимально доступная оперативная память для всех процессов пользователя: 1 ГБ физическая, 2 ГБ виртуальная

Конечно, если вдруг у всех 200 клиентах на сервере будет 100% загрузка памяти и процессора, то цифры на каждого будут совсем иные, но хостер говорит что такого практически не бывает и каждый получает заявленное.

Лично у меня за месяц использование процессора в среднем около 19% составило от квоты в 600 мгц.

Аватар пользователя maincg maincg 17 марта 2013 в 22:44

В VPS ничего страшного нет. Многие хостеры предлагают разнообразные панели управления: ISPmanager, Parallels Plesk и т.д. Также Вам предоставят VPS с выбранной Вами осью: CentOS, Debian, Ubuntu, Fedora, OpenSuSE, etc. Вам останется лишь установить XCache, nginx через SSH. Мой Вам совет: установите на виртуалку CentOS 6 с GUI и поработайте с ней, особенно с консолью. На VPS будет консольная CentOS. В Интернете пруд пруди информации по установке и настройке компонент к CentOS.

К примеру, у меня такие ТТХ VPS:
CentOS 6.3 (Xen-виртуализация)
CPU: 600 MHz (гарантирванно из 2.6 GHz)
RAM: 512 Mb
SSD: 7Gb
ISPmanager Lite

PHP 5.3 with XCache 3.0.1

Сайты летают, даже несмотря на то, что еще не установил nginx

Аватар пользователя Jean-Claude Jean-Claude 17 марта 2013 в 22:45

до поры до времени, у меня было несколько вдс

из проблем помню были такие - папка tmp заполнилась полностью, там были миллионы файлов сессий и всякого мусора, а обычной командой из ssh они чет не удалялись Smile

ну в общем была куча нюансов, которые я уже не помню...

Аватар пользователя astrameridian astrameridian 18 марта 2013 в 13:20

Подскажите на основании данной статьи:
http://drupalace.ru/lesson/sistema-keshirovaniya-drupal-7-chast-tretya-u...

Для множественного хранения внизу приведены настройки:
// Выносим кэш страниц в Varnish.
$conf['cache_backends'][] = 'sites/all/modules/varnish/varnish.cache.inc';
$conf['cache_class_cache_page'] = 'VarnishCache';

// Выносим общий кэш и кэш бутстрапа в APC.
$conf['cache_backends'][] = 'sites/all/modules/apc/drupal_apc_cache.inc';
$conf['cache_class_cache'] = 'DrupalAPCCache';
$conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';

// Выносим кэш форм в базу данных, чтобы не засорять оперативную память.
$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';

// Остальной кэш будет храниться в мемкэше.
$conf['cache_backends'][] = 'sites/all/modules/memcache_storage/memcache_storage.inc';
$conf['cache_default_class'] = 'MemcacheStorage';

// Просим Друпал загружать кэш из Varnish'a без бутстрапа базы данных.
$conf['page_cache_without_database'] = TRUE;
$conf['page_cache_invoke_hooks'] = FALSE;

Какие должны быть верные настройки для моего сайта, если Мемкэш и Варниш не используются, а используются Boost, APC, Filecache ?
Например если я всё хочу через APC загружать таблицу cache_form? которая у меня около 1.4 гб весит в базе, и явялется самой большой, сделать так, чтобы она через filecache грузилась минуя опять же базу данных?

Аватар пользователя astrameridian astrameridian 22 марта 2013 в 14:16

После установки модуля http://drupal.org/project/apc_status для просмотра состояния работы APC увидел, что APC не держится больше нескольких минут, получается весь эффект от него пропадает.

Сейчас настройки такие:

APC Version 3.1.13
PHP Version 5.3.22
Server Software Apache/2.4.4 (Unix) OpenSSL/1.0.0-fips mod_bwlimited/1.4 mod_fcgid/2.3.6
Shared Memory 1 Segment(s) with 100.0 MBytes
(mmap memory, pthread read/write Locks locking)
Start Time 2013/03/22 14:06:09
Uptime 3 minutes
File Upload Support 1

Runtime Settings
apc.cache_by_default 1
apc.canonicalize 1
apc.coredump_unmap 0
apc.enable_cli 0
apc.enabled 1
apc.file_md5 0
apc.file_update_protection 2
apc.filters -/sites/all/libraries/apc_admin/051675a87360/apc\.php$,
-/sites/all/libraries/APC/apc\.php\.inc$
apc.gc_ttl 3600
apc.include_once_override 0
apc.lazy_classes 0
apc.lazy_functions 0
apc.max_file_size 4M
apc.mmap_file_mask
apc.num_files_hint 2048
apc.preload_path
apc.report_autofilter 0
apc.rfc1867 1
apc.rfc1867_freq 0
apc.rfc1867_name APC_UPLOAD_PROGRESS
apc.rfc1867_prefix upload_
apc.rfc1867_ttl 3600
apc.serializer default
apc.shm_segments 1
apc.shm_size 100M
apc.slam_defense 1
apc.stat 1
apc.stat_ctime 0
apc.ttl 0
apc.use_request_time 1
apc.user_entries_hint 4096
apc.user_ttl 3600
apc.write_lock 1

Вопрос: как сделать так, чтобы APC не сбрасывал кэш?

Аватар пользователя astrameridian astrameridian 28 марта 2013 в 5:25

РЕШЕНО

Итог:
1. При тестировании сайта через: http://loadimpact.com - мин.время загрузки страницы: 7.77s, макс. время загрузки страницы: 9.92s, ошибок - нет
* При этом для усложнения задачи, предварительно было запущено сканирование сайта в 5 потоков без задержки и ограничений скорости: http://www.auditmypc.com/free-sitemap-generator.asp (приложение для создания карты сайта...ранее запуская только его в 4 потока сайт становился недоступным)

2. Использование ресурсов виртуального хостинга при этом было следующее:
Если запускать только тест loadimpact.com, то максимальная загрузка CPU в пиковые моменты была = 33%, памяти от 200 до 330 мб из 1048 мб.
Если запускать loadimpact.com и сканирование сайта в 5 потоков, загрузка CPU постоянно была = 100%, памяти от 660 до 900 мб из 1048 мб.

Представляю отчёт о выполненных действиях, которые позволили этого достичь:

1. Блоки вывода случайных материалов через Views: было включено глобально кеширование блоков и для 2 блоков в которых использовалось большое кол-во нод (4 000), была дополнительно введена фильтрация по дате от 01.01.2013 (за это время около 200-300 материалов было добавлено, что снижает кол-во кэша).

2. Различные тесты APC и Memcache не привели к устраивающим результатам и были удалены, а PHP версия была изменена с 5.3 на 5.5.

3. Были установлены модули: Authcache и File Cache для кеширования страниц анонимных и зарегистрированных пользователей (базовые настройки для работы 2-х модулей в связке), а также Shadow (Speed up SELECT queries by using 'shadow' tables), Shadow Views (Views integration for Shadow), Entity cache, Entity cache flusher.
*** Это позволило уменьшить время получения html страницы (62 кб) с 1.5 секунд до 180 мс (из которых 38 мс блокирование, 141 мс ожидание, 1 мс получение). А загрузка всей страницы в 442 кб стала происходить за 3,68 секунд, вместо 6-8 секунд.

4. Были установлены модули: CSS Embedded Images, LABjs, Preprocessor, Sassy, Speedy (Tools to improve the front end performance of your site).
*** При проверке скорости загрузки и эффективности оптимизации через: http://gtmetrix.com/, результаты были очень слабые, и основное что позволили добиться эти модули, это снижение кол-ва запросов при загрузке страницы со 142 до 51 (объединение изображений в CSS спрайты), уменьшение размера страницы на 60-80 кб (уменьшение размера CSS и Javascript, асинхронная загрузка JS).

Пока это всё.

На очереди тестирование модуля: db_maintenance для оптимизации таблиц базы данных.

Аватар пользователя marazmus marazmus 28 марта 2013 в 9:36

1) random в mysql очень медленный, гугл выдает тонны плача по этому поводу, вывод - кешируйте рандом-блоки

2) вся эта тряхомундия нивелируется покупкой хостинга у ИТПатрола за 300 рублей в месяц, после чего такие проблемы забываются, и появляется время на сам сайт, а не на разборки с нищебродским хостингом

Аватар пользователя astrameridian astrameridian 28 марта 2013 в 13:22

marazmus wrote:
1) random в mysql очень медленный, гугл выдает тонны плача по этому поводу, вывод - кешируйте рандом-блоки

2) вся эта тряхомундия нивелируется покупкой хостинга у ИТПатрола за 300 рублей в месяц, после чего такие проблемы забываются, и появляется время на сам сайт, а не на разборки с нищебродским хостингом

1. random блоки кешируются, об этом было написано в п.1

2. ИТПатрол в правилах запрещает регистрацию сайтов, которые продают ссылки (участвуют в биржах ссылок). И за 300р. у них 2 гб (вместо текущих 10 гб у моего хостера и памяти вроде тоже дают меньше, то ли 256, то ли 512, вместо 1048)...