Как сделать так чтобы таблица с кэшем в БД не "росла"?

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

Аватар пользователя moonman moonman 23 января 2007 в 21:02

Т.е. мне нужно чтобы кэширование вообще не происходило.
Что нужно изменить или сделать чтобы полностью отключить эту функцию?
Мне очень нужно именно отключить полность.
Друпал 4.7

Комментарии

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 24 января 2007 в 9:53

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

Аватар пользователя clubwave.ru clubwave.ru 24 января 2007 в 11:24

а смысл? чтоб локализация производила завросы пачками при каждом открытии и при достижении 300 хостов выделенный сервер упал?

у вас пространства мало чтоли?

Аватар пользователя moonman moonman 24 января 2007 в 11:52

А у меня нету локализации, на инглише.
И зарегестированных нету.
Смысла в кеше тоже нету.
Портал разросся, нужно где-то образать. Таблица с кешем огромная...
Поэтому мне нужно ее как-то удалить...
Как?

Аватар пользователя clubwave.ru clubwave.ru 24 января 2007 в 12:49

хрен знает.. из моих познаний друпала.. проще забить.. и сколько у тебя бд весит?

если портал для шататов, то проще хостинг в штатах брать и не заморачиваться на размере, там объёмы нереальные выдают за копейки..

Аватар пользователя moonman moonman 24 января 2007 в 13:00

да у меня чисто статейный сайт, на котором 3-4 админа сами пихаем статьи.
Там эта локаль нафиг не нужна, пара слов на инглише всем и так ясно.
Блин чем уважаю Друпаль это за то что поисковики его любят...

Не ну должен же быть способ удалить эту таблицу, откуда-то же эти запросы идут...

Народ кто знает где подправить нада?

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 24 января 2007 в 13:35

Еще раз: Cron включен? Если он включен, то таблица кеш расти не будет (!!!), старые записи будут удаляться "сами собой".

Разве это не то что нужно??

Аватар пользователя smile smile 24 января 2007 в 13:38

эм.....

а что мешает написать свой скрипт, который по крону будет очищать нужные таблицы?

на удаленную - конечно ругаться будет. на пустую - нет.

Аватар пользователя dyp@drupal.org dyp@drupal.org 24 января 2007 в 13:58

<? php
db_query('DELETE FROM {cache}');
?>
Не тестировал, за последствия не ручаюсь. Вставь в page.tpl.php. При каждом запросе страницы кэш будет обнуляться.
ЗЫ Я бы этого делать не стал.

Аватар пользователя moonman moonman 24 января 2007 в 13:59

>>>>Ну да, зато друпал будет КАЖДЫЙ раз заполнять эту таблицу. Будет бооольшая потеря производительности.

Вот-вот...

Зачем иметь одну фигню, потом создавать другую фигню, чтобы избавиться от первой фигни ROFL

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

Аватар пользователя moonman moonman 24 января 2007 в 15:02

>>>>LOL Интересно, я в игноре или слово Cron такое страшное?

Нужно элементарно вырубить запрос к БД на счет таблицы кэша.
Я же вверху написал что зачем это нужно:
1) запросы по поводу создания таблицы с кешем
2) запросы по поводу очищения от кеша.
???

Мне он вообще не нужен этот кеш. Я просто хучу чтобы его не было. И соответственно облегчится сайт.

Крон я не пользую потому что он мне не нужен и кеш мне не нужен.

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 24 января 2007 в 15:14

Крон нужен друпалу, почитайте в системных требованиях (если лень настраивать настоящий крон, можно просто поставить модуль poormanscron).

По поводу "отрубить кеш" уже сказали, что лучше этого НЕ ДЕЛАТЬ, чтобы потом не было сюрпризов (читайте: чтобы "не ловить глюки"). Система кеширования в ядре, и этим все сказано.

(хотя, если есть горячее желание патчить ядро, то успехов Вам!!! в этом начинании...)

Аватар пользователя moonman moonman 24 января 2007 в 15:19

>>>(хотя, если есть горячее желание патчить ядро, то успехов Вам!!! в этом начинании...)

Вопрос то стоял "КАК?"
А дальше уже риск мой Smile
А если Вы уж так не хотите мне помочь то и не нужно, я обратился не именно к Вам конкретно...

Аватар пользователя dven dven 24 января 2007 в 15:19

Сам не пробовал, но если просто убрать в функции cache_set запросы к БД, и возвращать из функции cache_get false?

Аватар пользователя dyp@drupal.org dyp@drupal.org 24 января 2007 в 15:31

''По поводу "отрубить кеш" уже сказали, что лучше этого НЕ ДЕЛАТЬ''
ну ладно, вам пусть человек попробует если он так серьезно настроен.
''А дальше уже риск мой :)''
только плз сообщите о результатах эксперимента )

Аватар пользователя moonman moonman 24 января 2007 в 15:53

Сообщу конечно.
Без проблем.
Только решите что делать то нужно поконкретнее?

Этот вариант уже выглядит довольно практично:

>>>Сам не пробовал, но если просто убрать в функции cache_set запросы к БД, и возвращать из функции cache_get false?

Аватар пользователя dyp@drupal.org dyp@drupal.org 24 января 2007 в 16:14

если я правильно понял идею то в includes/bootstrap.inc

меняем функции cache_set так
<?php
function cache_set($cid, $data, $expire = CACHE_PERMANENT, $headers = NULL) {
}
?>
а cache_get так
<?php
function cache_get($key) {
return 0;
}
?>
хотя cache_get можно и не трогать, т.к. если в кэше ничего не будет, то и возвращать будет 0

Аватар пользователя axel axel 1 февраля 2007 в 11:01

Вот это самый правильный совет. Если уж хочется отрубить кэш совсем, то делать это надо именно так как посоветовал dyp@drupal.org - поправить код, чтобы функции cache_get и cache_set ничего не исполняли и не отнимали лишнее время на свою работу.

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

Не давать таблице cache и другим таблицам сильно расползаться в объеме дает регулярная оптимизация их командой OPTIMIZE TABLE {имя таблицы}.

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Аватар пользователя dven dven 24 января 2007 в 16:18

>>> хотя cache_get можно и не трогать, т.к. если в кэше ничего не будет, то и возвращать будет 0
Думаю лучше сделать - избавляемся от ненужных запросов.

Аватар пользователя moonman moonman 24 января 2007 в 18:51

dyp@drupal.org

Поставил первый вариант - все работает Smile спасибо.

Уникальных у нас где-то около 1000 поэтому если проблемы должны быть то будут в ближайшее время - то отпишусь в любом случае.

Аватар пользователя moonman moonman 24 января 2007 в 20:31

Хостер самый простяцкий: sweb.ru

Ну вот уже где-то 1,5 часа прошло - ничего криминального не случилось.
По ощущениям - явно стало быстрее бегать. Вобщем мне нравится!

Аватар пользователя moonman moonman 1 февраля 2007 в 8:45

>>>Неделя прошла как сайтец поживает? Друпал рулит?

Всё работает.
Но больше всег очто радует это то что я могу быть совершенно уверенным в том, что моя База Данных находится во вполне контролируемых рамках и её размер можно логически предполагать, в отличии от того чтобыло - размер БД скакал как сивая кобыла и была соывершенно не предсказуема (а при моём тарифе к конкретным лимитом на объем диска это имеет значение).

Единственно конечно что обязательно нужно для этого - не должно быть локали и всяких лишних модулей.
Пока имеет 1000 хостов и ни разу не падал. Как выше будет себя вести не известно.

Аватар пользователя moonman moonman 1 февраля 2007 в 13:37

>>axel

Т.е. cache_get лучше изменть так, как написал dyp@drupal.org?

<?php
function cache_get($key) {
return 0;
}
?>

Или не нужно?
А только это:
<?php

function cache_set($cid, $data, $expire = CACHE_PERMANENT, $headers = NULL) {
}
?>

Аватар пользователя axel axel 2 февраля 2007 в 3:22

Да из cache_get тоже все лучше выкинуть - зачем ей в таблицу cache каждый раз с запросом лезть?

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Аватар пользователя kiev1 kiev1 1 февраля 2007 в 21:36

сделал, так, потом обратно включил кеш, не смотря на то что я зашел под админом - то есть по идее кеш и так не работает, но так как было - то есть с кешем работает в полтора раза быстрее чем с отключением таким способом
не понимаю но действительно так

Аватар пользователя axel axel 2 февраля 2007 в 3:23

Очень логично что с кешем работает быстрее.

--
Администратор сайта «Drupal — Россия»
на вопросы по Drupal отвечаю только на форумах, не пишите в почту и приватом!

Аватар пользователя moonman moonman 2 февраля 2007 в 8:00

>>axel

Поставил.

>>Очень логично что с кешем работает быстрее.

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

Аватар пользователя moonman moonman 2 февраля 2007 в 8:12

Работает очень быстро, я не знаю почему тут пишут что медленно.
Смотрел на время исполнения того или иного запроса: в среднем это примерно такие цифры: 0,00004 - 0,0004
И запросов стало меньше, только основные.

Аватар пользователя kiev1 kiev1 3 февраля 2007 в 18:23

> Работает очень быстро, я не знаю почему тут пишут что медленно.

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

Аватар пользователя moonman moonman 3 февраля 2007 в 18:28

>>>потому что у вас на сайте сколько страниц?
Около 3 000.
Запросов к БД недавно смотрел - около 100. Запросы все в диапазоне 0,00004 - 0,0004
Единственно у меня ещё стоит мод pathauto он восновном и даёт эти запросы.
А если без него - то можно можно вообще не волноваться.
Но реально говорю - не падает пока при 1000 уник.

Аватар пользователя ultraboy@drupal.org ultraboy@drupal.org 5 февраля 2007 в 9:33

сказали же:
"Единственно у меня ещё стоит мод pathauto он восновном и даёт эти запросы." Сколько можно вообще эту тему муссировать. Внимательно посмотрите на ссылку что Вы сами дали - ЧПУ-то не-е-ет!