Пользователь
0,0
рейтинг
8 сентября 2009 в 19:34

Разработка → Разгоняем Wordpress до скорости света перевод

image
Скорость и отказоустойчивость – одни из тех факторов, что неизменно влияют на популярность вашего ресурса, ведь даже с лучшим в мире контентом медленно работающий сайт будет раздражать читателей и рано или поздно вы их потеряете. В этой статье мы будем оптимизировать самый популярный блоговый движок — Wordpress, работающий на PHP. А заодно рассмотрим несколько общих моментов в оптимизации сайтов.

1 Тестируем текущую скорость


Чтобы узнать изменилось ли что-нибудь после нашей оптимизации, не помешает замерять для начала текущую скорость загрузки страниц блога, чтоб было с чем сравнивать. Есть несколько инструментов, которые помогут сделать это:

1.1 Pingdom

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

1.2 YSlow

YSlow– плагин для Firefox, который встраивается в, пожалуй лучший плагин для веб разработчика, Firebug. Он анализирует более 20 факторов, которые влияют на скорость работы сайта и оценивает общую производительность по 100 бальной системе, а каждый отдельный элемент оценкой от A до F.
image

1.3 Количество запросов и время их выполнения

Вставив небольшой кусок PHP кода, можно вывести в футер количество запросов к БД и время, затраченное на их выполнение.
<?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.

2 Web Hosting


Хотите верьте, хотите — нет, но веб хостинг одна из важнейших деталей, влияющих на производительность блога. Не вдаваясь в подробности, вот очень простая характеристика наиболее популярных типов хостинга, которая поможет вам примерно оценить нагрузку на сервер:
  • Shared Hosting – на одном сервере может хоститься в среднем около 100 человек;
  • VPS – на одном сервере может хоститься около 20 человек;
  • Dedicated – сервер будет использоваться только вами.

Чтоб просмотреть примерную нагрузку на сервер, залогиньтесь через ssh и введите в консоли команду top.

Это, конечно, не означает, что вы не сможете ускорить блог, работающий на виртуальном хостинге(Shared Hosting), однако стоит помнить – производительность тем выше, чем большие ресурсы мы имеем в своем распоряжении.

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

3 Установка и настройка сервера


Удостоверьтесь, планируемая нагрузка соответствует мощности сервера и он сможет с ней справиться. В первую очередь это будет зависеть от объема оперативной памяти и процессора. Как правило, Wordpress ставят на Apache, но много удачных решений существует и на базе других http серверов: nginx, lighttpd и т.д.

Не забудьте обновить до последней версии PHP и Apache.

3.1 Отключите неиспользуемые сервисы

Вы можете получить больше доступной оперативной памяти, отключив неиспользуемые службы и оптимизировав MySQL и Apache.
  • Удалите ClamD;
  • Настроить SpamD на использование только 1 дочернего процесса;
  • Удалите Mailman, если, конечно, вы не собираетесь запускать почтовый сервис.

3.2 MYSQL Query Cache

Поскольку стабильность и скорость Wordpress довольно сильно зависит от работы БД, стоит убедиться, что настройки в my.cnf соответствуют возможностям сервера. В первую очередь следует установить настройки кэширования запросов, добавив в my.cnf следующие строки:
query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 20M

Чтоб настройки вступили в силу придется перезапустить сервис MySQL сервис.

3.3 Кэш компилятора: XCache или Eaccelerator?

Кэш компилятора увеличивает производительность откомпилированных скриптов на сервере, кэшируя их – это поможет сократить время выполнения PHP скриптов. Стоит попробовать и то и другое решение, однако по результатам опытов увеличение производительности при использовании Xcache на 5% выше, чем с Eaccelerator.

3.4 Увеличьте максимальное число соединений на Apache

Увеличение максимального количества соединений в httpd.conf повысит производительность, т.к. сервер сможет обрабатывать большее количество подключений за раз. Однако, следует изменять этот параметр осторожно, дабы не исчерпать весь объем оперативной памяти и не замедлить работу сервера, потому всегда тестируйте новые настройки прежде чем запускать их в работу. Установим к примеру 150 коннектов:
max_connections = 150

Не забудьте рестартить сервис Apache, чтоб применить настройки.

4 Оптимизация кода и графики


Итак, сервер заработал и теперь настало самое время поиграть с кодом Wordpress.

4.1 Отключите хотлинки

Каждый раз когда вы используете свой сервер для хранения изображений вы существенно больше используете его ресурсов. Довольно часто люди заимствуют ваши изображения, ставя хотлинки на своих серверах. Это не только занимает канал, но и создает определенную нагрузку на сервер.
Добавьте следующий код в .htaccess файл, заменив example.com на имя вашего домена, чтобы отключить использование хотлинков:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example\.com/.*$ [NC]
RewriteRule .*\.(gif|jpg|png|ico)$ - [F,L]
</ifModule>

4.2 Используйте внешний хостинг для хранения изображений

Хостинг изображений на внешних серверах поможет значительно снизить нагрузку на сервер. В примере ниже вы можете видеть снижение объема используемой оперативной памяти на одном из блогов после переноса изображений на сервис Amazon S3.
image

4.3 Сжимайте java-скрипт код

Сжатие javascript довольно простая задача. Поскольку он выполняется при каждом просмотре страницы, вы можете уменьшить размер Javascript, удалив все незаполненное пространство. Вот простой инструмент, который поможет сделать это за вас — JavaScript Compressor.

4.4 Javascript в начале страницы

Часто случается так, что сайт начинает загружаться медленно или вообще останавливается, т.к. другой ресурс, с которого вызывается javascript(на пример Digg badges, Tweetmeme и т.д.), не доступен или оффлайн. Чтобы избежать этого вынесите весь javascript код в конец страницы, а то что по каким-то причинам вынести не удалось – попробуйте заключить в iFrame.

4.5 Используйте кэш браузера

Сам по себе кэш браузера, конечно не сделает ваш блог быстрее, однако поможет снизить нагрузку на сервер, кэшируя часто загружаемые объекты(стили, элементы интерфейса и т.п.).
Попробуйте вставить следующий код в .htaccess файл:
FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch "\.(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

4.6 Сжимайте статические данные

Вы можете уменьшить размер загружаемой страницы позволив браузеру принимать и передавать данные в сжатом виде. Это также снизит загрузку канала и количество загружаемых данных.
Следующий код в .htaccess может помочь вам в этом:
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

4.7 Используйте CDN для статических файлов

Если хранить все изображения на одном и том же домене, то браузер будет ожидать их загрузки одного за другим. Допустим на странице их у вас есть 12 штук, если вы разделите их между тремя поддоменами, они будут загружаться одновременно из трех «разных» источников вместо того, чтоб загружаться браузером по очереди из одного.
Можете попробовать перенести все css & javascript файлы на files.yoursite.com, а изображения и временные файлы на static.yoursite.com. Или же просто использовать CDN(Content Delivery Network) – большая сеть серверов, расположенных по всему миру, которые позволят не только хранить ваши файлы на разных поддоменах, а значит загружать их параллельно, но и доставлять пользователю данные с самого близкого к нему сервера. Все это позволит загружать данные намного быстрее.

5 Wordpress


В этой части статьи мы рассмотрим приемы для улучшения производительности, которые можно применить непосредственно к Wordpress.

5.1 Обновитесь до последней версии

Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность. Для примера в wordpress 2.8 была существенно оптимизирована работа с БД.

5.2 Отключите Post Revisions

Во всех версиях wordpress, начиная с 2.6, редакции ваших статей каждый раз во время правки автоматически сохранялись. Это замедляет работу БД и увеличивает ее размер без особой надобности.
Чтоб отключить post revisions, добавьте следующую строку в wp-config.php:
define('WP_POST_REVISIONS', false);

Чтобы удалить сохраненные ранее ревизии текста, выполните следующий запрос в PHPmyadmin:
DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

5.3 Сократите количество запросов

Уберите ненужные запросы, чтоб ускорить генерацию страницы. Например, следующий типичный код, встречающийся во всех темах для wordpress:
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Мы запросто можем переписать в:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Уже на два запроса меньше. Довольно просто, не правда ли?

6 Wordpress Plugins

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

WP Super Cache
Это, пожалуй, лучший плагин к Wordpress. WP Super Cache создает статические html версии каждой страницы и загружает их каждый раз, обходясь тем самым без запросов к БД. Это значительно увеличивает скорость загрузки страниц и снижает нагрузку на сервер. Строго рекомендуется к установке.

PHP Speedy WP
Этот плагин решает другую проблему, обозначенную в этой статье – удаление незаполненного пространства в CSS & javascript. Однако есть некоторые проблемы совместимости этого плагина с WP Super Cache, кроме того он долгое время уже не обновлялся, потому используйте на свой страх и риск.

Optimize DB
Плагин позволяет оптимизировать таблицы MySQL без помощи PHPmyadmin.

Счастья тебе и твоему уютному бложеку, %username%.
Перевод: Stuart
Artem @MrTiM
карма
109,1
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (59)

  • +2
    >Отключите Post Revisions
    В этом пункте грубейшая ошибка, для отключения ревизий надо в wp-config.php вставить:
    define('WP_POST_REVISIONS', 0);
    А ваш код использовать в MySQL для удаления старых ревизий.
    • 0
      Да, разумеется. Потерял важные строки при переводе.
      • 0
        Да и отключать их — тоже грубейшая ошибка :) Напоминает «оптимизацию» Windows путём отключения системы восстановления, потом люди, которые так любят делать, ещё сетуют на то, что систему надо переставлять каждый месяц.

        У меня знакомый восстанавливал убитый кривым плагином блог. Мы восстанавливали посты, которые редактировались одновременно, и правки затирались. Мы восстанавливали неправильно сохранённые посты.
  • 0
    >Обновитесь до последней версии
    Также не очень согласен с этим пунктом, 2.8 ест ресурсов по больше чем 2.7.1… Также спешка в обновлении часто приводит к неработоспособности плагинов или их полного отсутствия под новую версию.
    • +1
      я при переезде на свежий ворпдресс получил такоооооое в админке, что до сих пор туда стараюсь заходить пореже ) (
  • +1
    Вместо чистки кода и тюнинга, лучше поставить кэш перед Apache. Личный блог считай что статический сайт и при правильных настройках будет весь закэширован.
  • 0
    По поводу WordPres сказать ничего не могу, но способы кеширования стат. данных, разнос данных по поддоменам, кеширование запросов, а также подключение акселератора — это основа оптимизации.
  • 0
    На мой взгляд WP Super Cache не лучший вариант. Лично мне больше нравится Hyper Cache, к тому же он настраивается гораздо проще. Стоило бы добавить в пост альтернативу :).
    • 0
      Особенно в конфигурациях с nginx, не надо переписывать rewrite rules… :) просто включил hypercache и он работает.
    • 0
      Тоже был удивлен, что советую использовать WP Super Cache, а не Hyper Cache. Второй показывает гораздо лучшие результаты по снижению нагрузки на сервер и как следствие времени открытия сайта.
      • 0
        как сравнивали? покажите пожалуйста результаты
    • 0
      чем вам не угодил WP Super Cache? и почему для вас Hyper Cache лучше?
      Я сравнивал оба плагина и мне больше нравится WP Super Cache, возможности у обоих плагинов одинаковые, плюс Super Cache имеет опцию «Don't cache pages for logged in users» что полезно, когда админ отлаживает новый функционал, а посетители тем временем видят кешированные страницы ;)
      А также имеет гибкую настройку того, что можно исключить из кеширования (простыми чекбоксами или продвинутыми регекспами)
      • 0
        Тем, что гипер кеш проще. Согласись далеко не всегда нужно меганастраиваемое чудо, а вот что-то что работает как надо и при этом очень быстро запускается бывает чаще. Тем более ничего против суперкеша не имею, просто предложил альтернативу, всё-таки пользователям лучше выбирать из двух вариантов, чем из одного и одного :).
  • +2
    •Shared Hosting – на одном сервере может хоститься в среднем около 100 человек; — покажите мне такой, я видел только там, где не меньше полтыщи клиентов… а еще фиг знает сколько у каждого сайтов :)
    • 0
      Ну правильно, сотня клиентов — 200-300 сайтов, считая поддомены и не считая редиректы в среднем.
      Правда обычно на один сервер есть 5-10 клиентов которые генерят 80% траффика, остальное полтора бложека, на которые только боты регулярно и заходят.
      Это из моей статистики.
      А печально то, что 60-70% вордпрессиков устарели 5 лет назад, половина кастомных тем (за многа денег) и плагинов под них (еще больше многаденег) нельзя обновлять, потому что с 90% вероятностью сайт после обновления работать не будет.
      Так и живём, того заблокировать совсем, этого в r/o + revoke insert/update на базу, чтобы не ломали.
      Грустны трудовыебудни админа маленького хостинга…
  • +17
    Разогнать wordpress до скорости света невозможно, так как при этом его масса возрастёт до бесконечности — за такой хостинг можно и нобеля получить =)
  • –2
    за общие моменты — спасибо. ещё бы про Drupal тонкостей :)
    • –1
      Мои коллеги недавно выбирали CMS для сайта, с рассчетом на расширяемый функционал, но исключив из боя фреймворки сразу. В итоге поняли, что вроде бы кроме друпала то ничего путного и нет. Но, кажется, они не смотрели, например, на symphony-cms.com/.
    • 0
      Оптимизация Drupal — habrahabr.ru/blogs/drupal/64286/
  • –3
    картинка клевая)
  • 0
    AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html

    лично у меня вызывает только 500ю ошибку…
    • 0
      Наверняка виртуальный хостинг, поинтересуйтесь у хостера насчет mod_deflate ;)
  • 0
    спасибо! некоторые моменты очень даже помогли!
  • +1
    Первый совет я бы дал — обновитесь до последней версии.
  • 0
    про Memcache забыли… хорошая штука…
    подробнее см. imountain.com/blog/2008/06/18/how-to-optimize-wordpress-memcache-and-eaccelerator/, например
  • 0
    «снизит ьнагрузку» поправьте, пожалуйста
  • –2
    Да, и для Joomla! Просто интересно почитать ;)
  • 0
    Интересно, бывает такое чтоб одновременно и wordpress, и amazon s3… :-)
    • +2
      smashingmagazine.com вполне себе может это позволить.
  • +3
    угу, осталось добавить, что весь п4 (скоро, надеюсь, и половину пунктов 3 и 5) можно заменить одной фразой — установите Web Optimizer, code.google.com/p/web-optimizator/
    • 0
      Несколько раз пробовал его прикрутить к WP 2.8.4 — так и не заработало. Вообще сайт переставал открываться.
      • +1
        стоит запостить окружение на
        code.google.com/p/web-optimizator/issues/list
        или стукнуться мне в приват — проблема будет решена. На тестовом сервере с WP 2.8.4 работает на ура
        • 0
          Спасибо за предложение о помощи!
  • 0
    Странно apache прооптимизировали, а вот поставить перед для отдачи статики, nginx как-то не догадались.
  • 0
    некто kokos просит добавить следующее, а то он не зареген…

    защита от бесполезных ботов которые сервак грузят:
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} ^BlackWidow [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Bot\ mailto:craftbot@yahoo.com [OR]
    RewriteCond %{HTTP_USER_AGENT} ^CherryPicker [OR]
    RewriteCond %{HTTP_USER_AGENT} ^ChinaClaw [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Crescent [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Custo [OR]
    RewriteCond %{HTTP_USER_AGENT} ^DISCo [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Download\ Demon [OR]
    RewriteCond %{HTTP_USER_AGENT} ^eCatch [OR]
    RewriteCond %{HTTP_USER_AGENT} ^EirGrabber [OR]
    RewriteCond %{HTTP_USER_AGENT} ^EmailCollector [OR]
    RewriteCond %{HTTP_USER_AGENT} ^EmailSiphon [OR]
    RewriteCond %{HTTP_USER_AGENT} ^EmailWolf [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Express\ WebPictures [OR]
    RewriteCond %{HTTP_USER_AGENT} ^ExtractorPro [OR]
    RewriteCond %{HTTP_USER_AGENT} ^EyeNetIE [OR]
    RewriteCond %{HTTP_USER_AGENT} ^FlashGet [OR]
    RewriteCond %{HTTP_USER_AGENT} ^GetRight [OR]
    RewriteCond %{HTTP_USER_AGENT} ^GetWeb! [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Go!Zilla [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Go-Ahead-Got-It [OR]
    RewriteCond %{HTTP_USER_AGENT} ^GornKer [OR]
    RewriteCond %{HTTP_USER_AGENT} ^GrabNet [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Grafula [OR]
    RewriteCond %{HTTP_USER_AGENT} ^HMView [OR]
    RewriteCond %{HTTP_USER_AGENT} HTTrack [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ^Image\ Stripper [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Image\ Sucker [OR]
    RewriteCond %{HTTP_USER_AGENT} Indy\ Library [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ^InterGET [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Internet\ Ninja [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Irvine [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Java [OR]
    RewriteCond %{HTTP_USER_AGENT} ^LWP [OR]
    RewriteCond %{HTTP_USER_AGENT} ^lwp [OR]
    RewriteCond %{HTTP_USER_AGENT} ^JetCar [OR]
    RewriteCond %{HTTP_USER_AGENT} ^JOC\ Web\ Spider [OR]
    RewriteCond %{HTTP_USER_AGENT} ^larbin [OR]
    RewriteCond %{HTTP_USER_AGENT} ^LeechFTP [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Mass\ Downloader [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Microsoft.URL [OR]
    RewriteCond %{HTTP_USER_AGENT} ^MIDown\ tool [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Mister\ PiX [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*NEWT [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Navroad [OR]
    RewriteCond %{HTTP_USER_AGENT} ^NearSite [OR]
    RewriteCond %{HTTP_USER_AGENT} ^NetAnts [OR]
    RewriteCond %{HTTP_USER_AGENT} ^NetSpider [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Net\ Vampire [OR]
    RewriteCond %{HTTP_USER_AGENT} ^NetZIP [OR]
    RewriteCond %{HTTP_USER_AGENT} ^NICErsPRO [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Octopus [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Offline\ Explorer [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Offline\ Navigator [OR]
    RewriteCond %{HTTP_USER_AGENT} ^omniexplorer_bot [NC,OR]
    RewriteCond %{HTTP_USER_AGENT} ^PageGrabber [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Papa\ Foto [OR]
    RewriteCond %{HTTP_USER_AGENT} ^pavuk [OR]
    RewriteCond %{HTTP_USER_AGENT} ^pcBrowser [OR]
    RewriteCond %{HTTP_USER_AGENT} dloader(NaverRobot) [OR]
    RewriteCond %{HTTP_USER_AGENT} ^ReGet [OR]
    RewriteCond %{HTTP_USER_AGENT} ^SearchExpress [OR]
    RewriteCond %{HTTP_USER_AGENT} ^SiteSnagger [OR]
    RewriteCond %{HTTP_USER_AGENT} ^SmartDownload [OR]
    RewriteCond %{HTTP_USER_AGENT} ^SuperBot [OR]
    RewriteCond %{HTTP_USER_AGENT} ^SuperHTTP [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Surfbot [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Siphon [OR]
    RewriteCond %{HTTP_USER_AGENT} ^tAkeOut [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Twiceler [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Teleport\ Pro [OR]
    RewriteCond %{HTTP_USER_AGENT} ^VoidEYE [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Web\ Image\ Collector [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Web\ Sucker [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebAuto [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebBandit [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebCopier [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebFetch [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebGo\ IS [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebLeacher [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebReaper [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebSauger [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Website\ eXtractor [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Website\ Quester [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebStripper [OR]
    RewriteCond %{HTTP_USER_AGENT} ^libwww [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebWhacker [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WebZIP [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Widow [OR]
    RewriteCond %{HTTP_USER_AGENT} ^WWWOFFLE [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Xaldon\ WebSpider [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Zeus [OR]
    RewriteCond %{HTTP_USER_AGENT} ^Technoratibot [OR]
    RewriteCond %{HTTP_USER_AGENT} ^ZyBorg
    RewriteRule .* — [F,L]
    • 0
      мне кажется, что вреда от такой нагрузки на Апач при запросе каждой страницы будет больше, нежели пользы от фильтрации таких ботов :)
  • +1
    слегка ужасно…
    нет правда. такое впечатление что звон слышен да вот только где он? я понимаю что эт оперевод и топик стартер не виноват.

    давайте пройдемся по отдельным пунктам.
    • +1
      1.3 Количество запросов и время их выполнения
      и что нам дает? нихуя. потому как запросы мы не видим.
      ставим константу в конфиг SAVEQUERIES
      ставим следующий плагин

      snipt.net/Butuzov/wp-db-debug-plugin
      — смотрим запросы, что надо профайлим.
    • 0
      3.2 MYSQL Query Cache

      Кешировать то можно на стороне MySQL сервера. хорошо что автор знает такую фигню, но нужна она? memcache обработчик гораздо гораздо ефективней, хотя бы потому что подконтрольный.
    • 0
      про статику в целом.

      первое.
      вся графика и стили и все остальное по привычке кидают в папку темы а не надо, зря.

      добавьте в файл functions.php

      $___THEME = parse_url(get_bloginfo('stylesheet_url'));
      $DIR = dirname($___THEME['path']);
      unset($___THEME);

      define('URL_CSS', $DIR.'/layout/css/');
      define('URL_JS', $DIR.'/layout/js/');
      define('URL_IMG', $DIR.'/layout/img/');
      define('URL_IMG', $DIR.'/layout/swf/');

      define('DIR_CSS', TEMPLATEPATH.'/layout/css/');
      define('DIR_JS', TEMPLATEPATH.'/layout/js/');
      define('DIR_SWF', TEMPLATEPATH.'/layout/swf/');
      define('DIR_IMG', TEMPLATEPATH.'/layout/img/');

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

      для работы темы дсотаточно лишь файла style.css с описанием.
      а в хедере где нужно прописать путь к стилям просто используем наши константы. и пишем пути к реальным стилям.
      — что до аплоадом то да, их просто необходимо вешать на сервера с повышеной отдачей статики.

      • 0
        — удалено —
        О боже, что я за человек?
    • 0
      настройки апача, мускула, енджиникса и тп и тд, это отдельный разговр… я вообще считабю святотатством что автор такую ахинею городит.

      к примеру мог бы бля посоветовать — «если ты блогер хз когда начал вести блок и пишешь по 10 постов в день, то почитай справку мускула про разбиение таблиц» потому как случай почти идеальный для этого…
    • 0
      переводчику зачет, автору… лучше промолчу.
  • +5
    5.3 Сократите количество запросов

    ржал долго. первым запросом вп вытягивает все опции и кидает их в кеш. эти значения это опции. не надо их менять, это экономия на спичках.
    • 0
      С языка снял :)
      • 0
        что?
        • 0
          первым запросом вп вытягивает все опции и кидает их в кеш. эти значения это опции.
          • 0
            это и написано в моем коментарии. что означает ваш «с языка снял»?
            • 0
              Это идиоматическое выражение означает, что мысль пришла в голову одновременно, но тот, у кого ее «сняли с языка» не успел выразить ее первый
  • 0
    Вообще да, совет использовать инклуд php в футер для того, чтобы подсчитать количество запросов уже заставляет сомневаться в компетентности советующего.

    Именно для этих целей придумана масса плагинов wtuner, который позволяет не только смотреть количество запросов, но и сортировать их по времени выполнения, и позволяет видеть те или иные особенности их выполнения относительно скорости.
    • 0
      «масса плагинов типа WPTuner», конечно же, извините за ачепятке. ;)
  • 0
    ТС забыл указать об одном из главных тормозов WP — Виджетах. При их использовании жестко падает производительность, также они не кешируются тем же WP Super Cache. Так что лучше не использовать виджеты, а прописать вывод страниц, рубрик и т.д. прямо в шаблон.
  • 0
    Также стоило было упомянуть об убирании функций перевода из шаблона — т.е. прямой перевод, и убирании перевода пользовательской части WordPress за счет wp-config.php для этого достаточно вписать в него одну строчку:
    if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU');
    В этом случаи перевод будет работать только в админке.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      tiaurus, Вы его (WP Super Cache) наверное не правильно настроили, недавно клиенту настраивал сайт, посещаемость 1200-1500 в сутки, дак супер кеш справляется на ура, также читал на одном из блоков что WP Super Cache удачно справился с 10к+ в сутки.
    • 0
      и какое это определенное количество? у меня 5к посетителей в сутки на одном блоге, SuperCache отлично работает.
  • +1
    >>Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность.
    Сравните производительность wordpress 2.8.x с 2.6.x или 2.3.x. Тут я не согласен про производительность с вами.

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

    Также не забываем про отличный плагин от Владимира Колесникова WP File Cache, который реально уменьшает нагрузку на БД. В этом случае чистить тему от
    <meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
    не придется.

    Также jQuery библиотеку и другие js бибилотеки подгружаем с google api, как это делается я писал здесь
    Также по возможности картиночки собираем в спрайты и т.д.
    Этот процесс не имеет конца, всегда можно что-то оптимизировать или улучшить ;)
  • 0
    Так же забыли упомянуть очень полезные плагины:
    — WPLANG Lite (подробнее тут)
    — прямой перевод для WP (подробнее тут)
    (не использование этих двух плагинов, приводило у меня к постоянной смене локализации сайта, как админ морды, так и главной)

    Так же вроде забыли упомянуть плагин DB Cache (лично у меня количество запросов к базе данных снизилось с 154 до 20)
  • 0
    Хотелось бы увидеть статью про то как правильно тестировать сервер под нагрузкой.

    Только что настроил себе nginx cache, результат проверял через page insights и gtmetrix. Результат — никакой разницы. Хотя заголовки X-Cache правильно работают, место в tempfs отъедается. И в принципе это понятно — такой cache проявляет себя только под сильной нагрузкой, а устроить такую нетривиально. Не со своего же хилинького ДСЛя ДДОС устраивать :) Как-то раз попробовал, задал 300 запросов в сек, так у меня домашний раутер сразу лёг.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.