WP File Cache: долговременное кэширование в WordPress
Повышение производительности WordPress в один клик
Как известно, WordPress поддерживает два вида кэширования: Кэширование на уровне страниц; Кэширование на уровне запросов. Кэширование на уровне страниц WordPress поддерживает, но самостоятельно не реализует, вследствие чего приходится использовать сторонние плагины (Hyper Cache, WP Super Cache и т.д.). При всех достоинствах постраничного кэширования, у него есть несколько недостатков, а именно: невозможность использования динамических элементов (например, captcha, [...]
← Вернуться к полной версии записи «WP File Cache: долговременное кэширование в WordPress»…
Автор: Vladimir;
Комментарии к статье «WP File Cache: долговременное кэширование в WordPress» (299) »
Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.
Оставить комментарий к записи «WP File Cache: долговременное кэширование в WordPress»
गते गते पारगते पारसंगते बोधि स्वाहा
Всё ок, спасибо.
У меня и так стоит ограничение в 256м. Блин, фигня какая-то((
Не знаю, из-за ICS или из-за WP-File-Cache, но только что был песец глобальных масштабов.
на главной странице пропали все посты, в категориях 404 ошибка. В админку не пускает, говорит неверный логин пароль, не восстанавливает пароль. Отключил все плагины, запустил все, кроме двух(ICS File Cache), удалил ICS, включил file cache, очистил кэш и всё ок, работает. значит ICS так плохо работает с file cache. Кстати, без включенного file cache ICS не активируется.
Спасибо большое Владимир – всё работает.
Вот средние результаты замеров на WP 3.0.3 (без MultiSite):
0.354 c
0.674 c
0.232 c
0.298 c
0.259 c
0.341 c
SJ Object Cache (анонимный юзер без куков)
SJ Object Cache (с куками залогиненный юзер)
WP File Cache (анонимный юзер без куков)
WP File Cache (с куками залогиненный юзер)
Без кэша (анонимный юзер без куков)
Без кэша (с куками залогиненный юзер)
Замеры отображаются с помощью следующего кода:
Так же оба кэша (SJ Object Cache и WP File Cache) прекрасно работают на WP 3.1-beta2-16936 в режиме MultiSite.
Оба движка расположены на виртуальном хостинге (shared hosting).
Алексей, если Вы со включенным WP File Cache перейдёте на дочерний сайт, с высокой вероятностью можете потерять данные. WP File Cache не знает о том, что сайт не один, соответственно кэш будет один для всех.
Спасибо за предупреждение. Дочерних сайтов нет. Да и сам движок как испытательный полигон, поэтому не так страшно.
Кстати очень интересная мысль проверить это на практике. Возможно вскоре этим и займусь. О результатах отпишусь в комментариях.
P.S.
Было бы неплохо подправить код, с помощью которого отображаются замеры.
Спасибо, поправил. Надеюсь, не сильно наврал — письмо пришло уже без кода.
Огромное спасибо за пост, всё работает ))))
Здравствуйте, Владимир, я скачал последнюю версию WP File Cache и поставил себе на сайт http://www.yarmi.ru. Время генерации главной страницы не изменилось и осталось, где-то, в пределах 0,3-0,4 с, а вот количество запросов к базе резко увеличилось с 37 до 71-72. При повторных загрузках страницы результат тот же. Все лишние плагины отключил. В чем причина?
Кэш создаётся?
Да, создается. Обновился на днях до Wordpress 3.1 – ситуация поменялась: после очистки кэша кол-во запросов резко возрастает до 70-100, при повторной загрузке падает до 10-16. Такая вот метаморфоза
Ярослав, попробуйте SJ Object Cache — он лучше работает с WP 3.1
Спасибо, все работает:)
Привет!
А адсенс будет работать?
Ну у меня работает.
Владимир,
спасибо за прекрасный плагин. кол-во запросов упало в 3раза (с 60 до 20)!
но к сожалению на времени генерации страницы это не отразилось (. как было до 0.6-0.8сек, так и осталось
по этому поставил также wp super cache – совместная работа с File Cache грозит какими-нибудь проблемами? или посоветуйте что-то вместо super cache
пока результаты такие (время генерации страницы,сек / запросов):
без всего: 0.6-0.8 / 60
super cache (Use PHP)0.2-0.4 / 60
File Cache 0.6-0.8 / 20
File Cache +super cache (Use PHP)0.2-1.2 / 20 – несколько смущает, что иногда время получается больше чем даже без кэшей вообще. можете как-то прокоментировать?
“для увеличения производительности имеет смысл размещать кэш на RAM-диске”,
подскажите, пожалуйста, если БД (не сжатая) занимает 10мб, RAM-диска 16мб будет достаточно?
как поведет себя WP File Cache, если объем RAM-диска будет исчерпан?
Кэш — это не бесплатное повышение производительности: он смещает нагрузку. В данном случае он разгружает процессор/частично память, но загружает дисковую подсистему. Если сервер виртуальный, то с вводом/выводом у него, скорее всего, плохо.
Пока никто о проблемах не сообщал.
Посмотрите на размер каталога с кэшем — это поможет определиться с размером диска. Тут дело в том, что данные переводятся в строку при помощи функции
serialize()— в результате строковое представление может быть на треть больше, чем исходное.Не будет записывать то, что не помещается на диск. В результате данные, которые не могут быть сохранены в кэш, будут загружаться из базы данных.
я привильно понимаю, что если БД стоит на отдельном сервере (не на том на котором Вордпресс), то File Cache разгружает процессор именно сервера БД?
суть разгрузки процессора состоит в том, что вместо обработки ГРУППЫ SQL запросов (все запросы при генерации одной страницы сайта, например), File Cache берет с диска уже сформированный кусок данных (или под каждый запрос формируется свой файл в кэше)?
“привильно” – читать как “правильно” (:
Да.
По-разному. Вообще всё зависит от WordPress и плагинов. В случае с таксономиями может кэшироваться результат нескольких запросов, но чаще один запрос — один файл.
извините невежду, последний вопрос:
а в чем тогда собственно “секс” – как я понимаю к СУБД ушли от файлов т.к. СУБД: компактное структурированное хранение данных с целью МАКСИМАЛЬНО БЫСТРОЙ ВЫДАЧИ по запросу? а File Cache получается наоборот из БД данные перегоняет в файлы?
Анатолий, а тут уже всё зависит от самой базы и СУБД, и от того, как это дело масштабируется под нагрузкой.
Да, в базе искать быстрее, чем в файле. Но если запросы одни и те же, да и данные шибко не меняются, то проще достать результат из кэша, нежели гонять СУБД (фактически сервер устанавливает соединение, шлёт запрос; СУБД компилирует этот запрос, натравливает на него оптимизатор, читает данные из таблиц, проводит фильтрацию, отдаёт результат серверу).
Будет желание — поставьте плагин SQLMon и посмотрите, сколько времени тратится на запрос. Затем сравните с тем, за сколько тот же результат читается из файла.
спасибо, за детальное разъяснение (:
This plugin rocks! I used it to help me save resources and concurrent connections on my server and it has completely worked and helped me save $$$MONEY$$$. As soon as I can I will make a donation to you if you accept them. And, I will do a write about this plugin and give you a good link.
Thank you. Thank you. Thank you.
Welcome!
Does this plugin work with the Quick Cache Plugin?
Yes, I think so. Although I have never tried.
Я прошу прошения. Я недавно писал о своей проблеме, но все же. У меня постоянно слетает генерация карты сайта от гугла (плагин google xml sitemap) выдает такое
Fatal error: Allowed memory size of 262144 bytes exhausted (tried to allocate 31114 bytes) in /var/www/u02269/data/www/sweatego.ru/wp-content/plugins/wp-file-cache/lib/class.FileCache.php on line 193
или белый экран. Помогите,пожалуйста
Смотрите настройки PHP
явно говорит о том, что где-то что-то не так настроено.
262144 bytes — это 256 килобайт, WordPress требует явно больше (по умолчанию он пытается выделить себе 32 мегабайта).