Архивы блога

Влияние PHP-акселератора на потребление памяти WordPress

Возвращаясь к теме потребления ресурсов, затронутой здесь и здесь

Ради теста отключил загрузку PHP-акселератора eAccelerator в конфиге php.ini и увидел такую картину:

потребление памяти на «чистом» WP2.7

  • без всяких хаков и лайт-перевода — около 17мб на главной странице.
  • с лайт-переводом и хаком update.php — около 14мб.
  • с лайт-переводом, хаком и включенным акселератором — 3мб.

время генерации страниц 0,05-0,15сек 
Продолжить чтение →

31 комментарий

Почему вы выбрали Русский WordPress «Lecactus Edition»?

Чьим переводом WordPress вы пользуетесь?

Просмотреть результаты

Загрузка ... Загрузка ...

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

  1. Почему вы выбрали именно мою версию русского перевода WordPress?
  2. Считаете ли вы что мой перевод более качественный и полноценный по сравнению с «официальным«?
  3. Пользовались ли вы раньше «официальным» переводом и почему решили перейти на мою «сборку»?
  4. Что на ваш взгляд является решающим при выборе источника новых версий Русского WordPress?
  5. Нужны ли дополнительные опции в файле конфигурации WordPress? Например опция снижения «нагрузки»
  6. Ваши пожелания автору

Как правильно перейти на Русский WordPress Lecactus Edition, Вы можете прочитать в Часто Задаваемых Вопросах и Ответах

60 комментариев

ВП-ТЕСТЕРС ОПАСНОСТЕ!

В группу вп-тестерс на гугле попало нечто (смотрите сверху. ) — для истории скриншотег 18+

10 комментариев

нашлись еще баги wp2.7beta3

1 Несколько часов ломал голову и не мог понять что произошло. Если кто заметил некоторое время назад у меня на сайте показывалась всякая бяка — это я миксовал дампы базы. В итоге даже восстановил дамп на тестовый домен и там баг тоже проявлялся. проявлялся он и при экспорте-импорте записей (про это отдельный разговор — похерились такким образом ВСЕ теги — преобразовались в цифры. никогда не любил этот тип переноса данных). Но это все фигня

посмотрите на два скриншота

так показан список страниц с стандартным шаблоном ссылок

так показан список страниц с стандартным шаблоном ссылок

так показан список страниц с любым другим шаблоном ссылок

так показан список страниц с любым другим шаблоном ссылок

при этом если во втором случае (с чпу) «быстро редактировать» страницы то они вообще пропадают из списка. и приватная страница не показывается в списке сверху (там видно что всего 26страниц а публичных только 25). и еще при работающем ЧПУ не работают вообще скрин опшнс в управлении страницами — т.е. не отключаются колонки: автор, дата и т.д.

долгая чистка таблицы опций во время поиска багов дала тоже свои положительные результаты — выкинул из нее 1мб мусора (с 1,2мб до 200кб примерно снизил) и отрубил все rss в доске объявлений чтобы снова не засорялось.

2 сразу после апдейта с 2.6.3 до 2.7 на двух сайтах заметил что файлы стали загружаться не в папку 2008/11 а в 0000/00. Проблема решилась сама после захода в «Разные настройки» и их сохранении.

3 в визуальном редакторе (при использовании плагина расширенного редактора) почему то не добавляется сразу подпись картинки (та что в рамке), а вставляется она под картинкой. если зайти в свойства картинки и изменить там подпись то вижу что поле пустое. после заполнения его все на месте

4 вчера кажется оставили мне комент где был три раза тег < CODE >. так вот в списке коментов в админке этот комент был «залочен», т.е. у него отсутствовали ссылки на редактирование, ответ и т.п.

ищем дальше… пишу багрепорты в wp-testers иногда, но что то не реагировали еще ни разу

16 комментариев

Простой и эффективный поиск «узких мест» в вашем блоге на WordPress!

Обнаружен прекрасный плагин для поиска узких мест в вашем блоге WordPress, а именно показывает: какие файлы темы как быстро обрабатываются, какие плагины кушают сильно много ресурсов, какие запросы слишком медленные и т.п. полная детальная статистика, показывающая даже какой файл движка или плагина делает какой запрос и сколько он длится, сколько потребляет ресурсов

Плагин работает с WordPress 2.0.6-2.7 !

http://wordpress.org/extend/plugins/wptuner/

wptuner


Продолжить чтение →

77 комментариев

I like WP2.7

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

31 комментарий

Снижение потребления ресурсов WordPress

Если кто знает, то одно из отличий версий WordPress 2.3.1-2.3.3 сборки Maxsite.org от оригинальной было то что использовались различные языковые файлы для админчасти блога и самого «лица» блога. Тогда это давало существенный прирост в скорости работы сайта, за счет уменьшения вызовов этих самых строк (более подробно можете почитать в его свежем посте о MaxSite CMS, где снова была затронута эта тема). Как я уже там отметился в коментах — попробовал тоже самое сделать в свежей версии 2.7 (на последней бете) на своем сайте. Результат просто поразительный.  Повторю цитаты из моих коментов по ссылке выше:

если файл локализации (полновесный ru_RU.mo весит 350кб) установлен как обычно, то
MySQL: 45запросов / 0.577 Потребление памяти: 13.3MB
а если его убрать вообще, то
MySQL: 45запросов / 0.550 Потребление памяти: 10.1MB
если подсунуть вместо «полновесного ru_RU.mo» кастрированный файл который «ru_RU_lite» переименовав его в ru_RU.mo то потребление памяти вырастает всего килобайт на 300 вместо трех мегабайт

замена в конфиге строки стандартной

define ('WPLANG', 'ru_RU');

на

if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU'); else define ('WPLANG', 'ru_RU_lite');

снизило потребление на главной странице до…7,7мб.

Пересмотрел я все плагины что у меня стоят и для перевода «лицевой» части блога потребовалось лишь скопировать несколько файлов имяплагина-ru_RU.mo в имяплагина-ru_RU_lite.mo, вообще бОльшая часть плагинов ведь переводится только в админ-части, поэтому и у вас получится всего несколько файлов отдельных переводов по 2-30кб.

В итоге получилось (для главной страницы) примерно так MySQL: 45запросов / 0.441 Потребление памяти: 8.6MB

Даже без калькулятора понятно что 8,6мб это существенно меньше оригинальных 13,3мб. Скорость загрузки страниц также повысилась

Испытание на «голом» сайте WP2.7 также показало снижение нагрузки примерно на 3мб и время генерации страницы в среднем на 0,1сек

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

Добавить ли такую опцию для снижения нагрузки в дистрибутив WP2.7 ?

  • Да (97%, 188 голосов)
  • Нет (3%, 6 голосов)

Всего проголосовало: 194

Загрузка ... Загрузка ...

P.S. все вышеописанное вы можете применить и к WP 2.5-2.6.3

Скачать «лайт» версии перевода ru_RU_lite.mo для различных версий вы можете по этим ссылкам

2.5.1 | 2.6.3 | 2.7

156 комментариев

Супер, супер.. ГИПЕР!

Недавно появился новый плагин для кэширования в WordPress. Когда я ставил недавно версию 1.0, то она была откровенно глючная и работало все только еще медленнее, но проблема похоже исправлена. Новая версия 2.0.1 радует!

Что делает и как работает? Да примерно точно также как и знаменитый wp-supercache, за одним исключением двух вещей:

1 позволяет ПОЛНОЦЕННО кэшировать страницы даже если указан шаблон ссылок стандартный в виде «вопросиков и параметров», т.к. не создает структуру на диске в виде папок, а просто складывает файлы .dat в свою папку с кэшем

2 кэширует даже ошибки 404, которые не кэширует вообще плагин wp-supercache

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

4 в отличии от плагина wp-supercache тут для зарегистрированного и обычного посетителя выдается однотипный кэш

по скорости работы сайтов не уступает wp-supercache, а если учесть что только у этого плагина есть то что описано в пункте 1, то для некоторых он является единственным подходящим решением

Более подробно про плагин написано у автора

Устанавливается плагин просто

1 Скачайте плагин здесь и распакуйте папку из архива в wp-content/plugins. Если нужно скачайте мой русификатор и распакуйте файл из него в папку плагина wp-content/plugins/hyper-cache

2 Если вы ранее пользовались плагином wp-supercache, то деактивируйте его и удалите файл (символьную ссылку) advanced-cache.php

3 Установите права 777 на папку wp-content

4 Активируйте плагин и перейдите в настройки. Если сверху вы не увидите предупреждений на розовом фоне, то все нормально, если увидите — см пункт 2 и 3

5 в wp-config.php добавьте если еще нет

define( 'WP_CACHE', true );

6 Установите настройки (там все понятно даже для новичков)

7 Откройте любую страницу в браузере и посмотрите есть ли в конце исходника страницы строка типа <!— hyper cache: f94ca670035c4975bab89a1b20c31efb —> и проверьте создаются ли файлы в wp-content/hyper-cache

У себя поставил на своем блоге и на тестовом сайте. Работает пока отлично и на 2.6.3 и на 2.7бета. Скорость радует, глюков не заметил. А вообще автор пишет что работает плагин на всех версиях начиная с 2.1

64 комментария