Ars Longa, Vita Brevis » Результаты поиска » Super Cache http://blog.sjinks.pro Quod scripsi, scripsi Mon, 06 Feb 2012 17:56:02 +0000 en hourly 1 WordPress: кэширование средствами nginx http://blog.sjinks.pro/wordpress/877-wordpress-caching-with-nginx/ http://blog.sjinks.pro/wordpress/877-wordpress-caching-with-nginx/#comments Fri, 10 Dec 2010 12:08:15 +0000 Vladimir http://blog.sjinks.pro/?p=877 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Уменьшение потребления ресурсов во много раз

Много было сказано про кэширование в WordPress… Сегодня я хочу рассказать о действительно эффективном методе, позволяющем сильно снизить нагрузку.

Метод основан на использовании кэша web-сервера .

Идея состоит в генерации статических страниц и отдачи их пользователям, не имеющим cookie комментатора. Зарегистрированным пользователям, а также комментаторам всегда отдаётся свежая страница. Так как читателей, ни разу не оставлявших комментарий, как правило, гораздо больше, чем комментаторов, то подобный использование кэша позволяет значительно снизить нагрузку на /. Знакомые с принципом работы заметят, что WPSC использует тот же принцип работы.

В чем же преимущество перекладывания работы на Web-сервер (nginx)?

  1. PHP — интерпретируемый язык. Как следствие, аналогичный код на компилируемом языке будет во много раз быстрее.
  2. WordPress во многом bloatware :-) От момента начала загрузки страницы до окончания выполнения стадии init выполняется очень много «лишнего» кода.
  3. В зависимости от нагрузки на сервер от запроса страницы до выполнения PHP-кода может пройти некоторое время: всё зависит от загруженности PHP (если все дочерние процессы PHP заняты обработкой запроса, новому запросу придётся ждать освобождения одного из процессов. Если за приемлемое время ни один процесс не освободился, пользователь видит сообщение о печально знаменитой ошибке 504).
  4. Когда обслуживанием кэша занимается web-сервер, шансы на возникновение подобной ситуации
    5. (когда даже автор не может понять, в чём дело) значительно снижаются: реализация синхронизации/блокировок средствами PHP — неблагодарное дело.

Теперь переходим от теории к практике.

  1. fastcgi_cache_path /var/lib/nginx/myblog levels=2 keys_zone=myblog:10m max_size=512m inactive=20m;
  2. server {
  3.     server_name example.com;
  4.     root /path/to/blog;
  5.  
  6.     index index.php;
  7.  
  8.     if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_" ) {
  9.         set $do_not_cache 1;
  10.     }
  11.  
  12.     fastcgi_cache_bypass $do_not_cache;
  13.     fastcgi_no_cache $do_not_cache;
  14.     fastcgi_pass_header Cookie;
  15.     fastcgi_cache myblog;
  16.     fastcgi_cache_key $request_method|$host|$request_uri;
  17.     fastcgi_cache_valid 301 8h;
  18.     fastcgi_cache_valid 404 1h;
  19.     fastcgi_cache_valid 200 15m;
  20.  
  21.     if ($http_user_agent !~ FeedBurner) {
  22. # Здесь идут перенаправления для FeedBurner
  23.     }
  24.  
  25.     error_page 404 = @wordpress;
  26.     log_not_found off;
  27.  
  28.     location ^~ /files/ {
  29.         rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
  30.     }
  31.  
  32.     location ~ ^/(wp-admin/.*\.php|wp-login\.php|wp-register\.php|(feed|comment/feed)(/.*)?)$ {
  33.         try_files $uri @wordpress;
  34.         set $do_not_cache 1;
  35.         fastcgi_cache_bypass 1;
  36.         fastcgi_no_cache 1;
  37.         fastcgi_pass unix:/dev/shm/php-fcgi.sock;
  38.         fastcgi_index index.php;
  39.         include /etc/nginx/fastcgi_params;
  40.         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  41.     }
  42.  
  43.     location @wordpress {
  44.         include /etc/nginx/fastcgi_params;
  45.         fastcgi_param SCRIPT_NAME /index.php;
  46.         fastcgi_param SCRIPT_FILENAME $document_root/index.php;
  47.         fastcgi_index index.php;
  48.         fastcgi_pass unix:/dev/shm/php-fcgi.sock;
  49.         if ($do_not_cache != "1") {
  50.             add_header Vary Cookie;
  51.         }
  52.     }
  53.  
  54.     location ~ \.php$ {
  55.         include /etc/nginx/fastcgi_params;
  56.         fastcgi_index index.php;
  57.         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  58.         try_files $uri @wordpress;
  59.         fastcgi_pass unix:/dev/shm/php-fcgi.sock;
  60.         if ($do_not_cache != "1") {
  61.             add_header Vary Cookie;
  62.         }
  63.     }
  64.  
  65.     location ^~ /blogs.dir/ {
  66.         internal;
  67.         root /path/to/blog/wp-content/;
  68.     }
  69. }

Документация по использованию FastCGI в nginx приведена здесь, поэтому я не буду подробно останавливаться на том, что конкретно каждая директива делает.

Основная магия происходит в строка 8—10: здесь определяются условия, при которых отдаётся свежая страница. В данном случае проверяется наличие авторизационных cookie и cookie комментатора. Важно, чтобы в случае отказа от кэширования переменная $do_not_cache устанавливалась в 1.

Строка 16 задаёт ключ, по которому страница доступна в кэше. В ключе присутствует $request_method, чтобы различать запросы GET и HEAD (для HEAD данные не возвращаются, только заголовки).

Строки 17—19 задают время жизни кэша в зависимости от кода ответа. Чем больше время жизни, тем реже будет обновляться информация для незарегистрированных пользователей.

В строке 32 задаётся маска для страниц, которые не должны кэшироваться (например, админка, страницы логина и регистрации, фиды).

Так как содержимое страницы может отличаться в зависимости от cookie пользователя, в строках 49 и 59 для закэшированных страниц принудительно выставляется заголовок Vary: Cache. Если используются другие правила (например, фильтрация по User-Agent), нужно добавлять соответствующее правило.

Строки 21—23: подробнее описано в статье «Перенаправление RSS в WordPress на FeedBurner для nginx»

Строки 28—30, 63—66 подробнее описаны в статье «WordPress MultiSite, nginx и X-Accel-Redirect»

Вроде бы ничего не забыл. Теперь о том, какую мы получаем:

$ ab -n 10000 -c 100 http://blog.sjinks.pro/
Server Software:        nginx
Server Hostname:        blog.sjinks.pro
Server Port:            80

Document Path:          /
Document Length:        50294 bytes

Concurrency Level:      100
Time taken for tests:   46.925 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      504940000 bytes
HTML transferred:       502940000 bytes
Requests per second:    213.10 [#/sec] (mean)
Time per request:       469.254 [ms] (mean)
Time per request:       4.693 [ms] (mean, across all concurrent requests)
Transfer rate:          10508.28 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   94  76.9     94    3125
Processing:   118  373  81.7    360    1334
Waiting:       17   69  38.5     57     422
Total:        156  467 105.0    445    3535

Percentage of the requests served within a certain time (ms)
  50%    445
  66%    454
  75%    471
  80%    494
  90%    541
  95%    589
  98%    655
  99%    768
 100%   3535 (longest request)

Сервер зафлудили 10,000 запросами в 100 параллельных потоков. Сервер выдал практически полгигабайта за 47 секунд; в среднем сервер обрабатывал 213 запросов в секунду, при этом 99% запросов были обработаны за 768 мс (при том, что на сервере несколько сайтов в Alexa Top 100,000)! Нагрузка на сервер была минимальной (изменений Load Average замечено не было).

UPDATE: есть один небольшой нюанс: CAPTCHA. Если вы их используете, убедитесь, что они работают. Дело в том, что страница со статьёй будет отдаваться непосредственно из кэша nginx, PHP загружаться не будет. Поэтому если CAPTCHA полагается на использование сессии, она может работать неправильно. Здесь всё зависит от используемого плагина.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/877-wordpress-caching-with-nginx/feed/ 61 SJ Object Cache: еще более быстрое объектное кэширование для WordPress http://blog.sjinks.pro/wordpress/plugins/776-sj-object-cache-faster-object-cache-for-wordpress/ http://blog.sjinks.pro/wordpress/plugins/776-sj-object-cache-faster-object-cache-for-wordpress/#comments Thu, 14 Oct 2010 06:34:35 +0000 Vladimir http://blog.sjinks.pro/?p=776 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Делаем еще быстрее

После года тестирования наконец-то вышла первая стабильная версия плагина SJ Object Cache.

SJ Object Cache — альтернатива плагину , поддерживающая APC, , , Zend Disk Cache, Zend Shared Memory Cache, и .

В отличие от WP File Cache, SJ Object Cache ориентирован на VPS/VDS и выделенные сервера.

Одним из недостатков WP File Cache является то, что он смещает нагрузку с базы данных на файловую систему. Хотя это может быть не сильно критично для хорошего shared-хостинга, на виртуальных серверах и серверах со слабой дисковой подсистемой это может быть критично (виртуализация очень часто негативно сказывается на скорости ввода/вывода, в результате процессор может проводить много времени в ожидании окончания ввода/вывода). Вдобавок ко всему при включённом open_basedir файловые операции осуществляются медленнее из-за лишних проверок (привет всем, использующим Plesk).

Решением данной проблемы является использование разделяемой памяти (shared memory). Так как многие администраторы для повышения производительности ставят на выделенных серверах акселераторы (APC, xCache, eAccelerator), SJ Object Cache использует их интерфейс (API) для работы с выделенной памятью.

Функциональность SJ Object Cache

  • реализация долговременного кэширования на уровне запросов;
  • возможность отключения кэширования (в том числе и встроенного в WordPress);
  • возможность отключения межсессионного кэширования;
  • полная совместимость с интерфейсом класса WP_Object_Cache WordPress;
  • использование памяти под сессионный для увеличения производительности;
  • сессионное кэширование часто изменяющихся объектов;
  • возможность задания групп, не подлежащих межсессионному кэшированию (может быть полезно для обеспечения совместимости со сторонними плагинами);
  • модульная архитектура, позволяющая добавлять новые кэширующие движки;
  • хранение настроек в коде плагина.

Кэширующие движки

  • Base Cache — аналог объектного кэша WordPress без возможности сохранения данных между сессиями; по тестам показывает чуть большую производительность, чем встроенный в WordPress кэш;
  • Alternative PHP Cache (APC);
  • eAccelerator (внимание: eAccelerator 0.9.6 не поддерживается, так как из него убрали функции кэширования пользовательских данных);
  • xCache
  • Zend Disk/Shared Memory Cache (данный движок не тестировался, но работать должен);
  • File Cache — модифицированная версия движка WP File Cache;
  • File Group Cache — модифицированная версия File Cache, оптимизированная под слабую дисковую подсистему (при доступе к кэшу читается сразу вся группа, что приводит к минимизации числа обращений к диску и увеличению объема потребляемой памяти);
  • Memcache;
  • Memcached;
  • Версия 1.2 плагина полностью совместима с WordPress 3.x (в том числе с 3.1).

Замечания по установке

Плагину при активации/сохранении настроек должен быть доступен на запись каталог wp-content: в него копируется файл object-cache..

В настройках акселератора (APC, eAccelerator, xCache) нужно отвести достаточно места под пользовательский кэш. WordPress весьма прожорлив!

Настройки, контролирующие размер кэша APC: apc.shm_segments, apc.shm_size.

Настройки, контролирующие размер кэша xCache: xcache.var_size. xCache — единственный из трёх рассматриваемых акселераторов, имеющий раздельные кэши для опкода и пользовательских данных.

Настройки, контролирующие размер кэша eAccelerator: eaccelerator.shm_size.

Для APC и eAccelerator размер кэша должен учитывать кэш опкода. По скромным подсчётам, WordPress 2.9.2 без плагинов (PHP 5.1.22, amd-64) занимает порядка десяти мегабайт. Для настройки размера кэша очень рекомендую воспользоваться утилитами, входящими в дистрибутив акселератора: они позволяют оценить объем занятой памяти, фрагментации кэша и просматривать различную статистику. Если с первого раза оптимальный размер кэша подобрать не удаётся, это нормально :-)

Memcache и Memcached требуют наличия установленных расширений PHP из PECL (Memcache и Memcached соответственно).

На данном сервере (пять разных WordPress с разным наборов плагинов (SJ Object Cache настроен на трёх из них), три Simple Machines Forum, куча всего по мелочи, кэш eAccelerator для хранения сессий) размер кэша колеблется в пределах 128–192 мегабайт. Север выдерживает больше тысячи одновременных посетителей, порядка 100,000 посетителей в сутки и генерирует в среднем 64 гигабайта трафика в сутки — и это безо всяких страничных кэшей типа , Hyper Cache, ,  и т.п. Не без напильника, но тем не менее.

Удаление/деактивация плагина

Для успешной деактивации каталог wp-content должен быть доступен на запись — требуется удаление файла wp-content/object-cache.php.

Для версии 1.2 плагина на запись должен быть доступен каталог плагина — настройки плагина теперь хранятся в файле options.php (специально для тех, кто не хотел держать wp-content открытым на запись).

Скачать SJ Object Cache 1.0.
Экспериментальная версия SJ Object Cache 1.1 с поддержкой WordPress MU.
Экспериментальная версия SJ Object Cache 1.2 с поддержкой Memcache/Memcached

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/plugins/776-sj-object-cache-faster-object-cache-for-wordpress/feed/ 157 WP Super Cache vs MaxSite Cache: часть 2 http://blog.sjinks.pro/wordpress/725-689-wp-super-cache-vs-maxsite-cache-part-2/ http://blog.sjinks.pro/wordpress/725-689-wp-super-cache-vs-maxsite-cache-part-2/#comments Sun, 13 Dec 2009 08:23:41 +0000 Vladimir http://blog.sjinks.pro/?p=725 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Тест страничных кэшей на грамотно настроенном сервере

Вторая часть статьи WP Super Cache vs MaxSite Cache.

В предыдущей части я сравнивал поведение и на тестовом VDS (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на котором ни операционная система, ни программное обеспечение не были специально настроены — бралась конфигурация «из коробки» и тестировалась. Одним словом, «VDS абсолютного чайника».

В этой части изменилась только конфигурация программного обеспечения: сервер настраивался на максимальную .

В частности:

  • отказ от в пользу и от mod_5 в пользу php-fcgi (количество -процессов выбиралось таким образом, чтобы избежать использования файла подкачки);
  • смена ядра с linux-image-server на linux-image-virtual;
  • настройка MySQL: отказ от InnoDB (экономит примерно 100 МБ памяти), увеличение буфера ключей и т.п.;
  • установка и настройка (я исходил из того, что далеко не все чувствуют себя комфортно при сборке программ из исходников, поэтому брал только готовое ПО);
  • настройка iptables для фильтрации пакетов.

Методика тестирования осталась прежней: карта сайта преобразовывалась в список адресов, на этот список натравливался siege, а я присматривал за сервером и вносил коррективы в конфигурацию ПО (да, с первого раза трудно всё настроить идеально).

Чтобы убедиться, что новая конфигурация не хуже старой, я полностью отключил кэширование и имитировал 50 одновременных посетителей в течение 15 минут. На момент выполнения теста у сервера было свободно 348.5 МиБ памяти.

  Голый
Количество транзакций 4,825
Доступность сервера 99.98%
Объём данных, МБ 28.32
Среднее время ответа, с 9.23
Частота транзакций в секунду 5.36
Пропускная способность, МБ/с 0.03
Коэффициент параллельности 49.50
Максимальная длина транзакции, с 30.76
Минимальная длина транзакции, с 1.15
Максимальная загрузка процессора (system/user) 25.72%/68.39%
Load Average 40.81
Примерное потребление памяти, МиБ 414

Данные загрузки/потребления памяти очень приблизительны. Хотя вряд ли пользователи станут ждать по 9 секунд загрузку страницы, радует, что сервер не ответил только на один запрос и не ушел в нокдаун. Простая экстраполяция показывает, что сервер выдержит примерно 463,000 обращения к PHP-страницам в сутки.

Мы убедились, что новая конфигурация вполне жизнеспособна (старой до неё, как до Китая в неудобной позе), переходим к тестированию плагинов.
Тестирование проходило в 30 и 75 потоков. Я не разделял фазы построения и использования кэша.

  MaxSite Cache
(30 потоков)		 MaxSite Cache
(75 потоков)		 WP Super Cache
(30 потоков, HALF ON)		 WP Super Cache
(30 потоков)		 WP Super Cache
(75 потоков)
Количество транзакций 176,684 182,604 5,069 198,160 189,686
Объём данных, МБ 1,062.24 1,099.60 29.99 1,202.95 1,147.33
Среднее время ответа, с 0.13 0.34 5.30 0.10 0.29
Частота транзакций в секунду 196.36 203.00 5.64 220.20 210.95
Пропускная способность, МБ/с 1.18 1.32 0.03 1.34 1.28
Коэффициент параллельности 25.42 69.32 29.85 23.05 62.16
Максимальная длина транзакции, с 21.08 26.12 15.06 22.78 25.03
Минимальная длина транзакции, с 0.00 0.00 0.48 0.00 0.00
Load Average 1.8 2.2 30.1 1.3 1.65

Краткие выводы: на грамотно настроенном сервере лидирует WP Super Cache — и по скорости, и по создаваемой нагрузке. Это связано с тем, что задача по отдаче закэшированного контента переложена на web-сервер. Так как web-сервер справляется со статикой быстрее, чем с динамикой, в результате получаем рост производительности и снижение нагрузки.

Если по той или иной причине WP Super Cache не может работать в режиме Full On, то MaxSite Cache будет всё же предпочтительнее — ввиду своей простоты он обладает исключительным быстродействием.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/725-689-wp-super-cache-vs-maxsite-cache-part-2/feed/ 2 WP Super Cache vs MaxSite Cache: часть 1 http://blog.sjinks.pro/wordpress/689-wp-super-cache-vs-maxsite-cache-part-1/ http://blog.sjinks.pro/wordpress/689-wp-super-cache-vs-maxsite-cache-part-1/#comments Fri, 13 Nov 2009 23:17:34 +0000 Vladimir http://blog.sjinks.pro/?p=689 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Тест страничных кэшей на виртуальном сервере абсолютного чайника

После того, как MAX’у не понравился тест с участием MaxSite Cache, я решил несколько видоизменить методику тестирования.

На этот раз я тестировал только два кэша: и Lite.

Так как по словам MAX’а в реальности все ставится «из коробки», я взял виртуальный сервер (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на который поставил Ubuntu 8.04 LTS Server Edition. Затем поставил  (2.2.8-1ubuntu0),  (5.2.4-2ubuntu5.6) и MySQL (5.0.51a-3ubuntu5.4). Конфигурационные файлы брались «из коробки» (только для пришлось включить ), в системной конфигурации абсолютно ничего не менялось. VDS абсолютного «чайника». Для мониторинга ресурсов системы установил (он рисует такие красивые графики).

Кому интересно, VDS конфигурировался так:

wget http://ubuntu-releases.eecs.wsu.edu/hardy/ubuntu-8.04.3-server-i386.iso
VBoxManage registerimage dvd /home/user1/ubuntu-8.04.3-server-i386.iso
VBoxManage createhd --filename TestVDS-HD1 --size 10240 --remember
VBoxManage createvm --name TestVDS --register
VBoxManage modifyvm TestVDS \
    --ostype Ubuntu \
    --memory 512 --vram 1 \
    --acpi on --ioapic off --pae off --hwvirtex on --nestedpaging on \
    --boot1 dvd \
    --sata on --sataport1 TestVDS-HD1 \
    --dvd /home/user1/ubuntu-8.04.3-server-i386.iso \
    --floppy disabled \
    --nic1 nat \
    --audio none

VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/Protocol" TCP
VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/GuestPort" 80
VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/HostPort" 8080

Затем я поставил  2.8.5 с официального сайта, импортировал в блог порядка 800 статей среднего размера (авторство статей не моё, так что выложить не могу).

Вместо Apache Bench я использовал Siege, обращение производилось ко всем страницам сайта в случайном порядке (вероятность обращения к заданной странице задавалась количеством её повторений в файле с адресами). Тестирование каждого варианта (WP Super Cache и MaxSite Cache) проводилось по 45 минут — 30 минут при низкой нагрузке и 15 минут при высокой (увы, трафик не безлимитный, и раскидываться гигабайтами трафика для теста возможности пока нет). Это имитировало постепенный наплыв пользователей на сайт. Специфика теста такова, что новый запрос не выполнялся до тех пор, пока не завершался предыдущий.

Одновременно к страницам обращалось 30 пользователей (Apache просто больше не выдерживает). Между тестами системе перезагружалась (на всякий случай). Виртуальный сервер и сервер, с которого осуществлялось тестирование, были, естественно, разными; соединены гигабитным каналом.

Результаты получились очень интересными: MaxSite Cache Lite строит несколько быстрее, чем WP Super Cache (у MaxSite Cache более простая логика работы). WP Super Cache создаёт более сильную нагрузку на диск (так как файлы разбрасываются по множеству каталогов, а не кидаются в один) и, за счёт этого, чуть большую нагрузку на процессор (если сравнивать по значению idle time). Но при этом у WP Super Cache больший коэффициент параллельности (обслуживает большее число запросов одновременно).

Но при отдаче кэша и с повышением нагрузки результат меняется: WP Super Cache отдаёт данные быстрее и, как результат, обслуживает большее количество клиентов. Потребление памяти при этом чуть меньше, но загрузка процессора чуть больше. Вообще картину очень сильно портил munin — , им создаваемая, вносила существенные погрешности в измерения (было видно в top).

Построение кэша
  WP Super Cache MaxSite Cache
Количество транзакций 91,755 95,028
Объём данных, МБ 2,160.51 2,240.59
Среднее время ответа, с 0.05 0.04
Частота транзакций в секунду 50.97 52.79
Пропускная способность, МБ/с 1.20 1.24
Коэффициент параллельности 2.58 2.21
Максимальная длина транзакции, с 20.93 19.10
Минимальная длина транзакции, с 0.00 0.00
Использование кэша
  WP Super Cache MaxSite Cache
Количество транзакций 219,761 206,949
Объём данных, МБ 5,129.06 4,880.30
Среднее время ответа, с 0.07 0.09
Частота транзакций в секунду 244.29 229.92
Пропускная способность, МБ/с 5.70 5.42
Коэффициент параллельности 27.89 21.58
Максимальная длина транзакции, с 21.96 21.58
Минимальная длина транзакции, с 0.00 0.00

Краткие выводы: в плане построения кэша у MaxSite Cache Lite выше, что объясняется простотой его логики. Но при нагрузке и построенном кэше WP Super Cache обладает более высокой производительностью, так как web-сервер способен отдавать закэшированные данные без привлечения PHP. При одинаковом количестве запросов в секунду под нагрузкой WP Super Cache демонстрирует меньшее потребление памяти и нагрузку на процессор. При средней нагрузке на систему оба кэша ведут себя примерно одинаково — разница в потреблении памяти и нагрузке незаметна.

В следующей части: тест WP Super Cache и MaxSite Cache на грамотно настроенном сервере.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/689-wp-super-cache-vs-maxsite-cache-part-1/feed/ 9 WP Super Cache vs HyperCache vs W3 Total Cache vs MaxSite Cache http://blog.sjinks.pro/wordpress/683-wp-supercache-vs-hypercache-vs-w3-total-cache-vs-maxsite-cache/ http://blog.sjinks.pro/wordpress/683-wp-supercache-vs-hypercache-vs-w3-total-cache-vs-maxsite-cache/#comments Fri, 06 Nov 2009 10:59:55 +0000 Vladimir http://blog.sjinks.pro/?p=683 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Сравнение различных плагинов кэширования для WordPress

Для WordPress написано много кэширующих плагинов, предназначенных для борьбы со слабой производительностью сервера (либо кривыми руками администратора, который не в состоянии настроить /MySQL). Простой пользователь зачастую задаётся вопросом: какой же из плагинов выбрать?

В данной статье я рассмотрю наиболее популярные плагины (, Hyper Cache, W3 Total Cache и ), а затем расскажу о результатах жестокого теста, которому я подверг все эти плагины.

Прежде, чем перейти к делу, отмечу, что я не фанат ни одного из плагинов и не использую их на своих сайтах, считая, что овчинка не стоит выделки: будущее за динамическими страницами :-)

Поехали.

  1. WP Super Cache написан Donncha O’Caoimh, одним из разработчиков WordPress. Про своё отношение к этому плагину я уже писал. разрабатывался как замена WP-Cache. Ключевой особенностью плагина является генерация статических HTML-страниц таким образом, что они будут отдаваться Web-сервером — минуя PHP.
  2. Hyper Cache. С ним я тоже сталкивался, и какое-то время плагин стоял у меня на сайте. Плагин написан гораздо проще, чем WP Super Cache и имеет более высокий рейтинг на wordpress.org.
  3. W3 Total Cache — новое слово в кэшировании. Поддерживает сжатие скриптов, CSS, для базы данных, работу с CDN и многое другое.
  4. MaxSite Cache — отечественная разработка, при этом платная. Я тестировал Lite-версию, так как покупать полную версию чисто для тестирования желания нет. По словам автора, выйдет абсолютным победителем при сравнении с WP Super Cache и компанией.

Для теста была взята машина такое конфигурации: Intel(R) Xeon(R) CPU X3320 @ 2.50GHz, 4 ядра, 3 MiB кэш, 8 GiB DDR-2 RAM, 2×500 GB SATA, RAID1 (ARC-1210 4-Port PCI-Express to SATA RAID Controller), 82572EI Gigabit Ethernet Controller.
Операционная система: Ubuntu 9.10 64-bit Server Edition
Веб-сервер: nginx 0.8.19
PHP: 5.2.10.dfsg.1-2ubuntu6.1 () +  1.2.2-5, 75 процессов.

На тестируемой странице 25 несложных запросов, время их выполнения — 0.00993 сек.

На сайт натравливался ApacheBench — 10,000 запросов в 100…500 потоков. Это создаёт весьма приличную нагрузку, так как запросы идут один за другим.

Базовая  — 100 параллельных потоков. Я увеличивал количество потоков до тех пор, пока web-сервер не стал отдавать ответ, отличный от 200. Более 500 потоков не тестировал.

  WordPress WP Super Cache 0.9.7 Hyper Cache 2.6.2 MaxSite Cache Lite W3 Total Cache 0.8
Количество потоков 100 100 500 100 250 100 500 130 100 130
Время тестирования, с 677.442 1.115 1.079 18.736 8.633 3.291 2.501 2.992 21.284 21.086
Количество ошибок 0 0 0 0 3663 0 2713 0 0 0
Скорость, запрос/с 14.76 8967.28 9268.36 544.20 1158.30 3038.98 3997.80 3341.72 469.84 474.25
Среднее время обработки запроса, мс 6774.423 11.152 53.947 183.757 215.833 32.906 125.069 38.902 212.838 274.116
Среднее время обработки запроса по всем потокам, мс 67.744 0.112 0.108 1.838 0.863 0.329 0.250 0.299 2.128 2.109
Скорость передачи, Кбайт/с 175.12 106154.90 109865.55 6393.68 8754.04 35537.15 34413.87 39075.95 4928.74 4974.58
Порог завершения 95% запросов, мс 9188 11 27 394 268 52 91 58 344 364

То, что не вошло в таблицу: средняя загрузка системы (load average) при тесте голого WordPress зашкаливала за 60. При тесте WP Super Cache и MaxSite Cache я не успевал ее измерить (была ничтожной). С Hyper Cache и W3 Total Cache загрузка доходила до где-то 10. Так что кэширование работает и выполняет свою работу — снижает нагрузку на сервер.

«Голый» WordPress тестировать более, чем со 100 потоками смысла нет :-)

В ходе тестирования выяснился абсолютный лидер — WP Super Cache. Скорость отдачи кэшированных страниц поистине фантастическая — почти 800 мегабит/сек. Хотя такая скорость — это больше заслуга nginx.

MaxSite Cache Lite на 100 параллельных потоках проиграл WP Super Cache практически в пять раз! Причина понятна: WP Super Cache создает статические файлы так, что web-сервер их может отдавать клиенту без привлечения PHP-интерпретатора. А статические запросы при прочих равных всегда быстрее динамических. Так что платить 30 WMZ за полную версию MaxSite Cache я пока не готов :-)

Среди остальных плагинов MaxSite Cache выигрывает благодаря свой простоте: минимум проверок, никаких регулярных выражений и лишних подключаемых файлов. Но даже такой подход не спасёт от хорошего SlashDot-эффекта: какой-то процент пользователей будет видеть ошибку сервера, для других возрастёт время генерации страницы. Это касается и остальных плагинов. Мораль: подключение PHP-интерпретатора — дорогое удовольствие.

По поводу масштабируемости: более 130 потоков не пережил ни один кэш (кроме WP Super Cache).

Аутсайдером, на мой взгляд, оказался W3 Total Cache — при почти одинаковой с Hyper Cache нагрузкой на сервер, время отдачи страниц было значительно выше. Хотя если бы тест был не таким искусственным, то W3 Total Cache могла быть и более высокой. Хотя во многом W3 Total Cache делает то, что опытный системный администратор может настроить на уровне сервера.

Вообще плагины кэширования обладают очень интересной особенностью: они переносят нагрузку с одной подсистемы (процессор) на другую (диск). Так что на десктопном железе, слабых дисках или виртуальных серверах кэш может ухудшить ситуацию: процессор будет тратить время не на выполнение кода, а на ожидание завершения ввода/вывода (iowait). Так что при большом количестве оперативной памяти имеет смысл создавать RAM-диск и помещать кэш на него.

Кстати, даже при хорошей дисковой подсистеме, но при малом объеме оперативной памяти при большом объеме кэша могут возникать проблемы: например, если дисковый кэш у операционной системы мал, то при интенсивном равномерном обращении к разным страницам может возникнуть большая дисковая активность.

Вообще, как показывает мой опыт, прежде чем использовать плагин кэширования страниц, имеет смысл все же грамотно настроить сервер (обращайтесь). Например, если вместо Apache поставить nginx, можно освободить довольно много драгоценной памяти (prefork у Apache — это весьма сильный убийца производительности); если увеличить размер буфера ключей MySQL, можно добиться уменьшения дисковой активности. Если поставить opcode cacher (, xCache, ), то можно значительно снизить затраты на перекомпиляцию PHP-кода и уменьшить время отклика системы. Если использовать оптимизатор, встроенный в , то можно повысить производительность PHP-кода. Анализ производительности MySQL-запросов и знание принципов работы оптимизатора помогут переписать слабые запросы/добавить отсутствующие индексы в базу данных. Простор для действий довольно-таки большой. И динамика страниц остаётся :-)

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/683-wp-supercache-vs-hypercache-vs-w3-total-cache-vs-maxsite-cache/feed/ 53 WP Super Cache и высокая нагрузка: часть 2 http://blog.sjinks.pro/wordpress/601-wp-supercache-under-high-load-part-2/ http://blog.sjinks.pro/wordpress/601-wp-supercache-under-high-load-part-2/#comments Wed, 29 Jul 2009 02:03:31 +0000 Vladimir http://blog.sjinks.pro/?p=601 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Стоит ли овчинка выделки?

Вчера я наконец-то поднял munin и новый monit на сервере, а сегодня посмотрел на результаты мониторинга. Самое первое, что бросилось в глаза: iostat показывает очень большое количество записей (превышавшее количество чтений почти в тысячу раз).

На сервере живут четыре сайта на , два из которых (littlefox.ru и cat-tv.ru) находятся в Alexa Top 100,000 (они создают основную нагрузку на сервер).

Особенность обоих сайтов — они используют небезызвестный . Мне с этим плагином приходилось неоднократно сталкиваться, и не всегда с хорошей стороны (так получилось), так что я имею представление о том, как он работает.

С целью поэкспериментировать мы отключили WP Super Cache. В результате получилась такая картина.

Статистика munin

Так сложилось, что WP Super Cache мы отключили практически при пиковой посещаемости (хорошо видно на графике «eth0 traffic»), и тем интереснее смотрятся результаты. Практически сразу упало количество записей на диск (дисковая подсистема вздохнула с облегчением): при количестве записей, тысячекратно превышающих количество чтений, эффективность дискового кэша, очевидно, падает. В случае с виртуальным сервером такая могла бы его положить: дело в том, что виртуализаторы не очень хорошо справляются с операциями ввода/вывода (это их слабое место); как результат, от этого начинает увеличиваться на процессор (все больше времени проводится в iowait).

Также, как это ни странно, упала нагрузка на процессор! Причём заметнее всего это отразилось на user time (а не на system, как можно было бы ожидать) — если внимательно посмотреть на графики «CPU Usage» и «Load Average», то можно заметить, что при примерно одинаковом количестве посетителей (я сужу по объемам отдаваемого трафика) нагрузка при отключенном WP Super Cache оказывается меньшей (причем это заметно даже при низкой нагрузке — впрочем, при низкой нагрузке, наверное, любой не особо эффективен из-за затрат на реализацию кэширования)! Так же уменьшилось количество переключений контекста (что, видимо, и объясняет уменьшение system time) и уменьшилось количество прерываний от контроллера жесткого диска.

А вот статистика MySQL далеко не однозначна:

Статистика по запросам MySQL

С одной стороны, вроде бы и среднее количество запросов в секунду резко упало, но с другой стороны, это произошло до отключения WP Super Cache. Также заметно, что при выключенном WP Super Cache кэш запросов стал медленно таять (хотя это можно объяснить падением нагрузки и чисткой кэша). Хотя процентное отношение количества запросов, результат для которых был взят из кэша, весьма впечатляет. Что значит грамотная настройка MySQL. Тем не менее, данных для однозначных выводов недостаточно.

Перейдём к ответу на вопрос, стоит ли овчинка выделки. Как обычно, однозначного ответа нет. Нужно смотреть в каждом конкретном случае. Тем не менее, если сайт стоит на виртуальном сервере, то высокая нагрузка при включенном WP Super Cache может его убить. Если есть достаточно памяти (что на виртуалках большая редкость), то имеет смысл помещать каталоги с кэшем на RAM-диск и разгрузить дисковую подсистему. При высокой нагрузке на выделенном сервере нужно очень внимательно смотреть на конфигурацию MySQL, а также типы запросов. Если же сайт стоит на shared-сервере, то выбор здесь небольшой: либо отказаться от плагинов, которые грузят MySQL, либо сменить WordPress на что-то более легкое. Кэширование на shared-сервере, как правило, не оправдывает себя (во многом зависит от жадности хостеров, которые на одном сервере стремятся разместить как можно большее количество сайтов). Тем же, кто имеет административный доступ на сервер, я бы очень рекомендовал мониторинг сервера (, nagios/nagvis и т.п.) со включенным и выключенным кэшем. Возможно, что результат очень сильно удивит :-)

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/601-wp-supercache-under-high-load-part-2/feed/ 17 WP Super Cache и высокая нагрузка http://blog.sjinks.pro/wordpress/521-wp-super-cache-under-high-load/ http://blog.sjinks.pro/wordpress/521-wp-super-cache-under-high-load/#comments Mon, 23 Mar 2009 13:28:47 +0000 Vladimir http://blog.sjinks.pro/?p=521 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Интересные зависания, или, Синхронизация — это не так просто

Проблема: случайным образом перестаёт реагировать на внешние запросы.

Сайт работает на (с ), web-сервером стоит , php-fpm с 40 дочерними процессами висит в режиме . Довольно-таки стандартная конфигурация.

Иногда (периодичность не ясна) сайт падает. В том плане, что nginx выдаёт ошибку 502 Bad Gateway. При этом в логах отображается примерно такое:

2009/03/23 00:50:57 [error] 29289#0: *1821923 connect() to unix:/dev/shm/php-fcgi-XXX.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 195.10.218.132, server: example.org, request: "GET /wp-login.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi-XXX.sock:", host: "example.org"

Лечится только перезапуском php-fpm.

очень интересная и нестандартная: один и тот же PHP обслуживает двух разных пользователей, соответственно, имеется два пула дочерних процессов. При этом висит только один пул. Следовательно, это не должна быть в FPM, иначе бы висело всё.

К счастью, php-fpm имеет один замечательный инструмент отладки: лог запросов к скриптам, выполняющихся дольше определённого времени с backtrace вызовов функций (нечто типа debug_backtrace() в PHP).

Оставил всё это дело на ночь, а наутро в логах получилась примерно такая картина (я оставил только уникальные backtrace):

Mar 22 18:25:06.569411 pid 3491 (pool XXX)
script_filename = /index.php
[0x00007fff494c81e0] sem_acquire() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:137
[0x00007fff494ca6e0] wp_cache_writers_entry() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:198
[0x00007fff494ca7e0] wp_cache_ob_callback() unknown:0
[0x00007fff494cc280] ob_end_flush() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:515
[0x00007fff494cc380] wp_cache_shutdown_callback() unknown:0

Mar 22 18:32:29.859417 pid 3748 (pool XXX)
script_filename = /wp-cron.php
[0x00007fff494c7f00] sem_acquire() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:137
[0x00007fff494c8a80] wp_cache_writers_entry() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:427
[0x00007fff494c8ea0] wp_cache_phase2_clean_expired() /wp-content/plugins/wp-super-cache/wp-cache-phase2.php:673
[0x00007fff494c8fa0] wp_cache_gc_cron() unknown:0
[0x00007fff494c99d0] call_user_func_array() /wp-includes/plugin.php:414
[0x00007fff494ca380] do_action_ref_array() /wp-cron.php:54

Запросов первого типа было очень много, и они заняли все процессы, стрелки указывают на WP Super Cache. То, что проблема именно с семафором, подтверждает вывод ps -C php-cgi -opid,state,wchan:25,args:

23023  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23024  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23025  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23047  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23048  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23049  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23050  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23051  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23052  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23053  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23054  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23055  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23056  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23057  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23058  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23059  S flock_lock_file_wait      /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23060  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23061  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23062  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23063  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23064  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23065  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23066  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23067  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23068  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23069  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23070  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23071  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23072  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23073  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23074  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23078  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23079  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23080  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23081  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23082  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23083  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23084  S flock_lock_file_wait      /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23085  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf
23086  S semtimedop                /usr/bin/php-cgi --fpm --fpm-config /etc/php5/fpm.conf

S означает «сон, который можно прервать» (ожидание свершения события), а semtimedop — функция, в которой процесс уснул.

Так как в пуле 40 процессов, и все 40 процессов спят, имеем проблему с синхронизацией. Особенно смущает засыпание в flock_lock_file_wait — по идее, WP Super Cache использует либо семафоры, либо файловую блокировку, но вероятно, я что-то не учитываю (ибо не kernel developer).

Теоретически (если верить документации) неосвобождённые семафоры автоматически удаляются при завершении скрипта (то есть в ситуации, когда скрипт захватил семафор и трагически погиб, семафор будет освобождён).

В общем, буду копать код WP Super Cache и искать баги.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/521-wp-super-cache-under-high-load/feed/ 12 WP Super Cache + nginx: замена правил mod_rewrite http://blog.sjinks.pro/wordpress/509-wp-supercache-nginx-replace-mod_rewrite-rules/ http://blog.sjinks.pro/wordpress/509-wp-supercache-nginx-replace-mod_rewrite-rules/#comments Fri, 27 Feb 2009 09:53:02 +0000 Vladimir http://blog.sjinks.pro/?p=509 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Конфигурация для

Сборная солянка с нескольких форумов (ссылок, к сожалению, не дам, но Google может помочь); данная конфигурация является рабочей.

if (-f $request_filename) {
        break;
}

set $supercache_file '';
set $supercache_uri $request_uri;

if ($request_method = POST) {
       set $supercache_uri '';
}

if ($query_string) {
       set $supercache_uri '';
}

if ($http_cookie ~* "comment_author_|wordpress|wp-postpass_" ) {
       set $supercache_uri '';
}

if ($supercache_uri ~ ^(.+)$) {
       set $supercache_file /wp-content/cache/supercache/$http_host/$1index.html;
}

if (-f $document_root$supercache_file) {
       rewrite ^(.*)$ $supercache_file break;
}

Этот блок нужно вставлять до основных правил переписывания адресов (в идеале сразу после root).

Детали конфигурирования nginx для описаны в статье «Конфигурация nginx для WordPress: критический взгляд со стороны».

Можно сделать проще: поместить правила для WP SuperCache в /etc/nginx/includes/wpsupercache.conf, а из конфигурации виртуального хоста делать include /etc/nginx/includes/wpsupercache.conf; — работать будет, так как конфигурация WP Super Cache не зависит от внешних параметров.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/509-wp-supercache-nginx-replace-mod_rewrite-rules/feed/ 7 WP File Cache: долговременное кэширование в WordPress http://blog.sjinks.pro/wordpress-plugins/wp-file-cache/ http://blog.sjinks.pro/wordpress-plugins/wp-file-cache/#comments Tue, 02 Dec 2008 11:23:47 +0000 Vladimir http://blog.sjinks.pro/?page_id=418 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Повышение производительности в один клик

Как известно, WordPress поддерживает два вида кэширования:

  1. Кэширование на уровне страниц;
  2. Кэширование на уровне запросов.

Кэширование на уровне страниц WordPress поддерживает, но самостоятельно не реализует, вследствие чего приходится использовать сторонние плагины (, и т.д.). При всех достоинствах постраничного кэширования, у него есть несколько недостатков, а именно:

  • невозможность использования динамических элементов (например, captcha, работающая по методу «изящного отсеивания спама») или виджетов, генерирующих динамический контент (например, quote of the day);
  • плагины, которые отдают комментатору статическую версию страницы (в этом был замечен Hyper Cache), вынуждают пользователя каждый раз вводить свои данные (имя, сайт, email) заново.

Кэширование на уровне запросов WordPress поддерживает и реализует самостоятельно, но в этой реализации есть один недостаток: между сессиями не сохраняется (что может привести к неприятным последствиям). Тем не менее, из-за особенностей архитектуры WordPress, без кэша WordPress работать будет очень медленно.

Очевидно, что если сохранять кэш между сессиями (что WordPress поддерживает, но самостоятельно реализовать не может), это может весьма положительно повлиять на .

Отмечу, что хотя поддержка кэширования на уровне запросов (в том виде, как она реализована сейчас) появилась в версии 2.5, в ядро WordPress были внесены изменения, позволяющие поддерживать долговременное кэширование без танцев с бубнами, только в версии 2.6.

На WordPress.org, как ни странно, плагинов, поддерживающих долговременное кэширование на уровне запросов, я не нашел. Вероятно, разработчики считают, что это экономия на спичках и разумнее будет творить что-то более глобальное (например, страничное кэширование).

Первая версия плагина родилась у меня давно — еще в июне. И лишь недавно я нашел время, чтобы привести в человеческий вид, добавить интерфейс для администратора и перевести на русский язык.

Функциональность плагина:

  • реализация долговременного кэширования на уровне запросов;
  • полная совместимость с интерфейсом класса WP_Object_Cache WordPress;
  • использование памяти под сессионный кэш для увеличения производительности;
  • сессионное кэширование часто изменяющихся объектов;
  • хранение настроек в коде плагина.

Особенности плагина:

  • возможность отключения кэширования (в том числе и встроенного в WordPress);
  • возможность отключения межсессионного кэширования;
  • возможность задания групп, не подлежащих межсессионному кэшированию (полезно только разработчикам, которые знают, о чём идёт речь);
  • плагин хранит свои настройки непосредственно в коде (в файле wp-content/object-cache.). Это связано с проблемой курицы и яйца, а также с архитектурными особенностями WordPress: дело в том, что WordPress инициализирует кэш вызовом wp_cache_init(): при обработке данного вызова плагин должен инициализировать кэш. Если бы настройки хранились в таблице wp_options, плагин бы использовал функцию get_option(). Но функция get_option() вызывает wp_cache_get(), а wp_cache_get() не может использовать кэш, потому что он не инициализирован. В принципе, это не является проблемой; проблема заключается в том, что get_option() читает все опции из таблицы, для которых autoload установлен в 1. На практике это 90–95% таблицы. Ранее я уже писал, что WordPress в целом и get_option() в частности спроектированы так, что если кэширующий модуль не вернул данные, функция затребует их вновь и в полном объеме. Иными словами, опции будут загружены дважды (два обращения к базе данных). А это нехорошо. Поэтому настройки хранятся непосредственно в коде.

Плагин существует в четырёх локализациях: ураинской, русской, английской и белорусской. Если есть желание перевести плагин на другой язык, пишите.

Замечания по установке:

После активации плагин для хранения кэша будет использовать каталог wp-content/plugins/file-cache/cache. Поэтому перед активацией каталог должен быть доступен на запись. Каталог для хранения кэша можно изменить в настройках (для увеличения производительности имеет смысл размещать кэш на RAM-диске); каталог также должен быть доступен на запись.

Плагину при активации/сохранении настроек должен быть доступен на запись каталог wp-content: в него копируется файл object-cache.php. После того, как плагин активирован и сконфигурирован, права на запись можно убрать.

Удаление/деактивация плагина:
Для успешной деактивации каталог wp-content должен быть доступен на запись — требуется удаление файла wp-content/object-cache.php.

Для срочной деактивации плагина можно удалить или переименовать файл wp-content/object-cache.php. В этом случае WordPress будет использовать встроенные механизмы кэширования.

Download

Скачать последнюю версию плагина WP File Cache.

Список изменений

  • Версия 1.2.8:
    • Добавлена украинская локализация (спасибо Андрею К.).
  • Версия 1.2.7:
    • Добавлена белорусская локализация (спасибо Antsar);
    • Добавлена экспериментальная возможность использовать свежие данные в панели администрирования (данные будут браться из базы данных, кэш при записи будет обновляться).
  • Версия 1.2.5:
    • Кэшируемые данные больше не передаются по ссылке, что позволяет избежать случайного изменения данных в кэше;
    • Кэшируемые объекты перед помещением в кэш клонируются (из тех же соображений).
  • Версии 1.2.3–1.2.4:
    • Размещение плагина в репозитории WordPress и исправление ошибок, вызванных изменением каталога плагина. Спасибо Raveex за терпение и тестирование.
  • Версия 1.2.2:
    • Добавлена базовая совместимость с WordPress 3.0.
  • Версия 1.2.1:
    • Оптимизация кода, ускорение работы кэширующего движка;
    • Блокировка файла при записи;
    • Использование меньшего количества системных вызовов при записи файлов.
  • Версия 1.1
  • Версия 1.0
  • Версии 0.2.x

Оценки производительности

  1. «Голый» WordPress 2.7rc1:
    1. Кэширование запрещено: 191 запроса, 0.587 с
    2. Встроенный в WordPress кэш: 18 запросов, 0.350 с
    3. WP File Cache: сессионное кэширование: 18 запросов, 0.334 с
    4. WP File Cache: долговременное кэширование: 3 запроса, 0.315 с
  2. Данный сайт:
    1. Кэширование запрещено: 1442 запроса, 3.558 с
    2. Встроенный в WordPress кэш: 51 запрос, 0.776 с
    3. WP File Cache: сессионное кэширование: 51 запрос, 0.615 с
    4. WP File Cache: долговременное кэширование: 13 запросов, 0.576 с

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress-plugins/wp-file-cache/feed/ 289 Ответ на «13 Тэгов, которые следует удалить из вашей темы» http://blog.sjinks.pro/wordpress/188-re-13-tags-to-delete-from-your-theme/ http://blog.sjinks.pro/wordpress/188-re-13-tags-to-delete-from-your-theme/#comments Thu, 12 Jun 2008 01:23:49 +0000 Vladimir http://blog.sjinks.pro/?p=188 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Стоит ли экономить на спичках?

Сегодня мне наконец-то посчастливилось найти концы (в смысле, оригинал) статьи, которую публикуют многие блоггеры (в переводе на родной язык). Статья носит название «13 Тэгов, которые следует удалить из вашей темы» (с ней можно ознакомиться, например, здесь).

В переводе меня смутило то, что автор, на мой взгляд, «экономил на спичках», вместо того, чтобы использовать что-либо стоящее, поэтому я решил обратиться к оригиналу, в надежде на то, что автор хоть как-нибудь обосновал свою точку зрения.

Приведу эти «тринадцать вещей», чтобы было понятно, о чем я говорю.

  1. <?php language_attributes(); ?> находится в header..
  2. <?php bloginfo('html_type'); ?> находится в header.php.
  3. <?php bloginfo('charset'); ?> находится в header.php.
  4. <?php bloginfo('name'); ?> встречается в теме постоянно.
  5. <meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /> <!–- leave this for stats -–> находится в header.php.
  6. <?php bloginfo('stylesheet_url'); ?> находится в header.php.
  7. <?php bloginfo('rss2_url'); ?> находится в header.php, sidebar.php и footer.php. Будьте осторожны, если у вас включен FeedBurner. Не забывайте обновлять адреса фидов вручную ( FeedSmith не сделает этого).
  8. <?php bloginfo('pingback_url'); ?> находится в header.php.
  9. <?php bloginfo('stylesheet_directory'); ?> встречается в теме постоянно.
  10. <?php bloginfo('description'); ?> встречается в теме постоянно. Описание вашего сайта.
  11. <?php bloginfo('comments_rss2_url'); ?> находится в sidebar.php и footer.php.
  12. <!-– <?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds. -–> находится в footer.php. Этот HTML-комментарий многими из нас не используется, так что удаляйте!
  13. Если вы используете виджеты, то можете удалить код из sidebar.php между строчками <?php /* Widgetized sidebar, if you have the plugin installed. */
          if ( !function_exists('dynamic_sidebar') || !dynamic_sidebar() ) : ?>     и <?php endif; ?>.
    Контент между двумя этими строчками используется только тогда, когда виджеты отключены. Если вы уверены, что будете продолжать использовать виджеты, то можно выделить это как неиспользуемый код, а к строке можно оставить комментарий «Этот контент используется, если отключены виджеты», чтобы не забыть о назначении этого куска кода).

Как утверждает сам автор, …the theme uses PHP tags to get the information. However, it has to use these tags every time a page is loaded. As most of the information never changes, you can delete these tags from your theme, and replace them with normal text. That way, your server has less to process next time around.

Конечно, в логике отказать автору трудно: если заменить вызовы функций их результатом, то интерпретатору не придется вызывать эти функции, на чем, собственно, и происходит экономия. Однако, как показали замеры, выигрыш ничтожен — тысячные доли секунды (в среднем; при этом я тестировал на довольно слабом компьютере). Конечно, если блог посещает несколько сотен посетителей в секунду, то даже эти микросекунды могут хоть немного помочь. Но для среднестатистического блога такие оптимизации что слону дробина.

Пункты 12 и 13 что есть, что нет — лично я не смог заметить изменений.
Пункт 5 — это, наверное, в целях безопасности. Хочу огорчить: версию можно установить косвенно (хоть это и труднее).

Вызовы blog_info() и get_feed_link() сводятся (в конечном итоге) к get_option(). А get_option() достает требуемые значения из кэша — запрос к базе данных не производится.

Аргументация в комментариях сводится к тому, что интерпретатору придется выполнять меньше инструкций. Но в этом случае, на мой взгляд, оптимизацию нужно начинать не с темы.

Вообще, если не экономить на спичках, лучших результатов можно достигнуть, используя специальные плагины — Super Cache, и подобные им. Вряд ли кто будет спорить, что статическая страница отдается быстрее, нежели динамическая при прочих равных условиях ;-)

Не экономьте на спичках!

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/188-re-13-tags-to-delete-from-your-theme/feed/ 8