Стратегії очищення кеш-пам'яті для великих сайтів?

Один з моїх сайтів Drupal 7 має тисячі полів, купу типів вмісту, більше 25 переглядів та сотні (незабаром стане тисячами) типів профілів. Через це я використовую основний патч, який краще кешує інформацію про сутність сутності (http://drupal.org/node/1040790), і -dev версію Views, яка краще кешує перегляди за допомогою відображення (замість того, щоб мати один ВЕЛИЧИЙ рядок кешу переглядів із усіма даними переглядів у ньому).

Це допомогло більшості сторінок на сайті завантажувати 20-30 МБ оперативної пам’яті, а не 160 МБ + (замість того, щоб підтягувати рядки таблиці кеш_ * для полів та переглядів, що були 10 МБ +, виправлення допомагають зберегти дані кеш_ * набагато ефективніше).

Однак це створює проблему в тому, що відновлення кешу займає дуже багато часу . Зазвичай більше хвилини-двох. І за цей час Drupal просто не завантажуватиме жодних сторінок (оскільки кеші, з яких він намагається прочитати, ще не побудовані, інших запитів потрібно чекати).

Під час циклів з низьким трафіком це не велика справа; Сто або більше користувачів просто доведеться зачекати хвилину, перш ніж сторінка завантажиться. Але під час циклів з високим трафіком сервер Apache починає з глузду із завантаженням процесора 40+, і пам’ять швидко заповнюється, тому що всі робочі потоки сидять в очікуванні і збільшують максимум пам'яті, викликаючи заміну. Це свого роду спіраль смерті. Перезапуск httpd очистить речі, але потрібно 5-10 хвилин, щоб вони повернулися до норми.

Моя мета - зробити так, щоб кеш-пам'ять очищалася, не ставила сайт на коліна. Для одного, якщо я використовую індивідуальні функції очищення кеша адміністратора (наприклад, "CSS та JS", потім "Меню", потім "Реєстр тем" тощо), все пройде гладко, поки я не натиснув опцію "Сторінка та інше". Ось тоді кеш переглядів скидається (дуже керована процесором та базами даних робота з кількістю переглядів, які потрібно кешувати), і коли кеш інформаційного поля скидається (що також є процесором та інтенсивним використанням баз даних на цьому сайті).

Отже ... мої запитання / ідеї:

• Чи можна за допомогою барабанного та / або іншого сценарію оболонки очищати кеші більш розумним способом, ніж "вибух всіх кешів відразу і сподіваюся на чисту перебудову"?
• Чи можу я заблокувати запити http, поки відбувається очищення кешу, щоб апаш не забився купою запитів із штампуванням кеша?
• Якщо я можу очистити кеші за межами запиту Drupal / звичайний httpd, я, мабуть, можу встановити більш високий PHP memory_limit для кеш-операції та відключити свій універсальний memory_limit (зараз встановлено 256MB, якщо будь-який окремий потік httpd потребує очищення кеш-пам'яті ...).

В основному: Чи є якийсь розумний і витончений спосіб очистити всі кеші з Drupal, крім того, щоб просто натиснути кнопку в інтерфейсі або використовувати drush cc all?

[ Редагувати для уточнення : Основна проблема, яку я маю, - це відновлення кешу , яке (a) потребує певного часу та (b) блокування всіх інших запитів до завершення відновлення. Я хотів би знайти спосіб зробити так, щоб відбудови не були настільки смертельними в часи великого руху.]

Чи є якийсь розумний і витончений спосіб очистити всі кеші за допомогою Drupal, крім того, щоб просто натиснути кнопку в інтерфейсі або використати drush cc all?

Модуль кеш-дій робить це. Це залежить від правила. Для прикладу, ви можете встановити правило, щоб очистити певний вигляд, коли вузол типу "х" додано чи оновлено. Ознайомтеся з документами для отримання більш детальної інформації.

Також погляньте на витончений модуль кешу - ще не пробували, але виглядає цікаво.

Основна проблема полягає в тому, що ви використовуєте MySQL для зберігання даних кешу - для сайтів з високим навантаженням це дуже неефективне рішення.

Я радимо замість цього використовувати Memcache . Це різко збільшить продуктивність кеш-системи та дасть вам 2 чудових переваги:

1. Memcache набагато швидше для операцій з читання та запису, що MySQL - усі операції кешування (і відновлення повного кешу) будуть працювати швидше.
2. Оскільки дані кешу більше не зберігаються в БД - очищення кеша не заблокує жодних інших запитів MySQL.

Ось приклад конфігурації Memcache для Drupal 7.

Чи можна за допомогою барабанного та / або іншого сценарію оболонки очищати кеші більш розумним способом, ніж "вибух всіх кешів відразу і сподіваюся на чисту перебудову"?

Якщо ви не хочете обробляти всі кеші, використовуйте: drush cc type_of_cacheдля очищення конкретного або визначте власний.

Альтернативно очистити всі таблиці, схожі на кеш, вручну, наприклад

echo "SHOW TABLES LIKE 'cache%'" | $(drush sql-connect) | tail -n +2 | xargs -L1 -I% echo "DELETE FROM %;" | $(drush sql-connect) -v 

Якщо ви використовуєте запам’ятовуваний (синтаксис Bash), спробуйте:

pgrep memcached && echo flush_all > /dev/tcp/127.0.0.1/11211

Чи можу я заблокувати запити http, поки відбувається очищення кешу, щоб апаш не забився купою запитів із штампуванням кеша?

Увімкніть режим обслуговування ( drush -y vset maintenance_mode 1), щоб запобігти доступу людей на сайт. Або налаштувати передній кінець для переадресації кудись інше (наприклад, на лак, перенаправлення в Apache або зміну .htaccess).

Якщо я можу очистити кеші за межами запиту Drupal / звичайний httpd, я, мабуть, можу встановити більш високий PHP memory_limitдля кеш-операції, і відключити свій універсальний memory_limit(зараз встановлено 256 Мб, якщо будь-який окремий потік httpd потребує очищення кешів.) .).

Очищення кешу не потребує більше пам’яті, але відновлення кешу після очищення займе більше. Ви завжди можете розігріти кеші, запустивши cron або відкривши будь-яку сторінку, наприклад

time php -n -d memory_limit=-1 time $(which drush) cc registry
PHP_OPTIONS='-d memory_limit="2G"' drush cron
php -d memory_limit=1G ./scripts/drupal.sh http://localhost/

^{Вкажіть, -nщоб ігнорувати php.iniобробку, що може додатково прискорити процес очищення кешу.}

Можливо, пов'язані грошові витрати, але ви можете використовувати налаштування сервера кешування, як Varnish. Переваги полягають у тому, що Varnish буде обслуговувати ваш сайт, поки ваш кеш очищається на виробничому сервері, без того, щоб користувач був розумнішим.

Мінус: залежно від того, скільки секунд / хвилин простою виробничого сервера та налаштувань часу очікування VCL, лак може оновитись протягом цього часу, і ви побачите екран помилки Varnish 503.

Але такий підхід разом з Redis або Memcache може допомогти.