В попытке снизить нагрузку на сервер было применено управляемое кеширование везде, где только было можно. К примеру, на список объектов недвижимости вешались теги - по одному тегу на каждый объект. В итоге страница с 10 объектами имела 10 тегов. Также с каждым блоком с объектами. Каждая страница объекта имела по одному тегу. За неделю использования тегов накопилось 300 000. И все они находятся в таблице b_cache_tag.
Но технология управляемого кеша в 1С-Битрикс подразумевает обращение к этой таблице, да еще и выборку ВСЕХ записей из таблицы:
Код
|
function InitDBCache() { if(!$this->DBCacheTags) { global $DB; $this->DBCacheTags = array(); $rs = $DB->Query(" SELECT * FROM b_cache_tag WHERE SITE_ID = '".$DB->ForSQL(SITE_ID, 2)."' AND CACHE_SALT = '".$DB->ForSQL($this->SALT, 4)."' "); while($ar = $rs->Fetch()) { $path = $ar["RELATIVE_PATH"]; $this->DBCacheTags[$path][$ar["TAG"]] = true; } } } |
Чем грозит выборка 300 тысяч записей и их распихивание в массив, я думаю, и так понятно. Резкий рост нагрузки на сервер базы данных, при этом куда больший, чем было до применения управляемого кеша. В итоге оптимизация кеширования имела обратный эффект.
Но это не значит, что использовать управляемый кеш нельзя. Вероятнее всего, необходимо его использовать умеренно и на ограниченном типе данных. Например, на housage.com его логично будет использовать только для страниц объектов недвижимости, их всего 9000, при этом установить время кеширования на неделю, например. А для страниц со списками объектов можно использовать стандартное кеширование на сутки. В итоге таблица b_cache_tag будет иметь не сотни тысяч записей, а десяток тысяч записей. И выборка всех записей будет занимать не по 0.5 секунды, а обычные десятитысячные доли секунды.
