Новогодний подарок блоггерам — WordPress 2.3.2

Как всегда я плетусь в самом конце WP-движения, это я о скорости реакции на анонсы релизов)
Уже успели выложить и две разные версии русского вордпресса 2.3.2, который только-только сошёл с конвейера (от Максима и от mywordpress.ru), но, тем не менее, я всё же рискну быть не оригинальным и отписать ещё раз изменения со своими комментариями.
И так, данные взяты из официального анонса.

Улучшена производительность, при обработке постов, перед выводом пользователю.
Надеюсь, я правильно понял, то, что написано в этом тикете.
При выводе поста, да и любой другой страницы, производится множественный вызов функции get_post, через которую работают такие функции как the_title, get_permalink и т.д. Причём, хоть данные полученные от get_posts и кэшируются, но фильтрация/отбор данных происходит после получения уже ВСЕХ данных, а не ДО, что естественно сказывается на производительности. В 2.3.2 это пофиксили.

Улучшена работа функции is_admin(). Теперь нет возможности получить доступ к «Черновикам» администраторов обычному пользователю.
О «дыре» с доступом к черновикам я уже писал, вот теперь это уже и не дыра вовсе.

Ошибки базы данных теперь показываются только при включенном WP_DEBUG.
Ещё одна перестраховка от «шибко-хитрых-хацкеров», чтобы те не могли узнать названия таблиц вашей установки WordPress, при попытках sql-инъекций.

Во время установки WordPress, при нехватке прав у пользователя БД, будет выдаваться ошибка.
А, следовательно, и не будет создан «кривой» config.

Появился шаблон для отображения ошибок при подключении к БД.
Теперь любой пользователь может внести изменения в файл wp-content/db-error.php, который будет показан при невозможности подключиться к БД (например, если превышено количество одновременных подключений).

Добавлена дополнительная проверка при обработке текста, который конвертируется в ссылку.
Тут имеет место быть событие, когда вы вставляете текст с http://, а он автоматически конвертируется в аналогичную ссылку. Повышена производительность за счёт того, что теперь функция преобразования различает обычные ссылки, фтп и почтовые ящики. Стоит отметить, что, судя по всему подобные ссылки (за исключением ящиков) автоматически будут отображаться с rel=»nofollow», во всяком случае, тут всё указывает на это.

Внесены изменения в работу рассылки почты по POP3, чтобы избежать возможных XSS-атак.
Ещё один баг закрыт.

Запрос пароля к записи будет выдаваться только тем пользователям, у кого есть права на изменение этой конкретной записи. Всё это относится только к сторонним-клиентским программам, работающим через XML-RPC.

Ещё одно изменение в XML-RPC, которое связано с отображением данных о пользователе, при вызове wp.getAuthors.
Данные теперь выводятся в более ограниченном формате, а так же добавлена проверка, что пользователь имеет минимальные права (редактирование постов), чтобы ограничить распространение информации, такой как имя пользователя, его логин и прочее.

И ещё целый ворох проверок в методах XML-RPC и App, для улучшения безопасности.

И совсем маленькое добавления при проверке путей файлов, на win-серверах.


Вот и всё. Вроде бы и не много, но и не мало. Ставить, я думаю, стоит, но… только после того, как голова и руки будут действовать активно и правильно, апосля празднования НГ, а то можно дел наворотить)

И ещё, если тов. Лекактус не против, то я бы попросил его немного подправить текст на mywordpress.ru, а то что-то слишком много орфографических ошибок и местами не понятный текст. Если нужна помощь, то могу предложить свои услуги, но опять-таки — после праздничков.

Многоуважаемые хакеры, вы имеете последнюю возможность взломать этот блог и при помощи перечисленных дыр, потому что я не тороплюсь обновляться)

Быстрее-легче-стабильнее или “немного” о Wp-Super-Cache.

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

Итак, что же может этот плагин, для чего/кого он предназначен и чем лучше аналогичных стандартных и не очень средств кэширования?


Введение
Большинству пользователей WordPress’а известен прекрасный плагин WP-Cache 2. Он кэширует страницы блога и отдаёт их по запросу без обращения к базе данных. Несмотря на это, всё же приходится подгружать определенный php-код, чтобы обслуживать уже кэшированные страницы, чтобы там не говорили на странице о wp-cache (прародитель wp-cache2)

WP Super Cache действует по другому принципу. После установки, создаются html файлы, и они отдаются браузеру без единого вызова php. Насколько быстро ваш сервер отдаёт картинки? Почти так же быстро он будет выдавать и кэшированные страницы. Если вашему сайту ежедневно приходится справляться с массированным потоком посетителей или периодически испытывать Дигг-эффект, то этот плагин для вас.

Как оно работает то?
Как обычно действуют люди, подготавливая свой сайт к массовому паломничеству с дигга? Они в ручную сохраняют копию страницы, которая теоретически будет генерить основной траффик, и помещают её в папку соответствующую пермалинку. Этот метод помогает серверу выдерживать большие нагрузки и не «умирать», но эффективность его напрямую зависит от возможности предсказывать потоки пользовательского интереса к страницам. Сам по себе WP-Cache хоть и полезен, но в определенных ситуациях не совсем адекватен, тогда как WP Super Cache как раз и был создан, чтобы воссоздавать этот процесс автоматически.

Когда к странице обращается незалогиненый посетитель или он не оставляет комментариев, то сервер отдаёт ему статическую html-страницу из подпапки supercache, которая создаётся в cache папке WordPress. Если вы зайдёте в эту папку (например по фтп), то обнаружите точную копию своей пермалинк структуры в виде папок и отдельные html-файлы в каждой из них. Чтобы убедиться, что страница создана плагином, достаточно просмотреть её исходный код и вы обнаружите там следующую строку в самом конце <!— super cache —> или <!— super cache gz —> для сжатого варианта.

Залогиненым же пользователям или тем, кто оставит комментарий, будет показана кэшированная страница, созданная средствами стандартного WP Cache, где в конце будет значится <!— Cached page served by WP-Cache —>.

Фишки/Отличия от WP-Cache

  • Собственная система hook’ов, для более тонкой настройки кэширования (важно только разработчикам).
  • Прекрасно работает и с WordPress MU в VHOST и не-VHOST конфигурациях. Файлы каждого блога кэшируются независимо друг от друга.
  • Стандартные файлы WP-Cache разбиты на 2 части. Мета-файлы теперь располагаются в отдельной папке, что увеличивает скорость обращения к ним и определения необходимости обновления кэша.
  • Встроена заплатка для WP-Cache при работе с защищенными постами.
  • Автоматически отключает gzip-сжатие в WordPress вместо того, чтобы «умереть».
  • Улучшена работа с Akismet и иными плагинами борьбы со спамом — кэш будет обновлен, только если комментарий 100% не спам.
  • Кнопка «lock down» (защёлкнуть) — подготавливает сайт к мощному наплыву посетителей. После включения «защёлкивает» статичные кэш файлы и не удаляет их после добавления нового комментария.
  • Автоматическое внесение изменений в .htaccess (Не забудьте сохранить свой .htaccess перед установкой плагина).
  • Не кэшируются запросы с GET-параметрами.
  • Улучшенная проверка совместимости wp-cache-config.php и advanced-cache.php, если вы пользовались старой версией.
  • Улучшена поддержка Microsoft Windows.
  • Правильно работает с кэшированными страницами в ОС Red Hat/Cent или других, содержащих запись для gzip в /etc/mime.types.
  • Функция «Не кэшировать следующие адреса» теперь может использовать регулярные выражения.

Минусы

  • Если вы залогинен или оставили комментарий, вы никогда не увидите super-cache страницу. Вам всегда будет выдаваться старый-добрый WP-Cache. Это не так уж и плохо, так как большинство ваших посетителей никогда не оставляют комментарии.
  • Для работы со статическими страницами используется Mod Rewrite Апача, поэтому необходимо, чтобы он был активирован на сервере.
  • Особо динамичные части вашего сайта не будут обновляться так быстро, как хотелось бы. Например, виджет — последнии комментарии.
  • Некоторые хостинги испытывают проблемы при работе со сжатыми html-файлами, т.ч. может потребоваться дополнительная настройка.
  • Не рассчитывайте, что дешевый хостинг выдержит большой всплеск трафика, даже если страницы будут кэшированы.
  • Помните, что динамический контент, вроде того, который размещается в сайдбаре, будет обновлен только когда будет обновлена кэшированная страница. Время до обновления можно настроить, но кэшированные файлы будут удалены лишь в том случае, если у вас будет смесь из статических и динамических запросов.
  • Некоторые плагины, такие как SK2, Bad Behaviour и другие, работа которых зависит от «свежести» данных, могут работать не совсем корректно, во всяком случае, до тех пор, пока эти плагины не будут специально оптимизированны для очищения кэша в нужный момент.

(с) Автор Плагина


Это всё конечно интересно и красиво на словах, но работает ли оно в действительности? Сам я не мастер нагрузочного тестирования, поэтому приведу выкладки других людей.

Во-первых, автор плагина ставит в пример себя — после анонса Wp-Super-Cache на дигге, посещения скакнули до 4700 пользователей, что прямо скажем не мало. И вот какие графики получились — первый нагрузка на процессор, второй — посещения.
wp super cache plugin cpu graph
wp super cache plugin visits graph
Отчётливо виден момент активации кэширование (падение нагрузки на процессор), а так же приятно наблюдать, что рост посещений никак не сказывается на процессоре.

Во-вторых, некий Роберт провёл замеры производительности для 1000 запросов. Тестировал по локальной сети, на сервере (P4 — 3Ghz, 2GB RAM) поставил чистый ВордПресс и с другой машины делал запросы.

Результаты:
а) стандартный WordPress без кэша:
— время на тест — 161 сек;
— запросов в секунду — 6.21/сек
— время на 1 запрос — 161 мсек
— скорость передачи — 31.07 Kbytes/сек

б) WordPress + Super Cache:
— время на тест — 5.718750 сек;
— запросов в секунду — 174.86/сек
— время на 1 запрос — 5.719 мсек
— скорость передачи — 898.62 Kbytes/сек

в) WordPress + Super Cache + eAccelerator:
— время на тест — 2.531250 сек;
— запросов в секунду — 395.06/сек
— время на 1 запрос — 2.531 мсек
— скорость передачи — 2030.22 Kbytes/сек

Думаю, комментарии излишни.

Включил сейчас плагин на этом блоге, на пару минут для теста активировал gzip-сжатие и проверил, как реагируют браузеры. С Оперой и ФФ всё ок, а ИЕ6 как обычно отличился — предложил сохранить локально .html.gz страничку) Чтобы не пугать людей, сжатие отключил, но вообще нужно будет разобраться почему ИЕ так отреагировал.

Плагин в установке достаточно прост, особенно если следовать рекомендациям в readme :-), а вот настройка для тех, кто не видел до этого Wp-Cache2, возможно покажется непонятной. С другой стороны Wp-Super-Cache довольно специфическая вещь и не факт, что окажется востребованным.

Хотелось бы узнать — нужно ли отдельным постом расписывать установку и настройку?


Кстати, курсовая и 2 из 4 экзамены сданы на отл., что ещё немного приближает ко второму красному диплому :p
Заинтересовался я тут eAccelerator, интересно, удастся ли мне поставить его на виртуальную площадку у МастерХоста. Если да, то напишу как и что я делал.
Удачного дня и побольше Дигг-эффектов.