за сутки прироста comment_form не обнаружил, т.е. исправление function ajax_comments_cache_get($cid, $table = 'cache') помогло.
Поставил memcached, настроил CacheRouter на него, полет нормальный.
Единественное, не очень понял что означает вывод memcached-tool 127.0.0.1:11211 stats
в APC теперь хранятся только сами файлы php, ini - нужно примерно 40Мб на 1 сайт друпала.
в cacherouter/engines/memcache.php есть опечатка (версия не дев):
66: if ($expire == CACHE_TEMPORARY || $expire == CACHE_PERMENANT) {
от туда и брал вот этот http://drupal.ru/files/nginx.tgz[/quote]
вообще там еще настройки кой-какие в nginx.conf, в частности index index.php, и дальше идет include hosts/example.ru
а остальное в hosts/
и количество worker_processes поставьте сколько ядер,
worker_rlimit_nofile=8192, т.к. по умолчанию 32к нет, надо sysctl править
Здравствуйте!
не работает очистка кеша cache_form при использовании cacherouter 6.x-1.0-rc1
С cacherouter 6.x-dev не совместим http://drupal.ru/node/53106
запостил issue в drupal core http://drupal.org/node/978942 - у меня почему-то не чистится cache_form,
без нее весь кеш будет весить немного, попробую memcached, спасибо Вам за помощь!
еще sessions, captcha_sessions непонятно, их кто-нибудь чистит?
вроде не кеш, но сессий уже много накопилось.
boost кстати в базу тоже дохрена пишет, так что, возможно, Crea был прав, что varnish лучше!
просто я на роботах нагрузки не видел, так в принципе все нормально, но сейчас меня такой объем трафика 6 гигабайт в час между сайтом и сервером mysql на localhost не устраивает, я наружу в сто раз меньше отдаю!!
Без кеширования сайт тормозит, а с кешированием мускул насилует.
Сейчас выключил кеширование views - вроде на производительность вообще не влияет, возможно, я не совсем понимаю, как он кеширует, но запросов к бд у него больше всего.
у меня к примеру 10 views без аргументов, без node access, я полагал, что будет 10 записей в кеше, который обновляется раз в минуту (стоял кеш 1мин / 1 мин).
а на деле получилось 18к запросов за 2.5 часа = 120 в минуту / 10 = 1 запрос раз в 5 сек на каждый view - откуда столько?
ищите в ядре все функции, которые выводят дату, которую надо заменить - в комментариях, нодах и т.д.
перетаскиваете их в template.php Вашей темы
переименовываете их добавляя название темы function [your_theme]_date()
а там уже вызываете функцию, которую Вам предложили.
С архивом тоже вопрос решил - вместо длинного запроса, где created проверяется 3 раза сделал так:
1. создал view archive, который выдает список нод в нужном формате. - группировка по рубрике, время, анонс.
2. Создал панель-страницу, с аргументом %mydate. Другого способа, как получить аргумент в пути - не нашел - либо views, либо panels.
3. В этой панели сделал обработку аргумента - формат даты, и даты + 1 day / либо вывод текущей даты, если аргумент неправильный / его нет.
4. Создание view archive в панели.
DEPENDENT SUBQUERY tn eq_ref PRIMARY,vid
vid вот здесь
на друпал.орг пишут что дело в глубине
чем отличается
«Таксономия: ID Термина (с глубиной)
Таксономия: Глубина ID термина
»
от «Таксономия: ID термина» в этом преставлении?
без глубины однако быстро работает, нормально
Почему, вместо того, чтобы здесь жаловаться на Друпал, не написать патч к модулю Views и не выложить на drupal.org ?
листалка кстати для многих актуальна. такой запрос "order by created desc limit 0,20" на каждом сайте есть. И в стандартном виде он насилует мускул, как только может, а потом ходят слухи что в друпале запросов много
EXPLAIN запустите
Цифры у вас фиговые даже для медленного запроса. Может попробовать mysql памяти побольше дать ?
Памяти и так дал нормально пока - хотелось бы решить вопрос не железом, а логикой, т.к. этот же запрос на обычном десктопе загнется, так как у меня 2 x Xeon E5620.
Как я понял у вас выделенный айпишник, возможно VDS. Такие данные по скорости работы скриптов удручают, здесь mysql явно не при чём.
В том то и дело, что не vds, а дедик.
это проблема друпала - в части генерации турого запроса / неправильной схемы данных, потому что 340к строк прожевать быстро ну никак не получится.
сервер очень быстрый, на вдс такой запрос будет примерно в 20-30 раз медленнее, вот это и удручает.
в карте 170к нод, страшно остальные добавлять - вдруг по новой запустит.
хотя посмотрел на сам файл - вроде норм пишет, обновление в 19.45
меня запись в кроне смутила.
Новостной сайт
Большое спасибо Вам за критику!
CacheRouter - как правильно?
за сутки прироста comment_form не обнаружил, т.е. исправление function ajax_comments_cache_get($cid, $table = 'cache') помогло.
Поставил memcached, настроил CacheRouter на него, полет нормальный.
Единественное, не очень понял что означает вывод memcached-tool 127.0.0.1:11211 stats
в APC теперь хранятся только сами файлы php, ini - нужно примерно 40Мб на 1 сайт друпала.
в cacherouter/engines/memcache.php есть опечатка (версия не дев):
66: if ($expire == CACHE_TEMPORARY || $expire == CACHE_PERMENANT) {
теперь поставил в my.cnf
drupal & nginx
drupal & nginx
возьмите отсюда конфиг, он рабочий http://drupal.ru/node/31807
AJAX комменты
Здравствуйте!
не работает очистка кеша cache_form при использовании cacherouter 6.x-1.0-rc1
С cacherouter 6.x-dev не совместим http://drupal.ru/node/53106
CacheRouter - как правильно?
Кажется я нашел ошибку c cache_form
Проблема не в ядре, а в модуле ajax_comments + cacherouter - кто-то из них работает неправильно
в функции function ajax_comments_cache_get($cid, $table = 'cache') {
сделал //variable_set('cache_flush', 0);
и перенес ее в
CacheRouter - как правильно?
запостил issue в drupal core http://drupal.org/node/978942 - у меня почему-то не чистится cache_form,
без нее весь кеш будет весить немного, попробую memcached, спасибо Вам за помощь!
еще sessions, captcha_sessions непонятно, их кто-нибудь чистит?
вроде не кеш, но сессий уже много накопилось.
UPD: по умолчанию сессии живут 3 недели?:
CacheRouter - как правильно?
boost кстати в базу тоже дохрена пишет, так что, возможно, Crea был прав, что varnish лучше!
просто я на роботах нагрузки не видел, так в принципе все нормально, но сейчас меня такой объем трафика 6 гигабайт в час между сайтом и сервером mysql на localhost не устраивает, я наружу в сто раз меньше отдаю!!
Без кеширования сайт тормозит, а с кешированием мускул насилует.
CacheRouter - как правильно?
Сейчас выключил кеширование views - вроде на производительность вообще не влияет, возможно, я не совсем понимаю, как он кеширует, но запросов к бд у него больше всего.
у меня к примеру 10 views без аргументов, без node access, я полагал, что будет 10 записей в кеше, который обновляется раз в минуту (стоял кеш 1мин / 1 мин).
а на деле получилось 18к запросов за 2.5 часа = 120 в минуту / 10 = 1 запрос раз в 5 сек на каждый view - откуда столько?
CacheRouter - как правильно?
Вообще Cacherouter кто-нибудь применяет?
CacheRouter - как правильно?
сейчас таблицы такого размера: (после очистки кеша)
сегодня, вчера и дата поста
ищите в ядре все функции, которые выводят дату, которую надо заменить - в комментариях, нодах и т.д.
перетаскиваете их в template.php Вашей темы
переименовываете их добавляя название темы function [your_theme]_date()
а там уже вызываете функцию, которую Вам предложили.
drupal + views = медленный mysql
С архивом тоже вопрос решил - вместо длинного запроса, где created проверяется 3 раза сделал так:
1. создал view archive, который выдает список нод в нужном формате. - группировка по рубрике, время, анонс.
2. Создал панель-страницу, с аргументом %mydate. Другого способа, как получить аргумент в пути - не нашел - либо views, либо panels.
3. В этой панели сделал обработку аргумента - формат даты, и даты + 1 day / либо вывод текущей даты, если аргумент неправильный / его нет.
4. Создание view archive в панели.
drupal + views = медленный mysql
Большое Вам спасибо за правильные вопросы. многое прояснилось - и насчет индексов тоже. буду и дальше сюда писать запросы, которые медленные.
Помогите побороть ИЕ6
это жестоко, думаете они сами об этом не знают?
drupal + views = медленный mysql
DEPENDENT SUBQUERY tn eq_ref PRIMARY,vid
vid вот здесь
на друпал.орг пишут что дело в глубине
чем отличается
«Таксономия: ID Термина (с глубиной)
Таксономия: Глубина ID термина
»
от «Таксономия: ID термина» в этом преставлении?
без глубины однако быстро работает, нормально
drupal + views = медленный mysql
листалка кстати для многих актуальна. такой запрос "order by created desc limit 0,20" на каждом сайте есть. И в стандартном виде он насилует мускул, как только может, а потом ходят слухи что в друпале запросов много
drupal + views = медленный mysql
в коде надпись - "получаем список всех материалов" -
ключевая надпись.
drupal + views = медленный mysql
а right join там не предусмотрен?
drupal + views = медленный mysql
Проблема именно в node.vid IN (...) , индексы я смотрел - в node они все есть, прям нечего добавить, вот чтобы было понятно:
node
vid - primary
created - index
title
term_node
vid -> ref to node vid (not unique)
tid - index
primary index=vid+tid
1-й запрос оригинал
select title,created from node where vid in (select vid from term_node where tid=4) order by created desc limit 0,20
drupal + views = медленный mysql
Памяти и так дал нормально пока - хотелось бы решить вопрос не железом, а логикой, т.к. этот же запрос на обычном десктопе загнется, так как у меня 2 x Xeon E5620.
да дело не в этом
drupal + views = медленный mysql
В том то и дело, что не vds, а дедик.
это проблема друпала - в части генерации турого запроса / неправильной схемы данных, потому что 340к строк прожевать быстро ну никак не получится.
сервер очень быстрый, на вдс такой запрос будет примерно в 20-30 раз медленнее, вот это и удручает.
Помогите побороть ИЕ6
вроде модуль есть такой, но я обычный скрипт прописал DD_belatedPNG.js
и вставил его в конец страницы в шаблоне
Помогите побороть ИЕ6
xmlsitemap
в карте 170к нод, страшно остальные добавлять - вдруг по новой запустит.
хотя посмотрел на сам файл - вроде норм пишет, обновление в 19.45
меня запись в кроне смутила.