SJ Object Cache: еще более быстрое объектное кэширование для WordPress
Делаем WordPress еще быстрее
После года тестирования наконец-то вышла первая стабильная версия плагина SJ Object Cache. SJ Object Cache — альтернатива плагину WP File Cache, поддерживающая APC, eAccelerator, xCache, Zend Disk Cache, Zend Shared Memory Cache, memcache и memcached. В отличие от WP File Cache, SJ Object Cache ориентирован на VPS/VDS и выделенные сервера. Одним из недостатков WP File Cache является [...]
← Вернуться к полной версии записи «SJ Object Cache: еще более быстрое объектное кэширование для WordPress»…
Автор: Vladimir; опубликовано в: Плагины WordPress; метки: APC, eAccelerator, Memcache, Memcached, SJ Object Cache, WordPress, WP File Cache, xCache, кэш, плагинОкт
2010
Комментарии к статье «SJ Object Cache: еще более быстрое объектное кэширование для WordPress» (159) »
Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.
Оставить комментарий к записи «SJ Object Cache: еще более быстрое объектное кэширование для WordPress»
गते गते पारगते पारसंगते बोधि स्वाहा
Меня зовут Владимир, я программист-фрилансер, специализирующийся на Web-программировании и програмировании под Linux.
По совместительству занимаюсь администрированием LAMP/LNMP-серверов и техническим переводом.


Здравствуйте, есть ли какие-нибудь отличия вашего решения от плагина “db-cache-reloaded”, который в разы снижает количество запросов к базе и ускоряет загрузку страниц http://wordpress.org/extend/plugins/db-cache-reloaded/?
DB Cache Reloaded — это хак над базой данных, у которого много ограничений (он не работает в админке, не умеет работать со сложными запросами, может привести к рассинхронизации кэша и базы данных).
SJ Object Cache — это реализация официального WordPress Cache API. Но в отличие DBCR, для того, чтобы кэш работал, программист должен использовать это API. Если плагин лезет к базе данных самостоятельно, а не через стандартные функции WordPress, либо использует в запросах свои собственные таблицы, но не использует WP Cache API, SJ Object Cache не поможет.
Здравствуйте.
Мой сайт (wordpress, wp super cache + DB Cache Reloaded) со средней посещаемостью 5000-6000 тыс человек в сутки. Сервер – хороший VDS с apache, nginx и eaccell 0.9.6. Очень бы хотелось заменить связку wp super cache + DB Cache Reloaded на SJ Object Cache. Понимаю, что eaccell 0.9.6 не походит и нужно делать даунгрейд. Но уж очень заманчивой показалась производительность вашего сервера с SJ Object Cache.
Можно ли помочь с настройкой SJ Object Cache. Согласен на любых условиях.
Любопытно, но с этим плагином на выделенном сервере скорость загрузки страниц увеличилась примерно на 15%, но кол-во запросов к базе упало на 50%. Используется Xcache.
Здравствуйте
У меня стоит wordpress 2.3.3. На нем будет работать ваш плагин SJ Object Cache или надо обновляться до более новых версий?
Не будет. Нужен где-то 2.8
Два вопроса/предложения.
1.
Использую Ozh’ Admin Drop Down Menu.
Меню SJ Object Cache находится не в меню Settings, а отдельным пунктом – при этом Ozh’ Admin Drop Down Menu “расползается” на 2 строки при ширине окна 1280 пикселей (см. файл).
Есть ли возможность вызывать настройки плагина подобно wp super cache – через /wp-admin/options-general.php?page=sjobjectcache&tab=generic ? (В параметр tab прячется конкретная страница настроек – generic, filecache, xcache, …) Тогда меню SJ Object Cache аккуратно спрячется под Settings.
2.
Не смог найти этот плагин из самого WP (Plugins -> Add new). Есть ли плагин на wp.org/extend/plugins/, и планируется ли его там разместить?
menu.png
1. Можно попробовать.
2. Да, только он там будет под другим именем.
спасибо, прошу как-то сообщить (скажем, комментарием здесь) о появлении на wp.org
Здравствуйте.
Использую плагин SJ Object Cache на stand-alone блоге.
Параметры дед. сервера: nginx + php-fascgi + memcache и тд
Версия WP: 3.0
Когда плагин активен, при добавлении поста, почему-то по дефолту прописывает категорию ‘Новые заметки’, хотя на самом деле в посте явно указанна другая. При сбросе кэша (очистка в ручную или после TTL) всё становится на свои места.
В чем может быть проблема?
PS: WP File Cache не вызывает этих проблем с категорией.
Alex, попробуйте эту версию: http://d.sjinks.pro/wordpress/sj-object-cache-1.3.zip
Недавно поставил себе плагин W3 Total Cache. В настройках включил кэширование в Memcache для страниц сайта. Время отдачи закэшированных страниц уменьшилось с 2-3 до 0,5-0,6 секунд по сравнению с Hypercache. В вашем плагине есть такая возможность или он кэширует только объекты и запросы к базе? Вообще, по функционалу он сильно отличается от W3 Total Cache?
Олегъ, он кэширует все, что ему говорят кэшировать. WordPress кэширует только объекты/запросы, но при желании можно кэшировать всё, что угодно. Всё дело в использовании API. Так как мало кто его испольует, результаты могут получаться хуже.
По поводу W3 Total Cache: поставьте nginx, настройте кэширование через fastcgi_cache/proxy_cache, получится быстрее, чем W3 Total Cache
Да. Он решает только одну задачу: объектное кэширование (смею надеяться, что решает хорошо). W3 Total Cache пытается решить много задач, большинство из которых решается грамотным конфигурированием сервера.
Я позволил себе небольшой эксперимент:
ab -n 1000 -c 20 -r http://blog.sjinks.pro/ab -n 1000 -c 20 -r http://www.benatar.ru/У меня стоит кэширование nginx, у Вас — W3TC, выводы делайте сами
Вывод простой – ваш выделеный сервер намного круче самого дешевого хостингового тарифа от ht-systems, которым пользуюсь
На VDS сервере нашей компании я давно уже поставил nginx. На ht-systems мне этого никто сделать не даст, поэтому и интересуюсь плагинами кэширования
Понятно
Я думал, что у Вас выделенный сервер…
Посмотрите в сторону WP Super Cache в режиме генерации статических страниц. А еще, возможно, помогут эти обзоры:
Последние два теста проводились на виртуальном железе.
И еще для сравнения:
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Finished 10000 requests
Server Software: nginx
Server Hostname: blog.sjinks.pro
Server Port: 80
Document Path: /
Document Length: 52021 bytes
Concurrency Level: 200
Time taken for tests: 47.231 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 522070000 bytes
HTML transferred: 520210000 bytes
Requests per second: 211.72 [#/sec] (mean)
Time per request: 944.624 [ms] (mean)
Time per request: 4.723 [ms] (mean, across all concurrent requests)
Transfer rate: 10794.43 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 145 218.3 129 4195
Processing: 414 793 229.5 704 3211
Waiting: 17 128 34.3 127 939
Total: 431 938 317.2 836 4997
Percentage of the requests served within a certain time (ms)
50% 836
66% 918
75% 980
80% 1063
90% 1297
95% 1357
98% 1586
99% 1984
100% 4997 (longest request)
200 параллельных потоков, 10,000 запросов; из них 75% запросов выполнилось менее, чем за секунду.
Так что если Вам нужна именно производительность, смотрите в сторону кэширования средствами web-сервера, а не плагинами WordPress.
Спасибо за ссылки, эти статьи я прочитал в первую очередь.
Проблема в том, что на ht-systems суперкэш после обновления вордпресса до 3 версии создал зверскую нагрузку. Поставил гиперкэш.
На днях хостинг начал тормозить снова. Стал искать систему кэширования, которая умеет пользоваться memcache, благо он на хостинге есть. Тогда и нашел W3. Еще очень заинтересовало, что плагин умеет кэшировать объекты, запросы и т.д. Скорость немного подросла, но как-то неравномерно – одни страницы грузятся мгновенно, других секунд по 10 ждать надо.
Потом попал на вашу страничку. Стало интересно. Думаю, на днях попробую ваш плагин.
Олегъ, смотрите в сторону BatCache. wordpress.com его активно использует.
Здравствуйте
Прочитал вашу статью, решил поставить на сервере кеширование через fastcgi_cache. Поставил, не я, админ. Получил увеличение скорости загрузки сайта, видно невооруженным глазом, особенно в период самой большой нагрузки, вечером. Но начались проблемы – в некоторых браузерах одни иегоглифы. Исправили вроде, но видно не все, потеря посетителей 5-7 процентов. Плюс к этому начались проблемы с плагином меток. В админке, в посте, показать все метки, метки то появляются, то исчезают, то иероглифы. Скачать сайт wget – иероглифы. Плюс еще проблемы… Жалко, но пришлось отказаться от такого кеширования. Искал решение этой проблемы, оказывается не только у меня одного такое. Решения не нашел. Подскажите где искать проблему или надо большой напильник для настройки?
Эдуард, а можно как-нибудь посмотреть на конфигурацию, выполненную администратором? Я постараюсь вечером выложить свой конфиг.
Вот конфигурация
gzip_min_length 1100;
gzip_buffers 64 8k;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_disable Wget Pingdom.com;
gzip_types application/xml application/x-javascript text/css text/plain;
access_log off;
client_max_body_size 512m;
server_tokens off;
fastcgi_cache_path /nginx_cache levels=1:2 keys_zone=fastcgi_cache:32m max_size=512m inactive=1d;
server {
listen :80;
server_name site www.site;
root /home/sites/data/www/site;
index index.php index.html;
rewrite ^(/manager/.*)$ https://$host$1 permanent;
location ~* ^/(webstat/|awstats|webmail/|myadmin/|manimg/) {
proxy_pass http://:8080;
proxy_redirect http://test.sites:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf){
expires 1d;
}
if (!-e $request_filename ) {
rewrite ^/.* /index.php?q=$1 last;
}
error_page 404 /index.php;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/sites/data/www/site$fastcgi_script_name;
fastcgi_param DOCUMENT_ROOT /home/sites/data/www/site;
fastcgi_pass_header Set-Cookie;
fastcgi_ignore_headers Cache-Control Expires;
fastcgi_cache_key "$server_name$request_uri";
fastcgi_cache fastcgi_cache;
fastcgi_temp_path /nginx_cache/temp 1 2;
fastcgi_cache_bypass $arg_nocache;
fastcgi_cache_use_stale updating error timeout invalid_header http_500;
fastcgi_cache_valid 10s;
include fastcgi_params;
}
location ~ /\.ht {
deny all;
}
}
Ну у меня много замечаний… Те, которые по существу кэширования:
fastcgi_no_cache— смысл захламлять кэш данными, которые никогда не будут использоваться?fastcgi_cache_keyдовольно-таки опасен: если кто-то выполнит запрос HEAD и результат попадёт в кэш, все остальные пользователи будут видеть пустую страницу.fastcgi_cache_bypass $arg_nocache;выглядит очень сомнительно; есть подозрение, что может закэшироваться еще и админка.Vary: CookieПонятно. Vladimir, тогда если можно пару уточнябщих вопросов
1. предполагается $cookie_PHPSESSID не кешировать ?
2. Какой ключь рекомендуется ? вида fastcgi_cache_key “$server_name$request_uri|$cookie_phpsessid”; ?
3. Авторизации на сайте нет только админ панель
4. Какие рекомендации могут быть по поводу fastcgi_cache_bypass $arg_nocache ?
Эдуард, я сейчас пишу статью на эту тему, скоро появится на сайте.
Возможно ли доработать плагин, что бы он кэшировал ВСЮ страницу и клал в мемкэш с ключем равным url и заданным таймаутом?
тогда можно будет nginx натравить на мемкэш
Попробуйте BatCache.
SJ Object Cache — объектный кэш, а не страничный: у него совсем другой принцип работы.