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 ???
Комментарии
Сколько используется модулей, типов материалов, полей?
APC, xCache?
Какой веб-сервер?
Модулей включено 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. Наверняка это создаёт львиную нагрузку на базу данных, но для сайта очень важное значение имеет вывод на каждой странице разных материалов...
подпишусь
>На всех страницах сайта используются блоки вывода случайных материалов (views), которых всего 5
чо за вьюхи, какие запросы делаются? может индексы надо в базе поставить
Представления используются следующие:
1. Случайный вывод цитаты (только блок)
2. Случайный вывод 3-х анонсов статей: картинка + заголовок + 200 знаков содержимого (блок + ссылка на каталог статей)
3. Случайный вывод 5-ти анонсов видео галерей: заголовок + 200 знаков текста (только блок)
4. Случайный вывод 3-х анонсов опубликованных текстов (книг, 1 уровень подшивки): заголовок + картинка + 200 знаков текста (блок + ссылка на каталог книг)
5. Случайный вывод 5-ти анонсов опубликованных текстов (книг, 2-3 уровень подшивки): заголовок + 200 знаков текста (только блок)
6. Статичный вывод 5-ти последних опубликованных на сайте материалов: заголовок + 200 знаков текста (блок + ссылка на каталог материалов).
Соответственное вывод в блоки производится в основном по типу материала: цитаты, статьи, видео галереи, книги, все материалы.
Блоки расположены слева, справа и снизу под содержимым страницы.
Можно подробнее что за индексы и как их поставить и к чему это может привести?
да, это к специалистам вам надо обращаться, если вы совсем не в теме такого.
Вывожу данные 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%
Может можно как то представления сделать кешированными, например чтобы на всех страницах было разное содержимое (эффект случайного вывода), но при обновлении этой же страницы показывалось то же самое.
Реально ли такое сделать, и если да, то как реализовать?
послушаю
Акселератор для php просто необходим, при правильной настройке он не замедляет работу, а даёт прирост.
В разных случаях по разному, однако факт: увеличится скорость работы php, уменьшиться потребление памяти php.
Спорный момент в связке с apache, лучше использовать mod_php. ИМХО.
Если нет возможности отказаться от них, тогда закэшировать.
Проверьте модули apache, включен ли expires?
Возможно ли для статики поставить nginx?
Установка и настройка opcode-кэша, даст Вам хотя-бы вздохнуть спокойно.
Если нет возможности отказаться от них, тогда закэшировать.[/quote]
Каким образом правильно закешировать?
Через вьюс, установив время кеширования представлений? Как то пробовал устанавливать, но база слишком разрасталась, +3 ГБ в сутки!
Там есть параметр мин.и макс., может быть что-то типа мин.=0, макс.=1 час ?
Пробовал модуль alter block cache, но эффекта от его работы не было, при обновлении страниц каждый раз показывался новый контент в блоках вывода случайных материалов...
Или речь идёт о другом виде кеширования?
Так же замечу, при правильно настроенном модуле 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 ###
Также в настройках 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.
Других настроек вроде нету.
Так как хостинг виртуальный, врят ли я могу что-то на уровне сервера делать. Насколько я знаю от хостера, используется связка 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 нет.
Меняйте хостера.
Boost генерирует правила правильно. Вы добавили их в файл .htaccess?
Так же в настройках буста есть опция для отладки. т.е. буст может добавить либо заголовок, либо скрытый текст в конец страницы, о том что он отработал правильно.
Конечно добавил в .htaccess
Включил режим отладки, пишет в лог, если посмотреть, то в конце лога есть такие строчки:
[menu_item] => Array
(
[page_type] =>
[page_id] =>
[status] => 404
[extra_arguments] =>
)
[is_cacheable] => 1
[cache_this] =>
)
Правильно ли я понимаю что главное здесь параметр: is_cacheable =1, и он означает что кеширование работает?
вроде бы при заполнения памяти арс на диск пишет. медленнее, но все равно быстрее, чем без него.
я бы не советовал APC (именно APC) были у меня с ним глюки на нескольких серваках.
Угу, поэтому разработчики php включили его в ядро.
крон настроен?
там можно настроить кэширование запросов, кэширование рендера. плюс еще настройки для блока по кэшированию. устанавливаются исходя исходя из задач. в вашем случае, я бы настроил только кэширование блока по страницам. и опять же настроил крон.
Установил в каждом представлении на вкладке Блок, Кеширование: По времени | 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 мб оперативной памяти?
Это значит закэшированно.
При отдаче из кэша на странице можно найти:
<!-- Page cached by Boost @ 2013-03-14 14:38:04, expires @ 2013-03-14 15:38:04, lifetime 1 hour -->А вот этот значит что страница не найдена
Попробуйте ставить начиная с 10 минут
я говорил про это.
я в курсе, что он в ядре - поэтому и работал с ним, но у меня он глючил
25к нод = 25к разных кэшей одного блока :), вот и размер БД.
В принципе да.
Предлагаете какое-то другое решение (настройку)?
Может быть отключить кеширование по времени 5 минут/5 минут, это больше пойдёт в плюс или в минус? Ведь получается что каждые 5 минут 25 000 кешей одного блока х 5 блоков = 125 000 кешей будут обновляться, что наверное создаст большую нагрузку, чем если например вообще не устанавливать?
И можно как то вывести из под этого правила, например главную страницу, чтобы там хотя бы каждый час всё было по разному, и при этом без особой нагрзуки?
Это не совсем верное утверждение. Обновляться будут только устаревшие по времени т.е. не сразу 125 000. И кэшироваться они будут по очереди.
Я бы предложил кэшировать эти блоки глобально, так можно сэкономить место в БД.
Кстати, когда меняю какие либо настройки в представлениях, то попадаю на белый экран с текстом (видимо это код настроек представления), и приходится возвращаться на страницу назад в браузере и только потом сохранять.
У кого то такое было?
Может из-за кеширования или использования модуля admin menu который на javascript...?
у меня из за девела это было
я бы посоветовал ещё загуглить. Edge Side Includes мне в своё время эта технология очень пригодилась.
1. Вообщем установил для всех блоков глобальное кеширование без установки времени.
2. В модуле Boost повысил минимальное время с 10 минут до 30 минут.
3. Установил модуль APC с настройками 4 мб макс. размер файла и 128 мб максимальное использование памяти для APC/
Итоги:
Страница вроде также или чуть быстрее загружается, где-то 332 запроса за 350 мс, загрузка страницы по разному от 2.4 до 4.4 секунд, ощутимый выигрыш в цифрах по памяти 55 мб, вместо 95 мб.
Однако при просмотре загруженности сайта, все параметры близки к 100% при его естественной посещаемости...т.е. перегружена память физ./вирт. и процессор, во вложении основные процессы по Devel и чайлд-процессы Main, когда главная страница грузилась 132 секунды! Может посоветуете что-то на основании этой информации?
у вас что на коллбэке дополнительно висит?
Если речь идёт о "call_user_func_array" то скриншот во вложении.
(видимо linkcheker много взял на себя во время запуска крона, он проверяет во всех материалах ссылки на работоспособность)
Да кстати, сайт использует CDN Cloudflare.com, основной плюс которой в том, что страница загружается быстрее и вес её меньше, например без cloudflare вес страницы 440 кб и загрузка в среднем 7-8 секунд, а при подключенном cloudflare вес страницы 170 кб и загрузка страницы за 2-3 секунды.
Но, если в cloudflare отдавать не кешированные ресурсы, то нагрузка на сервер слишком высокая, поэтому получается двойная работа и на сайте сжимать (используется модуль Boost для страниц), а также сжимать javascript и css средствами Drupal и потом через cloudflare дополнительно оптимизировать и отдавать посетителю оптимизированную страницу.
Может быть в такой схеме не всё правильно и её можно улучшить?
И нужен ли при такой схеме APC?
Я APC не рассматривал бы в принципе. Сначала поставил eAccelerator, сайты летали, но через сутки начинали жутко тормозить (4-7 с). Как оказалось, в eAccelerator'а отсутствует Cacher. Снес его и установил XCache. Сейчас нет никаких проблем, скорость высочайшая. Не зря же его использует самый популярный хостер для Drupal'а
К сожалению не очень разбираюсь в установке и настройках на сервер, и даже если хостера просить установить не уверен, что буду знать как настраивать, просматривать эффективность...Так что пока только на уровне модулей для Drupal 7 ориентируюсь...Но если "прижмёт", попробуем: XCache.
Да, темка интересная
Если материалы не часто обновляются и комментарии не очень часто новые, то можно закешировать страницы на сутки бустом. Если львиная доля посетителей сайта анонимы, то должно хорошо помочь.
Спасибо, попробую. Было от 30 минут до 12 часов, сейчас поставил от 30 минут до 1 сутки и для html и для javascript. Посмотрим...
установите что то типа http://drupal.org/project/elysia_cron, разведите по времени тяжелые процессы.
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. Знаний в настройке и администрировании сервера нет совсем.
Поэтому рассматриваю подобное предложение на некоторое отдалённое будущее при росте нагрузки сайта в несколько раз.
Сделайте скрин страницы с модулями, интересно посмотреть что вы установили.
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.
у него на вирте может ssh нет
Провёл сейчас тест по 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...
Кстати если в 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%
Во вложении скрины основных вкладок, интересно что можете посоветовать, на основании этих данных и насколько правильно (безопасно) прибегать к авто советам на последнем скрине?
я думаю вы уперлись в настройку окружения
А что же можно ещё сделать не со следствием, а с причиной?
1. Возникла идея, можно ли сделать случайный вывод через представления но не среди всех материалов определённого типа, а например последние 100, тем самым сократив размер кэша базы и снизив нагрузку с базы данных по подготовке данного представления. Если это поможет, как это реализовать?
2. Пробовал недавно использовать модуль filecache, который записывает на диск содержимое кэша базы данных и выдаёт его минуя запрос к базе, но по результатам испытаний его работа вызывала большую нагрузку ввод-вывод 1024/1024 и соответственно процессора и памяти также, что приводило к меньшей производительности. Но это было тогда, когда вызов 1 страницы отнимал 98 мб памяти, а так как сейчас около 55 мб, возможно он даст лучший результат? Думаю попробовать в ближайшее время...
Может есть какие ещё идеи по повышению производительности и "стрессоустойчивости" сайта?
Подписался
то что на первом скрине phpmyadmin скорее всего относится ко всему mysql, а не именно к одному вашему аккаунту у хостера.
так как у меня тоже виртуальный хостинг с клоудлинуксом
посмотрел эти данные у себя, у меня нормальные работоспособные сайтики без ошибок и зверских нагрузок, но скрин более ужасный чем ваш
у вас 117 максимально одновременных соединений, у меня 331
у вас неудачных попыток 5600, у меня 70 000
у вас 550 гиг общего трафика, у меня 2,7 терабайта
у вас 48 000 000 запросов с запуска - у меня 720 000 000
и у меня все шустренько работает, очень даже хорошо.
причину я особую не вижу. количество запросов не ужасает. но то, что они медленно выполняются как бы намекает на настройку окружения
Может нету доступа к /tmp... получилось что друпал каждый раз сначала создавал кеш и только потом отдавал страницу...
Во временной папке .sh.... для записи кеша базы было около 10 000 файлов объёмом около 400 мб....наверное это означает что доступ был, или я что-то не так понимаю?
Кстати при включении модуля 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 всё равно корректно работает? или нужно что-то подправить?
Ущё вопрос по APC, в настройках php.ini выставил для APC 32 mb, при этом за всё время, при просмотре /admin/reports/status занятой памяти для APC показывает обычно 2-3 мб, никогда больше 4 мб не было. APC настройки были сделаны для стандартного режима (а) в описании модуля.
Или лучше сделать режим (б), чтобы максимум из базы данных в оперативной памяти грузилось?
Ура! После подключения 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 спящих.
Также есть вопрос, как не сбрасывая кеш Boost, который сейчас копится 24 часа, сбрасывать отдельный блок, например каждый час?
Речь идёт о размещении ссылок в блоке, ссылки периодически покупают на разных страницах, в итоге закешированная страница не отображает ссылки 24 часа.
Вроде стоит модуль ajaxblocks , который вроде должен подгружать данный блок используя ajax, но не знаю как проверить закешировнность/незакешированность отдельной области страницы...
Пробовал ранее модуль Block Cache Alter, но он как то в связке с Boost не работал...
Вообщем пока, кол-во ссылок в статусе Error увеличилось, т.е. они до сброса кеша видимо не обновляются на странице. Как же их всё таки обновлять?
На VPS 1GH и 512Mb простой сайт без включенных кешэй держит 50 одновременных соединений с загрузкой страницы до 5.9 сек. То есть это вообще без кешей и ускорителей, по дефолту.
Если это продаются ссылки через сервис типа сапы, то там только прямые ссылки нужны, так что все, что грузится через ajax не годится. Кроме того, если включится ссылка на день позже по-моему некритично. Их же не раскупают по сто в день наверное. Ну и в крайнем случае, если это так принципиально, то можно сбрасывать вручную кеш через админку или даже просто удалив нужный файл в директории кеша буста.
ёпть, еще и скулит
нормальный хостинг возьми, баксов за 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 мгц.
не знаю, не знаю, мне хостер дает 4,5% от своего сервака.
тогда у меня average cpu 0%?
В 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
до поры до времени, у меня было несколько вдс
из проблем помню были такие - папка tmp заполнилась полностью, там были миллионы файлов сессий и всякого мусора, а обычной командой из ssh они чет не удалялись
ну в общем была куча нюансов, которые я уже не помню...
Подскажите на основании данной статьи:
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 грузилась минуя опять же базу данных?
После установки модуля 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 не сбрасывал кэш?
купить нормальный хостинг, а не за 4 бакса
РЕШЕНО
Итог:
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 для оптимизации таблиц базы данных.
1) random в mysql очень медленный, гугл выдает тонны плача по этому поводу, вывод - кешируйте рандом-блоки
2) вся эта тряхомундия нивелируется покупкой хостинга у ИТПатрола за 300 рублей в месяц, после чего такие проблемы забываются, и появляется время на сам сайт, а не на разборки с нищебродским хостингом
1. random блоки кешируются, об этом было написано в п.1
2. ИТПатрол в правилах запрещает регистрацию сайтов, которые продают ссылки (участвуют в биржах ссылок). И за 300р. у них 2 гб (вместо текущих 10 гб у моего хостера и памяти вроде тоже дают меньше, то ли 256, то ли 512, вместо 1048)...