Интересный момент возник. Файл кеширования в дистрибутиве есть.
В конфиге не вижу чтобы он как то подключался.
Делаю по аналогии с 2.3.3 – никаких результатов не видно.
Впихнул в версию файл от дистрибутива 233 – заработало,
запросов попадало где то больше чем вполовину, время генерации
процентов на 10-15% ( по данным с темплаты)
Но это ж не выход, как заставить работать собственный файл.
А нет в 2.5 дискового кеширования. Ваще.
Насчет впихнуть от 2.3 – отличная идея!
Ну как нет , файл то cash.php есть – значит по идее должно и
кеширование быть, вот только как оно работает. Хотя кто их
разработчиков знает. Не успели 251 релиз сделать уже 2.6
бета анонсирует.
А так да, заменил этот файл, конфиг дописал
define(‘WP_CACHE’, true);
define(‘ENABLE_CACHE’, ”);
И заработало, кеш создается, и грузится вроде именно с него.
Чёртечто… 🙁 А я никак не могу понять, почему кэш не пашет. Даже не сообразил взглянуть в cache.php… Похоже кэша действительно нет. Кто-нибудь разбирался с этим? Что пишут разработчики?
Вот что пишут в cache.php
* The WordPress Object Cache is used to save on trips to the database.
* The Object Cache stores all of the cache data to memory and makes the
* cache contents available by using a key, which is used to name and
* later retrieve the cache contents.
Наверно потому и памяти стал жрать еще больше.
Замечательное решение. Главное – оригинальное.
как оказалось решение плохое. я на своих блогах опробовал, пришлось писать в тех. поддержку, чтобы узнать в чем дело. ответ пришел типа:
Интересно, а не работало ли кеширование в 2.3 так же, за что и было уволено? 😉
хз, все может быть. только вот придется ставить какой-нибудь из плагинов кеширования, а это практически наверняка поломает работу каких-то плагинов, чертовски не хотелось этого делать, потому и был испробован вариант со старым cache.php ((
Только что проверил "гибрид". После запуска на пустом кеше записано 46 файлов (20 запросов к базе). Повторная загрузка морды – не создано ни одного файла (9 запросов к базе).
Начало моего дебаг-лога выглядит так:
до создания файлов:
query $query = SET NAMES ‘utf8’
wp_cache_init
wp_cache_get id = is_blog_installed
query $query = SELECT option_value FROM wp_options WHERE option_name = ‘siteurl’
wp_cache_set key = is_blog_installed
wp_cache_get id = notoptions
wp_cache_get id = alloptions
query $query = SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’
wp_cache_add key = alloptions
wp_cache_get id = notoptions
wp_cache_get id = alloptions
wp_cache_get id = notoptions
после:
query $query = SET NAMES ‘utf8’
wp_cache_init
wp_cache_get id = is_blog_installed
wp_cache_get id = notoptions
wp_cache_get id = alloptions
wp_cache_get id = notoptions
wp_cache_get id = alloptions
там потом будут проблемы – с новой сессией.
в начале то я тоже радовался уменьшенному количеству запросов, но потом это меньшее количество стало боком.
Ну по идее правильно. Идет запрос к кешу – если он новый выводится кеш, если он старый ( по времени), запрашивается база – создается новый кеш.
Как по другому это работает?
Никто же не заставляет включать его сразу при малой нагрузке.
тогда кеш всегда будет старым, так как на момент запроса страницы кеш уже устарел по времени создания.
Не смешно, кеш создается с разрывом по времени.
Время создания+время хранения до устаревания.
Время хранения можно уточнить по скрипту файла.
В вашем случае непонятно. Вы говорите запросы в базу все равно идут,
те они не должны уменьшится, а по факту WP показывает, что их меньше.
Нелогично.
Когда потом, когда кеш устареет? Правильно, пересоздаст. Ну так это его принцип работы – какое-то время хранить инфу в файлах.
Не всегда, а через 900 секунд.
нет – имеется ввиду, что для каждого посетителя создается свой кеш – отсюда и постоянное переименовывание файлов кеша под конкретного посетителя и тормоза при открытии (до 30сек) когда несколько человек просматривают сайт.
именно в этом проблема имхо, но конечно могу ошибаться.
да и визуально – то WP показывает 7 запросов вместо 40 (кеш), то через 5 минут опять все 40 – а самое интересное, что иногда показывает 60 запросов, хотя на главной всего 30 их выполняется.
в общем – идея запихнуть старый cache.php не подходит к новой версии WP – что там внутри теперь не так.
Не нравится – не ешь 😀
Испытываю непреодолимо желание попросить рассказать, что именно "не так". Ну да ладно.
если бы я знал что не так – я бы это исправил )))
пока что имеются факты – работа таким образом с кешем вызывает тормоза при открытии страниц. я грешил на хостера, но как видно по ответу тех. поддержки кеш должным образом не работает. и частенько количество запросов вообще превышает в 1.5-2 раза количество существующих запросов.
насчет не нравится не ешь – мне идея такого простого включения кеша чрезвычайно нравится. но как при этом решить возникающие проблемы?
Может быть все же проблема то в хостере?
Кто ж признается в оверселлинге, и перезабитости своего сервера, что не хватает ресурсов.
Вылез тут у меня неприятный момент при тестировании VPS, и довольно мощного. 5 сайтов на joom вполне нормально работают при прсещаемости суммарно где то 1000 в день.
Зато 4 wp новых 2.6 (без изменений) при суммарной посещаемости 400 рыл, просто кладут такой же – серверу не хватает ни проца ни памяти. В панели видны зашкаливания по процу и требуемой памяти. Время начинает меняться от 0,35 с до 50-60 сек.
И ведь это учесть что joom по запросам к базе вообще прожорливая.
Характерно, что внеся изменения по кешированию положение улучшилось намного, за этот месяц зарегистрировано только 4 максимума.
Поэтому и предложил данный метод.
PS/ Сейчас уточнил у своего хостера, где на шареде висят 6 вордпрессов, в тч 3 измененых – говорит проблем с нагрузкой у тебя нет.
сомневаюсь, что проблема в хостере. зенон не самый дешевый хостинг на рынке. у него есть свои заморочки, но качество хостинга у них традиционно на высоте. да и проблема не в нагрузке на сервер, с этим проблем замечено не было, а именно в том, что кеш работает не так, как ему положено. не спорю – может он из-за каких-то настроек у хостера не работает как надо, то хз в какую сторону копать то.
Flector, честно говоря, из приведенного Вами сообщения суппорта лично мне совершенно не видно, что кеш работает "не так". А фраза "странно очень используется: сначала генерируется, а потом используется" вообще меня крепко озадачила. Неужто сначала кеш должен использоваться, а уже потом генерироваться? Или их смутило переименование временного файла? Так это в общем правильный подход, позволяющий избежать коллизий множественной генерации.
Тут надо бы отметить, что файловое кеширование имеет смысл только тогда, когда основным тормозом на хостинге является база. Если база работает шустро, то файловое кеширование может оказаться просто тормозом.
Flector, а знаете что, проверьте-ка как на Вашем хостинге отрабатывает функция filemtime(). Если она возвращает "смещенное" относительно time() время, то может получиться так, что кеш постоянно устаревший, и тогда действительно будет черти что.
а как проверить? пробую что-то типа
дата создания файла указана верно, текущее время тоже верно.
Проблема кэша в WordPress прежде всего в том, что у него есть некий объект, который распихивается по все файлам. Поэтому в принципе ситуация действительно может получиться, как описывает Flector. Ведь вы не смотрели, что именно изменилось в 2.6, а скажем для того, чтобы такое случилось достаточно всего лишь по другому сформировать ключ кеша. Например в нем следует указать группу, которая разделена на массив в массиве, где каждый элемент кидается в файл. Я, конечно же сомневаюсь, что разработчики WordPress потрудились как положено над кэшем, и просто удалили файловую часть, оставив сам обхект, но в теории, ситуация, когда кэш (или какая-та его часть) генерируется для каждого посетителя вполне реальна.
И проблема, кстати, может быть еще и не сколько в самом кеше, сколько в его использовании. Ну например какой-то плагин/функция использует кэш и сам вызывает его обновление. Но чтобы это проверить придется перелопатить все вызовы функций кэша.
Да и еще. Зенон – хостинг еще тот. Там ребята любители поэкспериментировать, поэтому не следует исключать, что проблема в хостинге. Попробовать, скажем, на другом сервере.
> что именно изменилось в 2.6
В сабже 2.5.1 🙂
Интерфейсная часть cache.php:
2.3.3
function wp_cache_add($key, $data, $flag = ”, $expire = 0)
function wp_cache_close()
function wp_cache_delete($id, $flag = ”)
function wp_cache_flush()
function wp_cache_get($id, $flag = ”)
function wp_cache_init()
function wp_cache_replace($key, $data, $flag = ”, $expire = 0)
function wp_cache_set($key, $data, $flag = ”, $expire = 0)
2.5.1
function wp_cache_add($key, $data, $flag = ”, $expire = 0)
function wp_cache_close()
function wp_cache_delete($id, $flag = ”)
function wp_cache_flush()
function wp_cache_get($id, $flag = ”)
function wp_cache_init()
function wp_cache_replace($key, $data, $flag = ”, $expire = 0)
function wp_cache_set($key, $data, $flag = ”, $expire = 0)
2.6
function wp_cache_add($key, $data, $flag = ”, $expire = 0)
function wp_cache_close()
function wp_cache_delete($id, $flag = ”)
function wp_cache_flush()
function wp_cache_get($id, $flag = ”)
function wp_cache_init()
> достаточно всего лишь по другому сформировать ключ кеша 😉
Пока разницы не увидел. Для желающих копать глубоко-глубоко в cache.php от 2.3.3 есть строка //$this->stats(); Если убрать комментарий, то вываливат на страницу столько инфы по кешу, что мало не покажется. 🙂
Коллеги, я тут от душевного расстройства (по поводу ремонта тещиной китайской электронной лампы дневного света) набросал… не-а, не угадали, не плагин. Но близко. Это кешировалка для WP 2.6. Простая как грабли. Однофайловая. Кеширует всё, что попадется.
Инструкция:
– скачать архив http://www.portal.kharkov.ua/soft/object-cache.zip
– файл object-cache.php положить в /wp-content/ (2.6 сам его найдет и задействует)
– директория /wp-content/cache или другая, указанная в CACHE_PATH, должна существовать и быть доступной для записи
CACHE_EXPIRATION_TIME по умолчанию 3600 секунд. Кеш пересохраняется всякий раз, как попадется что-то новенькое. На копии моего блога размер файла кеша получился порядка 200 килобайт.
Проверял только на локальной винде, на унихах нет ни одного подопытного 2.6.
а заменять cache.php в 2.6 от версии 2.3 при этом надо?
А пофигу 🙂 В 2.6 если есть WP_CONTENT_DIR/object-cache.php, то используется он, иначе штатный cache.php.
а на 2.5.1 пахать будет?)
Вроде противопоказаний нет. Пробуйте.
То есть весь кэш в один файл?
Ага, всё гамузом.
Понял.
Вот набросал свой вариант. Переделал из своей MaxSite CMS. Проверял на WordPress 2.3.3. У кого есть возможность/желание гляньте на новых версиях. http://maxsite.org/go/maxsite_cms_cache.zip (архив распаковать в "wp-content", на каталог "maxsite_cms_cache" сделать 777).
Посмотрел на 2.6.1. Все работает, кроме одного "но" – пост после создания при работающем кеше не поддается редактированию. Обнуление папки maxsite_cms_cache не помогает 🙂
Проблема решается временным (на время редактирования) изъятием файла object-cache.php 🙂
не смертельно, но неудобно.
С уважением,
Александр Башкиров
Вот последний мой вариант: http://maxsite.org/go/maxsite_cms_cache.zip Правда все равно это фигня: если у меня в системе кэширование используется почти во всех ресурсоемких функциях, то в WordPress’е этого просто нет. Поэтому что есть кэш, что нет…
Ставила вариант Ю.Б. http://forum.maxsite.org/viewtopic.php?pid=29792#p29792 и посл. вариант Макса
все отлично работает на 2,5,1 — количество запросов существенно снизилось: минус 14-30 от изначальных 28-90
Попробовал последний вариант Максима и вариант Ю.Б.
Последний вариант Максима работает и в "контентной части", и в "админке" (в том числе – на редактировании постов, где "обломалась" предыдущая версия).
Вариант Ю.Б. по ощущениям более быстрый, но обламывается в "админке" при редактировании поста – то есть показывает верхнее меню, а дальше – белый лист 😉
Sonika, Вы пробовали с вариантом Ю.Б. редактировать пост?
Да, все окей, сейчас стоит версия Макса — никаких проблем в админке.
wp 2.5.1
Мне сообщили 😉 что с моей кешировалкой при заливке на хостинг новых плагинов список в админке остается старый. Граждане, будьте бдительны!
Sonika, если не секрет, какое время жизни объекта в кеше Вы выставили?
Просто никак не могу понять – почему с кешем у меня тормоза…
Bask, ничего не выставляла — как был файл (кот. скачала выше), так его и залила на сервер
пробовал варианты Ю.Б. и Макса – оба снижают "видимые" запросы, но через час-два сайты начинают безбожно тормозить и время запросов увеличивается в 2-3 раза. После отключения кэша – переименования файла object-cahce все снова начинает работать быстро, но с обычным количеством запросов. такчто палка о двух концах. пробовал на 251 и 262 на своем сервере и паре хостингов
Блин, Ваня, все мои розовые мечты развеял 🙂
А ты точно уверен что тормоза именно из-за этих кэшировалок?
Ваня, а до какого размера раздулся файл кеша?
У меня цифры следующие:
– с вариантом Максима кеш порядка 2Мб
– с вариантом Ю.Б. – 1,8 Мб
кеш Максима работает примерно с 15 сентября. Кеш Ю.Б., как я писал, по ощущениям более быстрый – но не дает редактировать посты. (Моих заний WP для решения недостаточно 🙂 )
для решения "тормозов" в кеше Максима попробовал следующее:
– поотключал лишние плагины (давно пора, да лень было)
– особенно "налег" на плагины статистики, которые просто не использую или пользую редко
– увеличил время жизни кеша до 36000 (все равно я обновляюсь раз в 2..3 дня, в лучшем случае)
в итоге жить стало несколько легче. Но тормоза все равно остались.
Только что проверил, редактируются посты как миленькие (2.6.2). И плагины свежеподкинутые видны. Странно это. Надо будет закинуть куда-нибудь на хостинг, проверить в боевых условиях.
Все оказалось банально: снес Google Gears под Linux и Windows, все в итоге заработало. То есть, в 2.6.2 работает и кеш Максима, и кеш Ю.Б. показатели скорости – прежние. То есть кеш Ю.Б. – быстрее по ощущениям)))
интересный пост появился на днях про кэширование в ВП, его тотальное отключение и т.д.
собственно вот ссылка http://blog.sjinks.org.ua/wordpress/410-monstrosa-horribilis/
есть ли у кого нибудь мысли относительно того что там получились такие огромные числа?
По поводу отключения "кеша", если "добавить return false;". Есть старый хороший анекдот про рабочих и бензопилу. Рассказать или все и так знают?
расскажи!
Привезли рабочим бензопилу.
– О, бл…,- удивленно сказали рабочие. И принесли рейку.
– Бзык!- радостно сказала пила.
– О, бл…,- удивленно сказали рабочие. И принесли доску.
– Бзыык!- радостно сказала пила.
– О, бл…,- удивленно сказали рабочие. И принесли брус.
– Бзыыык!- радостно сказала пила.
– О, бл…,- удивленно сказали рабочие. И принесли шапалу.
– Бзыыык!- радостно сказала пила.
– О, бл…,- удивленно сказали рабочие. И принесли рельс.
– Бзыыыыхрррр…- удивленно сказала пила.
– А, бл…!- радостно сказали рабочие.
прикольно. ну а если серьезно откуда там взялись эти повторяющиеся как в истории строки в логах запроса?
От запросов опций. В обычном режиме, бишь с кешом, все опции, отмеченные как автозагружаемые, сразу вынимаются из базы и сохраняются в "кеше". Если якобыкеша нет, то посланный за любой опцией get_option пытается загрузить все опции в кеш. И так каждый раз, когда идет запрос значения опции.
тогда если уже "кэш есть", то тогда зачем придумывают еще "костыли" для включения кэша ? например такие как ваши с Максом object-cache
меня вот это интересовало в общем.
А дело в том, что это не совсем кеш. Или совсем не кеш. Данные кешируются только на время выполнения скрипта, на один сеанс. Мой костыль делает этот кеш, так сказать, долгоиграющим, сохраняя его на винт. Поэтому данные, собранные одним скриптом, доступны другому. Типа по наследству передаются и дополняются.
В вышеозначенной статье, кажись, упоминается возможность хранения этого кеша в шаред мемори. Идея хорошая, только я не знаю, как ее можно реализвовать (разумеется, на своем сервере, на хостинге никто не даст такое делать, и правильно, кстати, сделает).
А вот и не угадали! 🙂
Вообще я хочу сказать, что Владимир (автор сайта?) не до конца разобрался. Я конечно понимаю, что оптимизация sql на ровне order by и group by великая вещь :), но жаль не столь принципиально, как видится автору.
Так вот. Проблема большого количества запросов в таксономии. Я не одну бессонную ночь провел изучая это нововведение (в 2.3) и скажу, что там мрак.
Так вот. Проблема начинается, когда у вас много записей, и при этом много рубрик и, что самое важное – подрубрик. Обход дерева выполняется рекурсивно и это порождает гиганское количество запросов, потому что обходится каждая рубрика столько раз, сколько самих рубрик. А если есть подподрубрики, то там вооще хавайся – геометрическая прогрессия получается. 🙂
Проблема решается путем кэширования. Пока был файловый кэш, все работало как в теории: фиг с ним, с 1000 запросами, зато остальные потом вообще не тратят sql-запросы. Когда же файловый кэш убрали, то теперь вообще непонятно где и что хранится.
А что касается опций, то на них как раз и не тратится так много. Насколько я помню там вообще один запрос используется. Сами опции так устроены, что если их нет в кэше (читай – в памяти, обычной переменной), то только в этом случае пойдет запрос к базе. Следующая опция уже возьмется из переменной.
Макс, ты прав, один запрос на все автолоад-опции и по одному на каждую остальную. Если не трогать руками. Но автор статьи пришиб сохранение опций в псевдо-кеше. И.. "А!.." сказали рабочие 🙂 А в штатном режиме – таки да, в основном по дереву лазит.
Кстати про shared-память я ничего не понял… Смысл лепить горбатого? Файлового кэша мало что ли? Если кэш нагенерируется на 2 мега и все это загонять в память, то хостеры очень быстро взвоют от такого мегапотребления. 🙂
Я когда делал кэш для MaxSite CMS, испробовал разные варианты и сейчас сделал еще проще. Файловый кэш используется кем угодно, например плагинами. Там физически считываются файлы потому что обычно плагин вызывается один раз за вызов страницы. А вот для опций, поскольку их много, все хранятся в одной куче (файле). Дальше так: при инициализации системы происходит считывание этого файлового кэша в глобальный $cache_options. Дальше просто – все обращения за опциями уже из переменной (это обычный массив). То бишь даже файл кэша уже не елозится.
Вывод. Ну его нафиг: WordPress! Все переходим на MaxSite CMS! (стихи!)
Подскажите, а почему при включеном WP-Supercace сильно забивается оперативка на VDS? У меня 300 человек онлайн и занято примерно 700 мб оперативной памяти?
Вы считаете, что это много?
Ага, у меня всего 1Гб оперативки, а при отключеном суперкеше оперативка почти свободна, зато проц выедает почти весь лимит в 1200Мц, и сервер падает. Нашла еще упоминание о плагине WP FileCache, может, кто-то его использует на своем сайте?
Как он влияет на железо? Имеет ли смысл его ставить? И как он соседствует с Суперкешем?
Неужели никто не использовал WP FileCache на реальном сайте?