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»…

Автор: ; опубликовано в: Плагины WordPress; метки: APC, eAccelerator, Memcache, Memcached, SJ Object Cache, WordPress, WP File Cache, xCache, кэш, плагин
14
Окт
2010

RSS Комментарии к статье «SJ Object Cache: еще более быстрое объектное кэширование для WordPress» (159)  »

  1. Денис

    Здравствуйте, есть ли какие-нибудь отличия вашего решения от плагина “db-cache-reloaded”, который в разы снижает количество запросов к базе и ускоряет загрузку страниц http://wordpress.org/extend/plugins/db-cache-reloaded/?

    • Wandering Soul

      DB Cache Reloaded — это хак над базой данных, у которого много ограничений (он не работает в админке, не умеет работать со сложными запросами, может привести к рассинхронизации кэша и базы данных).

      SJ Object Cache — это реализация официального WordPress Cache API. Но в отличие DBCR, для того, чтобы кэш работал, программист должен использовать это API. Если плагин лезет к базе данных самостоятельно, а не через стандартные функции WordPress, либо использует в запросах свои собственные таблицы, но не использует WP Cache API, SJ Object Cache не поможет.

  2. Денис

    Здравствуйте.
    Мой сайт (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. Согласен на любых условиях.

  3. гость

    Любопытно, но с этим плагином на выделенном сервере скорость загрузки страниц увеличилась примерно на 15%, но кол-во запросов к базе упало на 50%. Используется Xcache.

  4. Эдуард

    Здравствуйте
    У меня стоит wordpress 2.3.3. На нем будет работать ваш плагин SJ Object Cache или надо обновляться до более новых версий?

  5. Bogdan

    Два вопроса/предложения.

    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

  6. Alex

    Здравствуйте.

    Использую плагин SJ Object Cache на stand-alone блоге.
    Параметры дед. сервера: nginx + php-fascgi + memcache и тд
    Версия WP: 3.0

    Когда плагин активен, при добавлении поста, почему-то по дефолту прописывает категорию ‘Новые заметки’, хотя на самом деле в посте явно указанна другая. При сбросе кэша (очистка в ручную или после TTL) всё становится на свои места.

    В чем может быть проблема?

    PS: WP File Cache не вызывает этих проблем с категорией.

  7. Недавно поставил себе плагин 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?

      Да. Он решает только одну задачу: объектное кэширование (смею надеяться, что решает хорошо). W3 Total Cache пытается решить много задач, большинство из которых решается грамотным конфигурированием сервера.

      Я позволил себе небольшой эксперимент:

        ab -n 1000 -c 20 -r http://blog.sjinks.pro/ ab -n 1000 -c 20 -r http://www.benatar.ru/
      Time taken for tests, s 5.614 60.489
      Requests per second, #/s 178.12 16.53
      Time per request, ms 112.282 1209.775
      Time per request, ms (across all concurrent requests) 5.614 60.489
      Transfer rate, KB/sec 9081.28 1034.93
      Connection Times, ms
        min mean ±sd median max
      Connect: 16 20 3.6 19 38
      Processing: 75 91 8.8 89 129
      Waiting: 17 21 3.4 20 40
      Total: 98 111 9.0 109 151
        min mean ±sd median max
      Connect: 68 489 1189.5 68 9096
      Processing: 676 704 99.6 687 1526
      Waiting: 68 69 0.4 69 73
      Total: 745 1193 1214.0 755 9784
      Longet request, ms 151 9784

      У меня стоит кэширование nginx, у Вас — W3TC, выводы делайте сами :-)

    • И еще для сравнения:

      [-]
      View Code Text
      $ ab -n 10000 -c 200 -r http://blog.sjinks.pro/
      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.

  8. Спасибо за ссылки, эти статьи я прочитал в первую очередь.
    Проблема в том, что на ht-systems суперкэш после обновления вордпресса до 3 версии создал зверскую нагрузку. Поставил гиперкэш.
    На днях хостинг начал тормозить снова. Стал искать систему кэширования, которая умеет пользоваться memcache, благо он на хостинге есть. Тогда и нашел W3. Еще очень заинтересовало, что плагин умеет кэшировать объекты, запросы и т.д. Скорость немного подросла, но как-то неравномерно – одни страницы грузятся мгновенно, других секунд по 10 ждать надо.
    Потом попал на вашу страничку. Стало интересно. Думаю, на днях попробую ваш плагин.

  9. Эдуард

    Здравствуйте

    Прочитал вашу статью, решил поставить на сервере кеширование через fastcgi_cache. Поставил, не я, админ. Получил увеличение скорости загрузки сайта, видно невооруженным глазом, особенно в период самой большой нагрузки, вечером. Но начались проблемы – в некоторых браузерах одни иегоглифы. Исправили вроде, но видно не все, потеря посетителей 5-7 процентов. Плюс к этому начались проблемы с плагином меток. В админке, в посте, показать все метки, метки то появляются, то исчезают, то иероглифы. Скачать сайт wget – иероглифы. Плюс еще проблемы… Жалко, но пришлось отказаться от такого кеширования. Искал решение этой проблемы, оказывается не только у меня одного такое. Решения не нашел. Подскажите где искать проблему или надо большой напильник для настройки?

    • Эдуард, а можно как-нибудь посмотреть на конфигурацию, выполненную администратором? Я постараюсь вечером выложить свой конфиг.

      • Эдуард

        Вот конфигурация

        [-]
        View Code nginx configuration
            gzip on;
            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;
                        }
        }
        • Ну у меня много замечаний… Те, которые по существу кэширования:

          1. Я не вижу директиву fastcgi_no_cache — смысл захламлять кэш данными, которые никогда не будут использоваться?
          2. Ключ в fastcgi_cache_key довольно-таки опасен: если кто-то выполнит запрос HEAD и результат попадёт в кэш, все остальные пользователи будут видеть пустую страницу.
          3. Авторизованные и не авторизованные пользователи будут видеть одни и те же данные; при этом есть вероятность, что в кэше останется и чей-нибудь email.
          4. fastcgi_cache_bypass $arg_nocache; выглядит очень сомнительно; есть подозрение, что может закэшироваться еще и админка.
          5. При использовании такого кэширования должен выдаваться заголовок Vary: Cookie
        • Эдуард

          Понятно. Vladimir, тогда если можно пару уточнябщих вопросов
          1. предполагается $cookie_PHPSESSID не кешировать ?
          2. Какой ключь рекомендуется ? вида fastcgi_cache_key “$server_name$request_uri|$cookie_phpsessid”; ?
          3. Авторизации на сайте нет только админ панель
          4. Какие рекомендации могут быть по поводу fastcgi_cache_bypass $arg_nocache ?

        • Эдуард, я сейчас пишу статью на эту тему, скоро появится на сайте.

  10. Евгений

    Возможно ли доработать плагин, что бы он кэшировал ВСЮ страницу и клал в мемкэш с ключем равным url и заданным таймаутом?
    тогда можно будет nginx натравить на мемкэш :)

Пожалуйста, не используйте эту форму для комментирования! Данная форма предназначена исключительно для ботов.

Оставить комментарий к записи «SJ Object Cache: еще более быстрое объектное кэширование для WordPress»

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Оставляя комментарий, вы выражаете своё согласие с Правилами комментирования.

Подписаться, не комментируя

गते गते पारगते पारसंगते बोधि स्वाहा