Pull to refresh

Comments 59

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

У меня знакомый восстанавливал убитый кривым плагином блог. Мы восстанавливали посты, которые редактировались одновременно, и правки затирались. Мы восстанавливали неправильно сохранённые посты.
>Обновитесь до последней версии
Также не очень согласен с этим пунктом, 2.8 ест ресурсов по больше чем 2.7.1… Также спешка в обновлении часто приводит к неработоспособности плагинов или их полного отсутствия под новую версию.
я при переезде на свежий ворпдресс получил такоооооое в админке, что до сих пор туда стараюсь заходить пореже ) (
Вместо чистки кода и тюнинга, лучше поставить кэш перед Apache. Личный блог считай что статический сайт и при правильных настройках будет весь закэширован.
По поводу WordPres сказать ничего не могу, но способы кеширования стат. данных, разнос данных по поддоменам, кеширование запросов, а также подключение акселератора — это основа оптимизации.
На мой взгляд WP Super Cache не лучший вариант. Лично мне больше нравится Hyper Cache, к тому же он настраивается гораздо проще. Стоило бы добавить в пост альтернативу :).
Особенно в конфигурациях с nginx, не надо переписывать rewrite rules… :) просто включил hypercache и он работает.
Тоже был удивлен, что советую использовать WP Super Cache, а не Hyper Cache. Второй показывает гораздо лучшие результаты по снижению нагрузки на сервер и как следствие времени открытия сайта.
как сравнивали? покажите пожалуйста результаты
чем вам не угодил WP Super Cache? и почему для вас Hyper Cache лучше?
Я сравнивал оба плагина и мне больше нравится WP Super Cache, возможности у обоих плагинов одинаковые, плюс Super Cache имеет опцию «Don't cache pages for logged in users» что полезно, когда админ отлаживает новый функционал, а посетители тем временем видят кешированные страницы ;)
А также имеет гибкую настройку того, что можно исключить из кеширования (простыми чекбоксами или продвинутыми регекспами)
Тем, что гипер кеш проще. Согласись далеко не всегда нужно меганастраиваемое чудо, а вот что-то что работает как надо и при этом очень быстро запускается бывает чаще. Тем более ничего против суперкеша не имею, просто предложил альтернативу, всё-таки пользователям лучше выбирать из двух вариантов, чем из одного и одного :).
•Shared Hosting – на одном сервере может хоститься в среднем около 100 человек; — покажите мне такой, я видел только там, где не меньше полтыщи клиентов… а еще фиг знает сколько у каждого сайтов :)
Ну правильно, сотня клиентов — 200-300 сайтов, считая поддомены и не считая редиректы в среднем.
Правда обычно на один сервер есть 5-10 клиентов которые генерят 80% траффика, остальное полтора бложека, на которые только боты регулярно и заходят.
Это из моей статистики.
А печально то, что 60-70% вордпрессиков устарели 5 лет назад, половина кастомных тем (за многа денег) и плагинов под них (еще больше многаденег) нельзя обновлять, потому что с 90% вероятностью сайт после обновления работать не будет.
Так и живём, того заблокировать совсем, этого в r/o + revoke insert/update на базу, чтобы не ломали.
Грустны трудовыебудни админа маленького хостинга…
Разогнать wordpress до скорости света невозможно, так как при этом его масса возрастёт до бесконечности — за такой хостинг можно и нобеля получить =)
за общие моменты — спасибо. ещё бы про Drupal тонкостей :)
Мои коллеги недавно выбирали CMS для сайта, с рассчетом на расширяемый функционал, но исключив из боя фреймворки сразу. В итоге поняли, что вроде бы кроме друпала то ничего путного и нет. Но, кажется, они не смотрели, например, на symphony-cms.com/.
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ю ошибку…
Наверняка виртуальный хостинг, поинтересуйтесь у хостера насчет mod_deflate ;)
спасибо! некоторые моменты очень даже помогли!
Первый совет я бы дал — обновитесь до последней версии.
«снизит ьнагрузку» поправьте, пожалуйста
Да, и для Joomla! Просто интересно почитать ;)
Интересно, бывает такое чтоб одновременно и wordpress, и amazon s3… :-)
smashingmagazine.com вполне себе может это позволить.
угу, осталось добавить, что весь п4 (скоро, надеюсь, и половину пунктов 3 и 5) можно заменить одной фразой — установите Web Optimizer, code.google.com/p/web-optimizator/
Несколько раз пробовал его прикрутить к WP 2.8.4 — так и не заработало. Вообще сайт переставал открываться.
Странно apache прооптимизировали, а вот поставить перед для отдачи статики, nginx как-то не догадались.
некто 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]
мне кажется, что вреда от такой нагрузки на Апач при запросе каждой страницы будет больше, нежели пользы от фильтрации таких ботов :)
слегка ужасно…
нет правда. такое впечатление что звон слышен да вот только где он? я понимаю что эт оперевод и топик стартер не виноват.

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

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

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

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

добавьте в файл 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 с описанием.
а в хедере где нужно прописать путь к стилям просто используем наши константы. и пишем пути к реальным стилям.
— что до аплоадом то да, их просто необходимо вешать на сервера с повышеной отдачей статики.

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

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

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

Именно для этих целей придумана масса плагинов wtuner, который позволяет не только смотреть количество запросов, но и сортировать их по времени выполнения, и позволяет видеть те или иные особенности их выполнения относительно скорости.
«масса плагинов типа WPTuner», конечно же, извините за ачепятке. ;)
ТС забыл указать об одном из главных тормозов WP — Виджетах. При их использовании жестко падает производительность, также они не кешируются тем же WP Super Cache. Так что лучше не использовать виджеты, а прописать вывод страниц, рубрик и т.д. прямо в шаблон.
Также стоило было упомянуть об убирании функций перевода из шаблона — т.е. прямой перевод, и убирании перевода пользовательской части WordPress за счет wp-config.php для этого достаточно вписать в него одну строчку:
if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU');
В этом случаи перевод будет работать только в админке.
UFO landed and left these words here
tiaurus, Вы его (WP Super Cache) наверное не правильно настроили, недавно клиенту настраивал сайт, посещаемость 1200-1500 в сутки, дак супер кеш справляется на ура, также читал на одном из блоков что WP Super Cache удачно справился с 10к+ в сутки.
и какое это определенное количество? у меня 5к посетителей в сутки на одном блоге, SuperCache отлично работает.
>>Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность.
Сравните производительность 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, как это делается я писал здесь
Также по возможности картиночки собираем в спрайты и т.д.
Этот процесс не имеет конца, всегда можно что-то оптимизировать или улучшить ;)
Так же забыли упомянуть очень полезные плагины:
— WPLANG Lite (подробнее тут)
— прямой перевод для WP (подробнее тут)
(не использование этих двух плагинов, приводило у меня к постоянной смене локализации сайта, как админ морды, так и главной)

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

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