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