Аптымізацыя WordPress для зніжэння нагрузку на працэсар

1. пражэрлівасць WordPress
2. Асноўныя прычыны перагрузак
3. Метады барацьбы з нагрузкай
4. Блакаванне запытаў на новыя версіі
5. Аўтаматычнае кіраванне версіямі (рэвізіямі)
6. Убудова WP-Optimize
7. Аналіз «крывізны" вашага сайта

Сёння я хачу пагаварыць пра тое, як знізіць нагрузку на сервер хосцера, створаную вашым блогам на WordPress. Мне нядаўна хостынг-правайдэр даслаў ліст з папярэджаннем аб тым, што мой блог стварае нагрузку на сервер вышэй за ўстаноўлены для майго тарыфу мяжы. Прычым, гэта было ўжо другое папярэджанне і таму, не чакаючы трэцяга, я ўзяўся за даследаванне спосабаў знізіць нагрузку на сервер, якую стварае мой сайт.

пражэрлівасць WordPress

Як высветлілася, каб сайт на WordPress пачаў ствараць недапушчальную нагрузку на працэсар сервера, шмат не трэба: дастаткова 15-20 раз запар (з паўзай не больш 0,75 секунды) клікнуць па адной і той жа спасылцы або проста адкрыць з крайняй хуткасцю 15- 20 старонак сайта ва ўкладках ці ж панаціскаўшы F5 ў браўзэры дзясятак разоў.

Калі недапушчальнай нагрузкай правайдэр называе ўжо 5%, то такім вось няхітрым клікання, калі вельмі пастарацца, можна выклікаць нагрузку, калі верыць логам, да 28 працэнтаў (!!!). А цяпер уявім, што клікаць пачаў не адзін карыстальнік, а два? Так, праблема актуальная толькі для віртуальнага хостынгу, ды і то ёсць думкі, як яны маглі б гэта аптымізаваць ... Але тым не менш праблема існуе.

Таксама высветлілася, што з кожнай новай версіяй WP становіцца ўсё пражэрлівей. Скажам, калі версія 2.3.3 спажывала менш за 10 Мбайт памяці, то 2.7.1 - не менш за 20.

Практыка паказвае, што мой сайт з кучай віджэтаў часам спажывае да 45-55% працэсарнага часу. Адкуль жа бяруцца такія лічбы?

Малюнкі, стылі і скрыпты - гэта "статычнае зьмест". Яно не змяняецца з цягам часу, і на такія звароты трэба менш за ўсё рэсурсаў (працэсарны час практычна не выкарыстоўваецца, памяці трэба мінімальная колькасць). Зрэшты, калі да Вас на сайт з выключна статычнымі матэрыяламі будзе заходзіць 100 тысяч чалавек у суткі, нагрузку ён усё роўна будзе ствараць прыстойную. Але ў нашым выпадку асноўная праблема - гэта "дынамічнае зьмест".

Скажам, на Добра адлюстраванне старонкі WordPress 2.8 марнуе Каля 19 Мб Памяці І 1 секунду гадзіне. Гэтя значыць, Што на Працяг 1 секунды, усім астатнім кліентам вашага хостынгу недаступна прыкладна 25 мегабайт памяці. Выкажам здагадку, Што Ў Вас - 100 наведвальнікаў у суткі І Ў сярэднім Яны ажыццяўляюць 3 просмтра старонкі. Значыць, Ваш сайт расходуе недзе 300 * 25 Мбайт памяці на працягу 300 секунд. У маштабах цэлых сутак - усё нармальна.

Але выкажам здагадку, што ў сайта пачынае расці наведвальнасць (да 150 чалавек у суткі), ці ж Вы ўсталявалі якой-небудзь супер-пупер новы убудова, і спажыванне памяці WordPress ўзрасла да 30 Мбайт. Такім чынам, спажыванне рэсурсаў хосцера вырасла прыкладна на 50%. Калі хостер палічыць, што Вы спажываеце занадта шмат памяці і працэсарнага часу за тыя грошы, якія Вы яму плаціце - Вам будзе адпраўлена папярэджанне аб магчымым адключэнні сайта і прапанова змяніць тарыфны план.

Такім чынам, дынамічнае змесціва - гэта лішнія запыты да БД і выдаткі працэсарнага часу. Прычым, чым больш у кодзе вашага шаблока запытаў да БД, тым больш будзе нагрузка. Фактычна, кожны дадаваны убудова і віджэт, якія для сваёй працы нешта выбіраюць з базы, ствараюць лішнюю нагрузку.

Іншымі прычынамі вялікай нагрузкі на працэсар могуць быць DDoS-атакі і праца пошукавых робатаў. З улікам таго, што яны могуць адкрываць памногу старонак запар ці ўвогуле адначасова, а баніць іх нельга, бо куды ж без іх, то могуць зноў жа паўстаць праблемы з хосцерам.

Асноўныя прычыны перагрузак

Асноўныя прычыны, па якіх блог вельмі моцна нагружае хостынг:

1. Выснова апошніх каментароў (звычайна ставяць на адлюстраванне 10 апошніх - а гэта дадатковыя 10 запытаў да БД)
2. Выснова апошніх навін у адмысловым блоку (няма сэнсу ў гэтым блоку, калі на галоўнай старонцы амаль ва ўсіх і адлюстровываюцца 5-10 апошніх навін)
3. Выснову самых Каментуемыя навіны (ізноў жа лішнія запыты ...)
4. Вялікая колькасць зусім не патрэбных устаноўленых віджэтаў.
5. Шмат зноў жа не патрэбных ўсталяваных убудоў.
6. Множныя лішнія запыты ў самым шаблоне, якія можна замяніць на статычнае змесціва.

Метады барацьбы з нагрузкай

Для пачатку, трэба высветліць, што здарылася нядаўна. Магчыма, у сайта рэзка вырасла папулярнасць. Магчыма, сайт быў нядаўна абноўлены (ўсталяваная свежая версія WordPress). Магчыма, Вы дадалі новую старонку або ўсталявалі новы убудова? .. Магчыма, Ваш прайс-ліст павялічыўся ўдвая?

Часта праблему можна вырашыць шляхам уключэння кэшавання. Напрыклад, для WordPress гэта можа быць убудова WP-SuperCache . У ModX на патрэбных старонках можна паставіць сцяжок "кэшируемый дакумент". У Drupal гэта робіцца ў меню "Наладка сайта -> Прадукцыйнасць". Для Joomla можна спампаваць PageCache .

Убудовы кэшавання для WordPress: Гэта WP-Cache, WP Super Cache, Hyper Cache, WP File Cache.

WP-Cache

У прынцыпе - WP-Cache версіі 2.0 - распрацаваны ў 2005 годзе і з таго часу апошнія абнаўлення вырабляліся ў 2007 годзе, так што выкарыстоўваць напэўна ня пажадана ў сілу ўсе ж вялікіх зменаў у самым рухавіку і выхаду версіі 2.7.

WP Super Cache

Самы распаўсюджаны ў дадзены час убудова. Аўтар плагіна - Donncha O Caoimh. Старонка плагіна - http://ocaoimh.ie/wp-super-cache/.

WP Super Кэш з'яўляецца убудовай статычнага кэшавання для WordPress. Ён генеруе HTML файлы, якія абслугоўваюцца непасрэдна Apache без апрацоўкі параўнальна цяжкіх PHP скрыптоў. З дапамогай гэтага плагіна вы істотна можаце паскорыць ваш блог WordPress.

недахопы:

- патрабуе досыць вялікая дыскавая прастора для захоўвання дадзеных кэшавання;
- маюцца неўстараненнем праграмныя памылкі (пакуль), якія часта прыводзяць да "падзення" сервера (пачытаць можна тут - http://blog.sjinks.org.ua/wordpress/521-wp-super-cache-under-high-load/ );
- досыць складаны ў ўстаноўцы (патрабуе рэдагавання wp-config.php і .htaccess) і наладзе.

Hyper Cache

Прынцып працы практычна аднолькавы з WP Super Cache. Таксама стварэнне статычных старонак, іх захоўванне і выдача пры звароце да сайта.

Сайт аўтара ўбудовы - http://www.satollo.com/, хатняя старонка плагіна - http://www.satollo.com/english/wordpress/hyper-cache.

недахопы:

- таксама шмат памяці пад кэш старонак;
- незразумелая апрацоўка старонкі 404 і кладка ў кэш;

- лічыцца, што яго прадукцыйнасць пры множных патоках і запытах ніжэй, чым у Super Cache.

WP File Cache

Гэта той убудова, які мне спадабаўся і які магу Вам параіць. Таму ў дачыненні да яго больш аб перавагах. А яны наступныя:

- рэалізацыя доўгачасовага кэшавання на ўзроўні запытаў;
- поўная сумяшчальнасць з інтэрфейсам класа WP_Object_Cache WordPress;
- выкарыстанне памяці пад сесійны кэш для павелічэння прадукцыйнасці;
- сесійнай кэшаванне часта зменлівых аб'ектаў;
- захоўванне налад у кодзе плагіна;
- першапачаткова на рускай і англійскай мовах;
- рускі аўтар, адпаведна руская падтрымка і иструкции.

Аўтар плагіна - Уладзімір Калеснікаў, хатняя старонка плагіна - http://blog.sjinks.org.ua/wordpress/plugins/190-wp-file-cache-replacement-for-wp_object_cache-with-persistent-caching/.

Аб тэставанні прадукцыйнасці кэшаў можна пачытаць тут http://blog.sjinks.pro/wordpress/683-wp-supercache-vs-hypercache-vs-w3-total-cache-vs-maxsite-cache/ і ў працягу артыкула http: / /blog.sjinks.pro/wordpress/725-689-wp-super-cache-vs-maxsite-cache-part-2/

Кароткія высновы: на пісьменна наладжаным сэрвэры лідзіруе WP Super Cache - і па хуткасці, і па стваранай нагрузцы.

Нядаўна выявіўся і іншы убудова, які працуе інакш, чым звычайныя кэшы.

Убудова DB Cache Reloaded з'яўляецца інструментам, якія забяспечваюць дынамічныя кэшаванне запытаў да базе даных. Праца гэтага плагіна грунтуецца на зусім іншых, выдатных ад убудоў статычнага кэшавання, прынцыпах, і дазваляе істотна павялічыць хуткасць загрузкі блога і знізіць нагрузку на хостынг.

Кожны раз, калі фармуецца старонка блога, ідуць запыты да базы дадзеных, пасыланыя тэмай, фішкамі, ўбудовамі. DB Cache Reloaded кэшуецца гэтыя запыты, накіроўваючы іх у далейшым не ў базу дадзеных, а ў кэш, доступ да якога больш хуткі. У выніку колькасць зваротаў да базы дадзеных змяншаецца ў некалькі разоў (у маім выпадку, з 25 да 5). Гэта зніжае загрузку працэсара і выкарыстанне аператыўнай памяці - зніжаецца агульная нагрузка на хостынг, памяншае час генерацыі старонак блога. Налады плагіна мінімальныя, ёсць код, які можна ўставіць у footer.php для адлюстравання часу загрузкі блога, колькасці зваротаў да базы дадзеных і аб'ёму спажыванай аператыўнай памяці.

Спампаваць DB Cache Reloaded

Калі простым кэшаваннем не абышлося - патрэбен погляд прафесіянала. Неабходна знайсці "дрэнны" убудова або модуль, і абнавіць, паправіць ці замяніць яго. Наўскідку - магу парэкамендаваць адключыць модулі статыстыкі і выкарыстоўваць замест іх лічыльнік LiveInternet або Google Analytics. Поўная аптымізацыя сайта можа заняць велізарная колькасць часу (і грошай), так што ухіляйце праблемы па меры іх узнікнення :)

Блакаванне запытаў на новыя версіі

Рухавічок WordPress уладкованы такім чынам, што пры кожным ўваходзе ў адміністрацыйную частку ён глядзіць, ня абнавіўся Ці які-небудзь убудова. Як ён гэта робіць? У кожным убудове прапісаная яго старонка, звычайна гэта падзел у каталогу убудоў на сайце wordpress.org. Заходзячы туды, ён параўноўвае версію, усталяваную ў ў вас з той, што знаходзіцца на сайце ўбудовы. Калі там больш новая, то ён прапануе аднавіць плягін.

Тое ж самае ён робіць і ў адносінах да самога сябе - кожны раз правярае, не зрабілі ці распрацоўшчыкі WordPress новую версію. Зразумела, што такая праца ад'ядаецца ў вашага сайта і так тыя нешматлікія мегабайты памяці, якія вылучаюцца правайдэрам на яго функцыянаванне.

Я не прывык часта абнаўляць убудовы, і, адзін раз падабраўшы іх і наладзіўшы, аддаю перавагу больш з імі не важдацца, вызнаючы прынцып "працуе - не чапай!". Таму мне дастаткова тры-чатыры разы на год правяраць, ці не выйшла Ці новая версія якога-небудзь, плагіна, а на астатняе час адключаць гэтую функцыю.

Раней я рабіў гэта рукамі, выпраўляючы канфігурацыйны файл. Так працягвалася, пакуль Калінін Iван не зрабіў убудова, які на лета пазбаўляе WordPress праверкі на абнаўленне убудоў. Разам з тым ён адключае і сам WordPress ад праверкі на абнаўлення. Называецца гэты убудова Блакаванне запытаў на новыя версіі . Працуе убудова проста: актывавалі - працуе, не актывавалі - не працуе.

Аўтаматычнае кіраванне версіямі (рэвізіямі)

Пасля таго, як вы отредактируете які-небудзь пост, WordPress захавае папярэдні варыянт, каб у выпадку чаго можна было зрабіць адкат. Але вось няўдача - гэта "ў выпадку чаго" ў мяне здараецца вельмі рэдка, і па сутнасці ўсе гэтыя дублі папярэдніх версій майго паста мне не патрэбныя. WordPress робіць такія бэкапы перыядычна, і яны ўсё назапашваюцца і назапашваюцца. Траціцца месца для іх, а рухавічок знаходзіцца ў стане пастаяннага кантролю і бэкапу. Думаю, што мне гэта не трэба, таму я адключаю такую ​​магчымасць (не спрачаюся, для кагосьці можа і карысную), а заадно экономлю месца на сэрвэры і зніжаю нагрузку на рухавічок за кошт памяншэння базы дадзеных.

Як і ў выпадку з праверкай на абнаўлення, раней я рабіў гэта ўручную, выпраўляючы файлы ў тэкставым рэдактары, але гэтаму прыйшоў канец, калі я знайшоў убудова, які робіць усё гэта аўтаматычна: кіраванне версіямі .

Пасля ўстаноўкі убудова пакажа, у якіх пастоў ёсць версіі. Думаю, што яны вам даўно ўжо не патрэбныя, можаце выдаляць іх. Пасля гэтага нядрэнна б пазначыць, ці варта вам наогул рабіць такія рэвізіі пастоў, і калі і варта, то з якой перыядычнасцю, і ў якой колькасці. Я наогул прыбраў ўсё.

Гэты убудова, як я ўжо і казаў, дазваляе не захламляць базу дадзеных залішняй інфармацыяй, а чым менш база дадзеных - тым хутчэй працуе WordPress.

Абодва плагіна добрыя перш за ўсё тым, што не трэба лезці ў код і рэдагаваць яго ўручную. Да таго ж, дэактывацыя убудоў прыводзіць да аднаўлення налад па змаўчанні. Гэта не адзіныя варыянты паскарэння працы WordPress, але яны - самыя даступныя.

Убудова WP-Optimize

Вы ведаеце, што пры выдаленні спамерскіх паведамленняў, яны не выдаляюцца з базы дадзеных, а проста хаваюцца з вачэй далоў? Не ведаю, для чаго так прыдумалі распрацоўшчыкі WordPress, але асабіста мне гэтая калекцыя нябачных какашек дакладна не патрэбна. Хоць я яе і не бачу, але месца яна ў базе дадзеных займае. А нам патрэбны рэвізіі пастоў?

Я думаю, што пасля таго, як пост апублікаваны, яго прамежкавыя версіі не патрэбныя нікому. Распрацоўшчыкі WordPress і на гэты выпадак маюць сваё, адрознае ад іншых, меркаванне - усё рэвізіі захоўваюцца ў базе дадзеных. Не ведаю, ці патрэбныя яны іншым, але я за ўвесь свой час знаёмства з WordPress, ні разу не скарыстаўся рэвізіямі. Каб пазбавіцца ад усяго гэтага непатрэбнага баласту, можна скарыстацца убудовай WP-Optimize.

Убудова можа адным клікам выдаляць усе спамерскія паведамлення, усе непацверджаныя паведамленні, аптымізаваць базу дадзеных, пазбаўляючыся ад непатрэбных дадзеных, а так жа хутка мяняць лагіны карыстальнікаў. Пры аптымізацыі табліц будзе паказаны вынік.

Спампаваць WP-Optimize

Аналіз «крывізны" вашага сайта

Для таго, каб праверыць колькі ж запытаў да базе дадзеных адбываецца пры загрузцы той ці іншай старонкі вашага сайта вы можаце скарыстацца вядомым убудовай WP Tuner - спампаваць плягін WP Tuner . Убудова усталёўваецца стандартным спосабам, а менавіта:

• распакуйце архіў wptuner.zip, выкарыстоўваючы ftp-менеджэр падключыцеся да вашага сайту і загрузіце тэчку wptuner ў тэчку з убудовамі wp-content / plugins / на сэрвэры
• ўвайдзіце ў адмінку wordpress і вылучыце ўкладку «Убудовы» - «Inactive»
• знайдзіце радок з убудовай WP Tuner і актывуйце яго
• Пасля актывацыі, WP Tuner павінен прапісаць у wp-config.php свае налады. Для гэтага трэба часова адкрыць гэты зайл на запіс з правамі 666 ці прапісаць невялікі кавалак кода ўручную.
• Калі код аўтаматычна не прапісаўся, пра гэта скажа сам убудова ў выглядзе памылкі і яе апісання.

Зараз можна зайсці ў адмінку вашага блога і азнаёміцца ​​з наладамі плагіна WP Tuner. У адмінку выбіраем з левага меню Налады -> WP Tuner.

Уласна, налад то не так ужо і шмат, да таго ж для таго, каб гэты убудова пачаў паказваць колькасць запытаў да базе даных пры загрузцы старонкі блога, наогул нічога мяняць не трэба. Трэба проста перайсці на сайт з админпанели (гэта трэба для таго, каб вы на сайце былі пад лагінам адміністратара) і адкрыць якую-небудзь старонку вашага сайта. Пасля заканчэння загрузкі пракруціць старонку ўніз і вы ўбачыце пад футером вашага сайта акно плагіна WP Tuner. На малюнку, прыведзеным ніжэй паказана, дзе можна ўбачыць лік запытаў да базе даных, якое было выраблена пры загрузцы гэтай старонкі.

Звычайныя наведвальнікі сайта, натуральна, гэтага бязладдзя бачыць не будуць, толькі адміністратар блога, г.зн. вы.

Але паглядзець лік запытаў да базе даных можна і не звяртаючыся да паслуг убудоў. Для гэтага трэба атрымаць доступ да файлаў вашага сайта па FTP І адкрыць на рэдагаванне , Напрыклад, файл /wp-content/themes/название_вашей_темы_оформления/footer.php і дзе-небудзь у код гэтага файла трэба ўставіць наступную канструкцыю (месца ўстаўкі будзе вызначаць месца вываду колькасці запытаў у футере або па іншаму - падвале вашага блога):

1 <? Phpif (is_user_logged_in ()) {?&gt; 2 <? Phpecho get_num_queries (); ?&gt; Queries in <? Php timer_stop (1); ?> Seconds.

У выніку, пасля загрузкі старонкі вашага сайта, у самым нізе старонкі вы ўбачыце колькі пры гэтым было зроблена запытаў да базе даных.
Гэтая інфармацыя будзе даступная толькі залогиненным карыстальнікам блога. Г.зн. калі ў вас на блогу рэгістрацыя адключаная, то гэты надпіс будзеце бачыць толькі вы.

Як паменшыць нагрузку, ствараную пошукавымі ботамі, можна пачытаць тут http://n-wp.ru/2074.

Аб аптымізацыі шаблонаў для зніжэння колькасці запытаў да БД мы пагаворым у асобным артыкуле.

(Наведванняў: 567, з іх сёння: 1)

Спадабалася публікацыя? Чаму няма? Пакінь коммент ніжэй або падпішыся на feed і атрымлівай спіс новых артыкулаў аўтаматычна праз feeder.