Проекти на WordPress: поради щодо оптимізації

1. налаштовуємо СУБД
2. Вибираємо движок: MyISAM або InnoDB?
3. Оптимізація конфігурації СУБД
4. Налаштовуємо веб-сервер
5. Backend + Frontend = Apache + Nginx
6. забезпечуємо безпеку
7. висновок

Сьогодні 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 $ ./mysqlhunter.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 можна ознайомитися. Для пошуку вразливостей можна також скористатися програмою.

Змініть префікс таблиць в базі даних. За замовчуванням в базі даних 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, то він може скористатися наявними уразливими і зламати ваш сайт. Тому інформацію про версії краще видалити.

По-перше, потрібно видалити файл: http: //ваш_сайт/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', '');

Ключі використовуються для хешування паролів. Дуже часто на цей розділ не звертають уваги навіть досвідчені користувачі. Тим часом змінити ключі безпеки досить просто: достатньо зайти на сторінку і скопіювати згенеровані ключі в файл 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.