Проекты на WordPress: советы по оптимизации

  • Tutorial
wordpress

Сегодня Wordpress является одной из самых популярных CMS. Задуманная изначально как движок для блогов, сегодня она используется для самых разных типов сайтов, в частности, для новостных порталов и интернет-СМИ. На Wordpress работают корпоративные веб-сайты, образовательные и развлекательные порталы.

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

Подробных инструкций по установке и настройке Wordpress в Интернете опубликовано немало. В этой статье мы бы хотели затронуть вопросы, которым в большинстве публикаций о Wordpress не уделяется достаточно внимания. Мы расскажем о том, как оптимизировать работу сайтов на Wordpress, а также дадим ряд рекомендаций по повышению уровня безопасности и стабильности работы. Во всех примерах используется Ubuntu 12.04.

Настраиваем СУБД


Выбор СУБД


Как известно, для работы Wordpress необходима СУБД MySQL. В последнее время широкое распространение получили альтернативные реализации (форки) этой СУБД, наиболее популярными из которых являются Percona Server и MariaDB. Во многих инструкциях по установке, опубликованных в Интернете, рекомендуется использовать MariaDB.

Мы же рекомендуем использовать Percona Server, так как этот форк по сравнению со стандартным MySQL является более производительным и стабильным. Кроме того, Percona обладает более широкими возможностями для сбора системной статистики.

Чтобы установить Percona на сервер, нужно сначала импортировать ключи:
$ apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A

Затем нужно добавить в файл /etc/apt/sources.list следующие репозитории:
deb http://repo.percona.com/apt precise main
deb-src http://repo.percona.com/apt precise main

И выполнить команду:
$ sudo apt-get update

После этого можно устанавливать percona-server при помощи стандартного менеджера пакетов:
$ sudo apt-get install percona-server-server percona-server-client

Выбираем движок: MyISAM или InnoDB?


Самыми популярными движками в MySQL-базах являются MyISAM и InnoDB. Если движок выбран неправильно, то возникают проблемы с производительностью и консистентностью.

Рассмотрим особенности этих движков более подробно.

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

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

InnoDB используется в современных версиях MySQL как движок по умолчанию.
В отличии от MyISAM InnoDB поддерживает транзакции и внешние ключи. В Percona Server используется собственный движок — XtraDB, полностью совместимый с InnoDB. Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.

Статей, посвященных сравнению MyISAM с InnoDB/XtraDB, а также MySQL c его форками, опубликовано немало (см., в частности, тест производительности здесь). Мы не будем вдаваться в теоретические подробности и ограничимся практическим советом: MyISAM нужно выбирать только в случаях, когда нужен полнотекстовый поиск. Со всеми остальными задачами прекрасно справятся InnoDB/XtraDB. Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.

Оптимизация конфигурации СУБД


По мере развития сайта количество данных в БД будет расти, и возникнет необходимость изменений настроек базы данных. Чтобы обеспечить оптимальную работу сайта, желательно регулярно проверять, насколько оптимально настроена действующая конфигурация MySQL. Такую проверку проще всего осуществлять с помощью специальных скриптов, самым известным и популярным из которых является mysqltuner.pl. Его можно скачать при помощи следующих команд:
$ wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
$ chmod +x ./mysqltuner.pl
$ ./mysqltuner.pl

Этот скрипт собирает статистику MySQL и выдает рекомендации по улучшению существующих настроек.

Настраиваем веб-сервер


Параметры Apache


Настройки apache хранятся в файле /etc/apache2/apache2.conf

В конфигурационном файле Apache имеется такой параметр, как max_clients — максимальное количество процессов, запускаемых для параллельной обработки клиентских запросов. На первый взгляд может показаться, что для этого параметра нужно устанавливать максимальное значение. В реальной практике, однако, все бывает по-другому.

Допустим, один процесс Apache может потребить 20 Мб оперативной памяти. Если для параметра max_clients выставлено значение 200, то при пиковой нагрузке под все процессы потребуется 200×20 Мб = 4Гб памяти — и это только под Apache! В результате нехватки памяти даже самые простые запросы будут выполняться крайне медленно. И программное обеспечение на сервере может перестать работать.

Поэтому слишком большое значение параметра max_clients выставлять не желательно. Если количество запросов превысит установленное значение, то все эти запросы будут поставлены в очередь и обработаны, как только освободятся занятые процессы.

В целях повышения производительности рекомендуется также отключить keepalive-соединения, исправив соответствующую строку в конфигурационном файле:
KeepAlive off 

Backend+Frontend = Apache +Nginx


Любой более или менее высоконагруженный веб-проект должен иметь многоуровневую архитектуру (об этом мы уже писали). Для большинства проектов на базе Wordpress вполне подойдет двухуровневая архитектура Backend — Frontend. Мы рекомендуем использовать следующую связку: в качестве бэкенда Apache, в качестве фронтенда — Nginx.

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

К тестам, опубликованным в Интернете, нужно относиться со здоровой долей скептицизма: нередко php-fpm+Nginx показывает лучшие результаты лишь потому, что Apache не был настроен должным образом (см., например, отчет о тестировании и его критический разбор; см. также любопытную дискуссию здесь). На основании собственного опыта можем сказать, что для большинства проектов на Wordpress комбинация Apache+Nginx вполне подойдет. Выбор решения должен основываться не только и столько на приросте производительности, сколько на специфке решаемых задач и соображениях технологического удобства. А Apache, на наш взгляд, отличается большей гибкостью конфигурирования. Он может использоваться и как отдельный веб-сервер, и как бэкенд для Nginx, и как фронтенд для php-fpm.

Общая схема работы выглядит так: Nginx принимает запросы от пользователей, которые затем либо передает Apache, либо обрабатывает самостоятельно. Apache будут передаваться запросы, связанные с обработкой динамического контента — например, php-скриптов. Nginx самостоятельно обрабатывает запросы на отдачу статики — например, графики, JS, CSS, текстовых файлов, XML-файлов.

Apache обработав запрос и передав содержимое Nginx, отключается и переходе к обработке других запросов. Благодаря этому работа существенно ускоряется (что немаловажно, например, при медленном интернет-подключении).

Кроме того, раздачу динамических запросов можно ускорить с помощью сервера Memcached (см., например, инструкцию по установке и настройке здесь).

Обеспечиваем безопасность


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

Защититесь от вредоносных программ и уязвимостей в скриптах на сервере, на котором установлен Wordpress. Мы рекомендуем использовать сканер ClamAV+Maldet. С инструкцией по установке и настройке AV можно ознакомиться здесь. Для поиска уязвимостей можно также воспользоваться программой WPScan.

Измените префикс таблиц в базе данных. По умолчанию в базе данных Wordpress установлен префикс «wp_». Это упрощает использование уязвимостей с MySQL-инъекцией: если известно имя таблицы, в нее гораздо проще вставить вредоносный код, изменить в ней информацию или вообще удалить. В новых версиях Wordpress появилась возможность выбора префикса при установке.

Если вы используете раннюю версию Wordpress, то изменить префикс можно с помощью специализированных плагинов. Наиболее известным и популярным является Prefix Changer. Следует, однако, учесть, что многие из этих плагинов не всегда работают корректно, поэтому перед их использованием рекомендуется сохранить резервную копию базы данных.

Переместите файл wp-config.php. В файле wp-config.php хранятся важные параметры настройки Wordpress, которую желательно защитить от несанкционированного доступа. По умолчанию этот файл сохраняется в корневом каталоге, но его можно переместить на каталог выше. Не обнаружив файла wp-config.php в корневом каталоге, Wordpress будет искать его автоматически.

Получите SSL-сертификат и включите SSL-шифрование. Для этого в файл wp-config нужно добавить следующие строки:
/* Enable SSL Encryption */
define(‘FORCE_SSL_LOGIN’, true);
define(‘FORCE_SSL_ADMIN’, true);

Удалите информацию о версии Wordpress. Если злоумышленник узнает, что вы используете устаревшую версию Wordpress, то он может воспользоваться имеющимися уязвимостями и взломать ваш сайт. Поэтому информацию о версии лучше удалить.

Во-первых, нужно удалить файл: ваш_сайт/readme.html, из которого можно без труда узнать, какую версию Wordpress вы используете.

Об используемой версии можно также узнать из файла header.php, который находится в папке с темой. Он содержит следующую строку:
<meta name="generator" content="WordPress " />

Можно удалить всю эту строку целиком. Если в файле header.php вашей темы оформления нет такой строки, то, скорее всего она вставляется автоматически Wordpress'ом при вызове функции wp_head(). В таком случае удалить информацию о версии из секцииможно, добавив в файл functions.php следующий код:
remove_action(’wp_head’, ’wp_generator’);
function selectel_remove_version() {
return ’’;
}
add_filter(’the_generator’, ’selectel_remove_version’);

Измените ключи безопасности. В упомянутом выше файле wp-config.php есть раздел с ключами безопасности. Выглядит он так:
define(’AUTH_KEY’, ’’);
define(’SECURE_AUTH_KEY’, ’’);
define(’LOGGED_IN_KEY’, ’’);
define(’NONCE_KEY’, ’’);

Ключи используются для хэширования паролей. Очень часто на этот раздел не обращают внимания даже опытные пользователи. Между тем изменить ключи безопасности довольно просто: достаточно зайти на страницу https://api.wordpress.org/secret-key/1.1 и скопировать сгенерированные ключи в файл wp-config.php. Эту процедуру достаточно осуществить всего один раз во время первичной настройки сайта.

Ограничьте доступ к папкам wp-content и wp-includes. Из соображений безопасности рекомендуется закрыть доступ к содержимому папок wp-content и wp-includes. Нужно закрыть доступ к любым файлам, кроме графики, JS и СSS. Для этого нужно в каждой папке создать файл .htaccess и поместить в него такой код:
Order Allow,Deny
Deny from all
Allow from all

Создайте пустой файл wp-content/plugins/index.html. Благодаря этому станет недоступной информация о том, какие плагины вы используете. В плагинах Wordpress могут содержаться уязвимости, и этим могут воспользоваться злоумышленники.

Чтобы сделать листинг недоступным, можно также добавить в файл .htaccess, хранящийся в папке с плагинами, следующую строку:
Options -Indexes

Ограничьте доступ к папке wp-admin.

Чтобы ограничить доступ, нужно в этой папке создать файл .htaccess и поместить в него следующий код:
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName «Access Control»
AuthType Basic
order deny,allow
deny from all
# указываем, например. IP-адрес домашнего компьютера
allow from 
# здесь указываем адрес один или несколько IP-адресов, с которых мы будем писать в блог на работе
allow from 
allow from 

Ограничивать доступ определенным набором IP-адресов не всегда удобно. Можно настроить доступ к папке wp-admin только по паролю. Для этого нужно создать файл .htauth:
$ htpasswd -c /home/yourdirectory/.htauth

И поместить его на один уровень выше директории /public_html/
Затем нужно создать в папке wp-admin файл .htaccess и поместить в него следующий код:
AuthName «Admins Only»
AuthUserFile /home/yourdirectory/.htauth
AuthGroupFile /dev/null
AuthType basic
require user <имя пользователя>

Заключение


Настройка даже такой простой и интуитивно понятной CMS, как Wordpress — дело довольно непростое и содержащее большое количество нюансов, на которые не всегда обращают внимание даже опытные пользователи. Мы надеемся, что приведенные рекомендации будут вам полезны. Со своей стороны мы всегда готовы оказать помощь по настройке и оптимизации сложных проектов на Wordpress в рамках нашего нового пакета услуг по администрированию серверов.

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

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

Selectel

193,00

ИТ-инфраструктура для бизнеса

Поделиться публикацией
Комментарии 70
    +4
    Многие советуют скрывать версию WordPress, но на самом деле её всегда можно определить по другим косвенным признакам. Вот старенькая статья на эту тему: codeseekah.com/2012/02/20/the-wordpress-meta-generator-tag-paranoia/.

    Мне для настройки безопасности очень нравится плагин iThemes Security: wordpress.org/plugins/better-wp-security/
      0
      Рекомендую присмотреться еще и к этому плагину — All In One WP Security & Firewall
        0
        А можете кратенько пояснить какие у него плюсы по сравнению с iThemes Security?
      +12
      Лучше не скрывать версии, а подменять на старые. Сразу же отфутболиваются малолетние кулц-хакеры. Не разобравшись почему 2-х летняя xss не сработала, они обычно просто уходят.
        –8
        >> Выбираем движок: MyISAM или InnoDB?
        Прекратите насиловать труп!
          +1
          Это вы о чем?
            +3
            Это о MyISAM, самом лучшем аналоге CSV-файлов
          0
          Ребята, Вы даже не представляете на сколько Вы в тему с этим постом. Спасибо!
            +1
            Рады помочь. )
            +2
            Подскажите, а почему бы не использовать один nginx, без apache вообще?
              0
              NGinx не работает с PHP, т.е. бекенд (Apache/php-fpm) для выполнения php-скриптов нужен будет в любом случае.
                +1
                  +2
                  Забавно, что даже название статьи по ссылке «FastCGI Example (with PHP FPM)».
                  Это как-то противоречит моим словам?)
                    +2
                    Ну либо я чего-то не понимаю, объясните, что именно подразумевается под «работой с PHP»?
                      +1
                      nginx не умеет сам интерпретировать скрипты, написанные на php, что тут непонятного?:)
                        +2
                        А если сформулировать по-другому.
                        Почему бы не использовать один веб-сервер в связке с PHP FPM, вместо двух веб-серверов, один из которых только из-за того, что он умеет PHP?
                          +3
                          Это не формулирование по-другому, это другой вопрос.

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

                          В статье мы рассматривали Apache, потому что до сих пор часто ставится только он один. По этой же причине многие конфиги писались под Apache, хотя могли бы быть написаны под NGinx и тогда производительность была бы выше.
                      +5
                      Кажется я начинаю понимать. Вы имеете ввиду что сам по себе nginx не работает с PHP?

                      Ну да, не работает, но вы же сами указываете php-fpm в качестве обработчика PHP.

                      Вот меня и интересует вопрос, какой смысл устраивать связку nginx → apache → php-fpm, если ее можно сократить до nginx → php-fpm, при этом исключится любитель кушать память на каждый запрос apache.

                      Собственно, я и хотел узнать, может в связке nginx+apache+php-fpm, действительно, есть какой-то необходимый случай?
                        +1
                        У Apache стандартно php-скрипты обрабатываются модулем mod_php и необходимости проксировать дальше на php-fpm нету.

                          +1
                          Речь шла не об этом, но вы уже изменили и статью. Ясно. Спасибо. Останемся каждый при своем мнении.

                          А по поводу вышесказанного, знаю что связка WP+WP Super Cache+nginx+php-fpm, будет работать, где apache уже ляжет напрочь. Тестировал лично.
                            +1
                            В статье пока мы поменяли только опечатку с mysqlhunter.pl на mysqltuner.pl. ;)

                            Выше есть предупреждение о холиварах php-fpm/Apache.
                    +1
                    Ну и касаемо WP+nginx.
                    Я хотел узнать в чем преимущество связки, а оказывается вон оно как.
                  0
                  Спасибо!
                  Очень полезно всё это иметь в одной статье.
                    +2
                    Вы пишите, что:
                    MyISAM показывает хорошие результаты на выборках SELECT, что во многом обусловлено отсутствием поддержки транзакций и внешних ключей.


                    Но ведь 99% процентов обращений к БД в Вордпресс — это как раз селекты. Почему тогда лучше использовать InnoDB (с точки зрения производительности)?
                      +2
                      Вообще Вордпресс создавая БД из коробки не использует никаких особенностей InnoDB. Поэтому Для Вордпресса, имхо, эффективнее MyISAM.
                        0
                        Т.е. если особенности InnoDB не используются, то MyISAM производительней?)
                          +1
                          Нет. MyISAM в принципе производительней.
                          А если особенности InnoDB не испольщуются, то MyISAM — предпочтительней.
                            +1
                            Ради интереса провел небольшой тест:
                            Померил выборки из MyISAM и InnoDB
                            root@blog:/home/www# time for i in {1..1000}; do mysql wordpress -e "SELECT * FROM wp_options" >/dev/null; done
                            
                            real	0m14.314s
                            user	0m10.729s
                            sys	0m2.060s
                            root@blog:/home/www# free -m
                                         total       used       free     shared    buffers     cached
                            Mem:          2012       1378        634          0        164        464
                            -/+ buffers/cache:        749       1263
                            Swap:            0          0          0
                            root@blog:/home/www# for n in `mysql wordpress -B -N -e "show tables;"`;do mysql wordpress -B -N -e "ALTER TABLE $n ENGINE=InnoDB;";done
                            root@blog:/home/www# time for i in {1..1000}; do mysql wordpress -e "SELECT * FROM wp_options" >/dev/null; done
                            
                            real	0m16.113s
                            user	0m12.037s
                            sys	0m2.628s


                            2 секунды разницы на 1000 запросов. Т.е. MyISAM быстрее выполняет запрос на  0,002 секунды.
                            Если у вас такие объемы, что эта разница существенна, то вы не будете использовать MyISAM уже по соображениям надежности в Highload.
                              +4
                              Вообще-то для показа одной страницы Вордпресс может выполнять десятки запросов к БД, так что 2 секунды на 1000 запросов это совсем не мало.
                              К тому же «SELECT * FROM таблица» — это совсем непоказательный пример, странно что вообще получилась разница.
                        0
                        99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.
                        Там была ссылка на тесты, где описаны варианты Read-only для MyISAM и InnoDB.
                        На шаред-хостиге, когда ваши данные из БД наверняка будут читаться с дисков, MyISAM может быть производительнее.
                          0
                          99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.


                          Какие еще сессии и т.п.? Речь про БД Ворпресса в MySQL.
                            –1
                            Вы не собираете статистику о поведении пользователей?
                            Скиньте свой «mysqladmin status», посмотрим соотношение чтения/записи.
                              +1
                              Собираю, конечно. В Google Analytics.
                                0
                                Я посмотрел на стандартном проекте соотношение чтение/записи — вы правы, извиняюсь. Почти 98%.
                                Однако InnoDB всё равно быстрее.
                                Можно, к примеру, посмотреть тест Oracle:
                                www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf
                                График RO — разница в 4,5 раза это очень много.
                                  0
                                  Я не специалист по MySql и не агитирую за MyISAM, т.к. до прочтения вашей статьи понятия не имел, чем он отличается от InnoDB. Но на основании вашего утверждения

                                  MyISAM показывает хорошие результаты на выборках SELECT

                                  я сделал предположение, что для Вордпресса имеет смысл использовать MyISAM.

                                  Если «InnoDB всё равно быстрее», то это значит, что результаты InnoDB на выборках SELECT все равно лучше.

                                  P.S. В тестах по вашей ссылке графики начинаются с шести процессорных ядер. Возможно, что на 1-2 ядрах MyISAM окажется быстрее.
                                    +1
                                    Перестаньте путать людей. MyISAM/InnoDB — все зависит от конкретного проекта. Какую из таблиц в каком типе держать — зависит от каждого случая. От оъема данных, сложности архитектуры, собственно самих запросов. Блог или новостной портал, даже очень большой, будет использовать одни запросы. Интернет-магазин или каталог — другие. Появление запросов по meta_key, больших объединяющих запросов, сортировок по meta_value существенно изменит поведение, так как пойдет полнотекстовый поиск, вылезут узкие места с индексами. Если используются свои кастомные таблицы — отдельная история. Вот исходя из этого надо тестировать и выбирать наиболее подходящий тип для каждой конкретной таблицы. А для более-менее стандартного сетапа и среднестатистического сайта, коих большинство — нет никакой разницы. Так что эту рекоммендацию можно смело опустить.
                                      0
                                      Часто вы так тестируете? Поделитесь статистикой какой движек когда используете. Или расскажите в каких случаях что использовать. Какой смысл говорить, что всё меняется от случая к случаю и лучше тестировать? Это и так очевидно.
                          0
                          > MyISAM нужно выбирать только в случаях, когда нужен полнотекстовый поиск. Со всеми остальными задачами прекрасно справятся InnoDB

                          А почему не пользоваться полнотекстовым поиском в InnoDB? Больше года как доступен.
                            0
                            Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.

                            Не все готовы пользоваться MySQL 5.6
                              0
                              И какие будут причины его не использовать? Стабильность на высоте, новые фишки прямо-таки говорят «юзай нас».
                                +1
                                Плюсов много, согласен. Но сейчас 5.6 не является дефолтной версией в дистрибутивах ОС.
                                Очень многое переписано, от этого переход в дефолтную стабильную ветку не такой быстрый. Из опыта помню сам как повелся на mysql 5.5 и поставил его, а потом нарвался на баг и моя InnoDB-шная база покрашилась.
                                  0
                                  А какая разница, какая версия в дистрибутиве? В чем проблема обновить дистрибутив или поставить альтернативный источник?
                                  Что касается стабильности, то 5.6 давно проверенная и стабильная версия.
                                    0
                                    Посмотрите на ChangeLog и на длинные полотна под заголовком «Bugs Fixed»:
                                    dev.mysql.com/doc/relnotes/mysql/5.6/en/
                                      0
                                      Посмотрел. В 5.5 аналогичные.
                                        0
                                        Из 5.5 в 5.6 перешли баги, но не наоборот.

                                        В 5.6 их в два раза больше, хотя и в 5.5 много.
                                          0
                                          Приводите конкретные баги, мешающие вам жить, а не список всего-всего.
                            0
                            Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.

                            И у MyISAM кэшеруются, просто на уровне системы.

                            И почему вдруг отключение KeepAlive повысит производительность?
                            Скорее снизит расходы памяти и создаст лишние тормоза для клиента.
                              0
                              1) ОС кеширует не данные MyISAM, а страницы на уровне бинарников (Page Cache) и метаданные этих бинарников. Они же оттуда очень легко вымещаются.

                              2) www.opennet.ru/base/dev/keepalive_apache.txt.html
                              0
                              Удивительно, но мне казалось что все эти действия многим очевидны. Оказалось нет.
                              Ничего нового не узнал, но все равно спасибо
                                +2
                                Ещё следует добавить установку/активацию php-акселяторов типа opcache и xdebug.
                                А также специальные wordpress плагины типа WP Super Cache и W3 Total Cache.
                                  0
                                  С каких пор xdebug является accelerator'ом? Вы его случаем с APC не путаете?
                                    +1
                                    Думаю, что речь шла о XCache, просто опечатался человек в пятницу вечером)
                                      0
                                      Ну, такое допустимо, да и не только в пятницу)
                                  +13
                                  Вы забыли упомянуть, что InnoDB потребляет раза в 4 больше пространства на жестком диске, и при большом объеме данных (раз уж речь идет о крупных и высоко-нагруженных проектах), это не всегда может быть оправдано.

                                  Связка Apache + nginx используется в основном только тогда, когда клиентам хостинга необходимо предоставить доступ к файлу .htaccess, во всех остальных случаях nginx + php-fpm уже давно стал стандартом для WordPress.

                                  > В новых версиях Wordpress появилась возможность выбора префикса при установке.

                                  Ну да, в новых… Лет так 11 назад ;) core.trac.wordpress.org/changeset/664/

                                  > Переместите файл wp-config.php.

                                  Это делается далеко не из соображений безопасности, а только потому, что так работать удобнее если директория с ядром WordPress подтягивается и обновляется с помощью системы контроля версий, например Subversion или Git. Получается, что в самой директории ничего никогда не меняется, а меняется лишь wp-config.php и wp-content, которые оба могут находится за пределами директории ядра.

                                  > Ключи используются для хэширования паролей

                                  Ключи не используются для хэширования паролей, иначе при смене ключа у вас бы ни один старый пароль не подошел. Ключи используются для генерации куки аутентификации, и «одноразовых» чисел (nonce) в WordPress. Менять эти ключи можно когда угодно, при смене всех вошедших пользователей лишь «выбросит» из админки и им придется войти повторно. Более того, это хороший метод защиты, когда у вас например украли куки браузера.

                                  > Удалите информацию о версии Wordpress

                                  Как уже кто-то отметил в комментариях — это глупость. Версию ядра WordPress можно легко узнать из версий внешних библиотек, например jQuery, TinyMCE. Лучше не прятать версию а вовремя обновляться и использовать надежный пароль, возможно 2-уровневую аутентификацию. А наличие тега rel=generator помогает лишь сбору статистики.

                                  Ботам, которые брутфорсят пароли от WordPress, или ищут уязвимости в темах использующие старый TimThumb совершенно не важно какая у вас версия ядра. Им даже не важно стоит ли у вас WordPress :) Есть ответ по 80-му порту — будут бомбить.

                                  > Ограничьте доступ к папкам wp-content и wp-includes.

                                  Может быть wp-content, но не wp-includes, там есть некоторые .php файлы, к которым необходим прямой доступ, например wp-includes/js/tinymce/wp-mce-help.php. Не исключено, что в новых версиях появятся и другие.

                                  > Ограничьте доступ к папке wp-admin.

                                  Тоже не совсем просто. В этой директории есть некоторые файлы, которые исполняются с фронтенда без необходимости авторизации пользователей в WordPress, например любые темы или плагины, которые используют AJAX в WordPress проходят через wp-admin/admin-ajax.php.

                                  P.S. Если кому-то интересна тема высокой посещаемости и WordPress, крайне рекомендую: WordPress под нагрузкой: масштабирование и отказоустойчивость :)
                                    +2
                                    Спасибо, Константин. Очень многое прояснили, особенно про «wp-admin» видно что человек который писал статью, написал немного из своего опыта, а потом просто передрал то, чего уже написано огромное множество, не опробовав советы самостоятельно.

                                    И как уже писалось, плагин iThemes Security решает большую половину проблем с безопасностью WP, особо не напрягая при этом конечного пользователя.

                                    Также совет «Создайте пустой файл wp-content/plugins/index.html» тоже бестолковый, если он для пользователей которые не ковыряют конфиг сервера, тогда предыдущие по оптимизации явно не для них, а если он для админов, то лучше посоветовать закрыть просмотр директорий на сервере, чтобы не пришлось таких еще пустых файлов создавать по всем папкам плагинов :)

                                    Опять же, не ковыряя сервер и не изменяя СУБД можно получить неплохой прирост используя например:

                                    WP+Hyper-Cache

                                    НУ и если углубляться, почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache? Очень толковый мануал вот здесь: rtcamp.com/wordpress-nginx/tutorials/single-site/fastcgi-cache-with-purging/

                                    Ах, ну и раз уж вы эту статью написали для того, чтобы в конце вставить:

                                    Со своей стороны мы всегда готовы оказать помощь по настройке и оптимизации сложных проектов на Wordpress в рамках нашего нового пакета услуг по администрированию серверов.


                                    Почитайте, что предлагают в услуге «Управляемый хостинг» буржуи rtcamp.com/wordpress-nginx/managed-hosting/, ценник там конечно другой немного, но думаю что будет интересно.
                                      +1
                                      > посоветовать закрыть просмотр директорий на сервере, чтобы не пришлось таких еще пустых файлов создавать по всем папкам плагинов
                                      Это же написано в статье, читайте внимательнее.

                                      > iThemes Security решает большую половину проблем с безопасностью
                                      «Я закрыл половину дыр в безопасности, теперь всё ок».
                                      Советы давались исходя из того как часто встречаются такие проблемы, а не для админов senior-уровня.

                                      > почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache
                                      Еще не написано про squid и varnish, про CDN, рассылку новостей по миллионам подписчиков и многое другое.

                                      Ссылка на managed-hosting интересная, спасибо.
                                      0
                                      С большинством согласен, спасибо за комментарий.

                                      Про размер InnoDB намеренно не говорил. БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах. Даже если вы выделяете под MySQL отдельную дисковую подсистему из SSD дисков, их хватит в большинстве случаев за глаза и за уши.
                                      Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.

                                      Размер бинарников может быть существенен, когда речь идет о резервном копировании. Вроде как чем меньше бинарников, тем быстрее все скопируется. Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись, сбросить кеш, создать снапшот и разлочить. Но у InnoDB можно без блокировок создать косистентный дамп.
                                        +1
                                        Спасибо за ответ!

                                        > БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах.

                                        О блогах это вы зря :) Именно в блогах и СМИ авторы публикуют по 200 записей в день, причем по 40 редакций и десяток внедренных объектов oEmbed в каждой, а уж если вы поддерживаете, скажем сеть сайтов в режиме multisite, то «отдельной дисковой подсистемой» можно и не обойтись, и прирост объема в 4 раза может хорошо сказаться на стоимости поддержки, именно поэтому WordPress.com до сих пор крутится на MyISAM.

                                        > Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.

                                        Это совершенно не странно, во-первых потому, что несмотря на наличие транзакций и откатов в InnoDB, ядро WordPress ими не пользуется, ровно так же как и внешними ключами, которые вообще практически весь смысл теряют, как только мы переходим на шардинг данных.

                                        Во-вторых, блокировка таблиц влияет только на запись, а для большинства крупных и высоко-посещаемых проектов на WordPress соотношение чтения к записи слишком велико, чтобы об этом даже думать, потому и сложно например встретить репликацию master-master с WordPress, несмотря на то, что такая репликация хорошо поддерживается тем же XtraDB Cluster.

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

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

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

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

                                        И все же, InnoDB это круто :) и главная причина по которой WordPress.com до сих пор работает на MyISAM (и частично на MariaDB) — это объем, потому я и затронул эту тему в моем предыдущем комментарии.
                                          0
                                          1) > Во-вторых, блокировка таблиц влияет только на запись...
                                          Это не так и это очень важный момент.
                                          Когда идет SELECT, блокируется вся таблица на запись и на обновление.
                                          Когда идет запись, ставится блокировка на чтение всей таблицы (в MyISAM таблица — минимальная еденица блокировки). А это жуткие проседания времени ответа при обновлении данных или добавлении новых постов. Вы приводите пример с огромным ресурсом, где данные переваливают за 100G, значит записи в базу идут с достаточно высокой скоростью. И тогда варианта два — или изменяемые таблицы постоянно недоступны для чтения или часто изменяемые данные (как например таблица с коментами) переводится в InnoDB. Если таблицу с коментами на таком ресурсе не перевести в InnoDB, то будут большие задержки на сайте и попросту будет забиваться очередь запросов в MySQL. Если забьется очередь, то сляжет всё.
                                          Если допустить, что мы таблицу с коментами перевели в InnoDB, т.к. в неё идет много записей, то стоит вспомнить, что у таблицы с постами есть поле comment_count, которое обновляется при каждом добавлении или удалении комента. И не только оно постоянно обновляется, но и to_ping и pinged.
                                          Т.е. локи идут и на таблицу с постами.
                                          Интересно у вас, как у Wordpress core-developer-а узнать, что вы с этим делаете в MyISAM.

                                          2) Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.

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

                                          4) > Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.
                                          Прочитали? А теперь забудьте про этот метод бекапа)
                                          Если вы так бекапитесь, что у вас почти 100% будут недописанные данные. А я напомню как MyISAM восстанавливает поврежденные данные — он их просто удаляет.
                                          Вот так вы обновляли значение количества комментариев под постом, а в результате пропал весь пост.

                                          P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.
                                            0
                                            > Когда идет SELECT, блокируется вся таблица на запись и на обновление.
                                            > Когда идет запись, ставится блокировка на чтение всей таблицы

                                            Вы правы, только это происходит не всегда, см. dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html

                                            Но дело даже не в этом. Когда слейв читает с мастера, он группирует запросы на изменение таблиц последовательно, поэтому на реплике они выполняются гораздо быстрее, чем на мастере. При этом на крайний случай всегда есть --low-priority-updates или возможность приостановить слейв на время. Опять же, самое худшее, что мы можем получить из этой ситуации это лаг.

                                            > Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.

                                            Мультисайт: wpmag.ru/2014/wordpress-multisite/

                                            > Если вы так бекапитесь, что у вас почти 100% будут недописанные данные.

                                            Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;

                                            > P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.

                                            Обязательно.
                                              0
                                              По первой части — я бы посмотрел решение проблем с блокировками более детально, думаю это уже не совсем стандартный WP. Так навскидку не вижу возможности играться с приоритетностью без потерь. Я бы, честно, пошел в сторону уменьшения размера БД или (если надо подешевле) поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.

                                              > Мультисайт: wpmag.ru/2014/wordpress-multisite/
                                              Простите, может я что-то проглядел, но не увидел там причины того, что базы под WP должны занимать 100G+. :((

                                              > Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;
                                              Могу дополнить — если выводите реплику и с неё бекапите, то нужно еще засинкать логи и перемонтировать раздел в RO (обычного sync после флаша таблиц недостаточно, хотя уже лучше). MySQL 5.6 умеет подниматься на RO девайсах. :)
                                                0
                                                > Я бы, честно, пошел в сторону уменьшения размера БД

                                                Вот мы и пошли в сторону MyISAM :)

                                                > поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.

                                                Так репликам ж тоже с дисков читать надо.

                                                > не увидел там причины того, что базы под WP должны занимать 100G+. :((

                                                Суть в том, что в режиме мультисайт вы можете поднять неограниченное количество сайтов под одной установкой ядра и БД WordPress. Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит.

                                                Иными словами — сеть блогов любого университета, не говоря уже о крупных проектах как edublogs.org, happytables.com и т.д.
                                                  0
                                                  > Вот мы и пошли в сторону MyISAM :)
                                                  Ненене :) Мы решили, что надо базу уменьшать, а не бинарники) Кстати, там на больших объемах разница в размере далеко не в 4 раза.

                                                  > Так репликам ж тоже с дисков читать надо
                                                  Не увидел проблемы.

                                                  > Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит
                                                  В базу в 1Гб можно поверить, но в 100 таких проектов на одном сервере (с зеркалированием/реплицированием и т.п.) нет. Я достаточно проработал админом в одном из лучших шаред-хостеров России, чтобы утверждать, что вы скорее упретесь поочереди во все другие ресурсы, чем в размер дисков под базы.
                                                  Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят. Если не будете оверселить ресурсы, то на один сервер ну клиентов 20 влезет и то, базы у больше части не будут такие здоровые.
                                                  Если у вас базы уже дошли до 100G+ и вы используете MyISAM для экономии места, то это архитектурная проблема, которая всё равно вылезет потом.
                                                    0
                                                    > Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят.

                                                    Здесь речь идет не о шаред-хостинге :) WordPress.com это сервис на основе WordPress мультисайт, который развернут на более тысячи серверов в 6 дата-центрах на 3-х континентах. БД шардится на более 600 серверов MySQL, на каждый из которых приходится в среднем по ~ 400 запросов в секунду. Можете представить какой у нас объем.

                                                    Это конечно самый крупный публичный проект на WordPress, поэтому его можно назвать крайним случаем, и здесь вполне оправдан выбор MyISAM, несмотря на то, что InnoDB был бы эффективнее.

                                                    Тем не менее, возьмите типичный американский университет, где студентам и преподавателям предоставляется возможность создать сайт и вести свой блог. Такого объема как у WordPress.com у них в сети никогда не будет, но поверьте, 100 ГБ они быстро наберут, особенно если добавить элементы соц. сети, например с помощью BuddyPress.

                                                    В общем я не говорю, что нужно использовать MyISAM. Все знают, что у InnoDB будущее куда светлее, чем даже у MariaDB. Но тот факт, что InnoDB потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        > Спасибо автору, но после «Ubuntu 12.04» советы по оптимизации и безопасности — не воспринимаются серьезно.
                                        Обоснуйте, пожалуйста.

                                        Мы-то как раз не используем NGinx+Apache, у нас php-fpm стоит и CDN и много чего еще, но это другая история. Статья написана для клиентов, а Apache более универсальный. Иногда костыль удобней.
                                          0
                                          А зачем выключать кипалайв?
                                          0
                                          Все говорят о том, что ngnix с php-fpm лучше Apache с mod_php, но почему?
                                          • НЛО прилетело и опубликовало эту надпись здесь

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

                                          Самое читаемое