Аптымізацыя сервера пад Drupal з замерам вынікаў

  1. замест прадмовы
  2. эксперыментальная мадэль
  3. эксперыментальнае абсталяванне
  4. Дадзеныя «сырога» сервера
  5. аптымізацыя PHP
  6. аптымізацыя MySQL
  7. тэсты LoadImpact
  8. замест заключэння

Сама па сабе інструкцыя аб тым, дзе што падкруціць на сэрвэры, каб Drupal стаў працаваць хутчэй, сустракаюцца на прасторах інтэрнэту ў рознай ступені дэталізацыі. Аднак усе сустраканыя мне артыкула валодалі невялікім заганай: я не сустракаў якіх-небудзь рэальных замераў, якія спадарожнічалі наладзе. Як колькасна змяняецца хуткасць генерацыі старонкі? Як змяняецца выкарыстанне памяці? Што адбываецца пры павелічэнні колькасці паралельных запытаў? Давайце правядзем эксперымент. Некаторыя рэкамендацыі, выкладзеныя ў артыкуле, носяць агульны характар ​​і могуць быць карысныя для іншых CMS.

замест прадмовы

У аснову дадзенага артыкула легла падборка матэрыялаў Server tuning considerations , Размешчаная на афіцыйным сайце Drupal. З яе адабрана тое, што носіць найбольш універсальны характар ​​і можа быць дастасавальна да адвольнага серверу, на якім плануецца выкарыстанне Drupal (у прыватнасці, секцыі, якія тычацца налады PHP і MySQL). Гэты артыкул не ахоплівае пытанні тонкай налады самой CMS.

эксперыментальная мадэль

Для праверкі нагрузкі быў створаны нейкі эталонны цяжкі сайт. Для гэтага быў выкарыстаны Drupal 7 і некалькі папулярных модуляў, у тым ліку Views і Pathauto. У адзін з тыпаў матэрыялу было дададзена лікавае поле, якое магло прымаць значэнне ад 1 да 10. З дапамогай функцыі генерацыі кантэнту модуля Devel было створана каля 10 тыс. Старонак матэрыялу дадзенага тыпу і ад 0 да 15 каментарыяў да кожнага пасадзе.

Далей быў створаны і размешчаны на галоўнай старонцы блок Views, абіралы 100 выпадковых старонак, дзе поле прымала значэнне 5 (г.зн., калі верыць тэорыі верагоднасці, 100 з 1000 старонак) разам з каментарамі да іх. Крытэрый фільтрацыі Global: Random быў выкарыстаны, каб старонка гарантавана генераваць па-новай пры кожнай загрузцы. На асабістым тэставым серверы час генерацыі такой старонкі складала прыкладна 10 секунд. Таксама пры падрыхтоўцы быў узняты тэставы інтэрнэт-крама на базе Commerce Kickstarter і згенеравана каля 5 тыс. Тавараў. Аднак высветлілася, што Global: Random зусім не сябруе з Search API, а без рандомизации старонка з 96 прадуктамі Грузія адчувальна хутчэй, чым папярэдняя тэставая старонка. Таму замеры па хуткадзейнасці інтэрнэт-крамы не праводзіліся. Тэставыя сайты былі перанесены на ...

эксперыментальнае абсталяванне

Для эксперыментаў я запазычыў на некалькі дзён свежаўсталяванай VPS Intel Xeon E3-1230 3.2GHz / 2-3 GB RAM / 30 GB SSD і Intel Xeon E3-1230 / 8GB DDR3 / 4x1TB SATA2 / 100Mbps Unmetered у Нідэрландах (далей па тэксце - VPS і Е3-1230 адпаведна). На серверах былі стандартна настроеныя LAMP + Nginx. Асноўная частка замераў выраблялася утылітай ab з агульным лікам запытаў 1000 і лікам паралельных запытаў ад 10 да 50. Па заканчэнні таксама было запушчана некалькі тэстаў Loadimpact.

Дадзеныя «сырога» сервера

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

На гэтым і наступных аналагічных графіках па восі X будзе доля запытаў, якія былі абслужыць за час, не якое перавышае адпаведнага значэння па восі Y
На гэтым і наступных аналагічных графіках па восі X будзе доля запытаў, якія былі абслужыць за час, не якое перавышае адпаведнага значэння па восі Y.

Акрамя таго, цікавасці дзеля я запусціў бясплатны тэст Loadimpact, аднак якой-небудзь адчувальнай нагрузкі ён не стварыў.

аптымізацыя PHP

Першае, што трэба зрабіць на сэрвэры пад Drupal, - выставіць у php.ini значэнне memory_limit хаця б 256M. Як правіла, гэтага зусім дастаткова для большасці сайтаў. А вось 128M часам аказваецца замала. Зрэшты, гэта нельга назваць аптымізацыяй, гэта хутчэй жыццёвая неабходнасць.

Для паскарэння працы сайтаў на ўзроўні PHP распрацоўшчыкі рэкамендуюць выкарыстоўваць розныя кеширующие аптымізатары. У іншых крыніцах часцей за ўсё згадваецца APC, таму да яго я і звярнуўся. Пра тое, як яго паставіць, можна пачытаць у інструкцыі . Зараз жа нас цікавяць ключавыя параметры налады. Уласна, асноўнай параметр - памер сегмента памяці кэша, apc.shm_size. Чым больш грузная старонка, чым больш розных файлаў падключаецца пры выкананні, тым больш павінна быць значэнне. Напрыклад, тэставаму сайту хапіла 64M. А тэставы магазін пры гэтым значэнні выдаў памылку:

[Mon Jan 13 21:41:46 2014] [error] [client 176.36.31.190] PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0, referer: http://s2shop.1b1.info/products?page=2

Ўзняцце значэння да 256M ўміг ўбрана гэтую праблему. Па дадзеных модуля Devel, пры разавых праглядах сайтаў ўключэнне кэшавання паўплывала на такія параметры:

  • у паўтара-два разы скарацілася час генерацыі старонкі;
  • скарацілася пікавае спажыванне памяці з прыкладна 50-55 MB да 30-32 MB для тэставага сайта і з прыкладна 65-70 MB да 30-32 MB для тэставага крамы.

Пра тое, як паўплывала ўключэнне APC на вынікі бомбления з дапамогай ab, будзе сказана крыху пазней. Па агульнадаступнай публічнай інфармацыі, выдатныя вынікі дае выкарыстанне php-fpm замест Apache + mod_php. Аднак я пакуль не спрабаваў параўноўваць гэтыя дзве канфігурацыі.

аптымізацыя MySQL

Адзін з самых простых спосабаў аптымізаваць MySQL - замяніць my.cnf на my-huge.cnf. Гэты файл разлічаны на сістэмы з дастатковай (2 Гб і вышэй) колькасцю аператыўкі і маштабным выкарыстаннем MySQL. Акрамя ўсяго іншага, ад стандартнага конфігу ён адрозніваецца істотна вялікім памерам буфера (key_buffer_size) і уключэннем кэшавання запытаў (query_cache_size).

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

Е3-1230, 10 паралельных запытаў
Е3-1230, 10 паралельных запытаў

VPS, 10 паралельных запытаў
VPS, 10 паралельных запытаў

Е3-1230, 30 паралельных запытаў
Е3-1230, 30 паралельных запытаў

VPS, 30 паралельных запытаў
VPS, 30 паралельных запытаў

Як можна заўважыць, на VPS разрыў паміж неоптимизированным MySQL і аптымізаваным прыкметней, чым на E3-1230. Мне здаецца, што гэта звязана з выкарыстаннем SSD дыскаў на VPS. Цяпер усё больш папулярнымі становяцца канфігурацыі сервераў, у якіх базы дадзеных выносяцца на SSD. Улічваючы, наколькі істотна за апошні час яны патаннелі, такое рашэнне не моцна б'е па кішэні і ў многіх выпадках дазваляе прыкметна паскорыць працу сайтаў. Плюсам у карысць SSD, на маю думку, з'яўляюцца і два наступныя графіка.

E3-1230, 50 паралельных запытаў
E3-1230, 50 паралельных запытаў

VPS, 50 паралельных запытаў
VPS, 50 паралельных запытаў

Як бачым, на серверы з SATA дыскамі буферызацыя з кэшаваннем вельмі хутка пачынаюць захлынацца. Пры гэтым на VPS з SSD дыскамі агульная тэндэнцыя захоўваецца. На VPS я паспрабаваў яшчэ павялічыць значэння key_buffer_size і query_cache_size, дзякуючы чаму атрымаў нязначны, але стабільны прырост прадукцыйнасці (крывая MySQL 2). Зрэшты, на гэтым этапе на абедзвюх канфігурацыях ўжо пачынае захлынацца працэсар.

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

тэсты LoadImpact

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

  1. На галоўную старонку тэставага сайта былі нацкаваныя да 100 SBU, прыкладна раўнамерна размеркаваных па 5 розных лакацыях (2 у ЗША, 2 у Еўропе, 1 у Аўстраліі). Сумарны графік не дазваляе ўбачыць, напружыла Ці сервер гэтая нагрузка хоць колькі-небудзь.

    Сумарны графік не дазваляе ўбачыць, напружыла Ці сервер гэтая нагрузка хоць колькі-небудзь

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

    Але ўзрастанне нагрузкі становіцца больш прыкметнымі, калі глядзець графікі асабліва па еўрапейскіх кропках, з якімі звязнасць лепш

    Пры гэтым агульны струмень дадзеных быў блізкі да 90 Мбіт / с. Хацелася дагнаць канал да палічкі, але не засталося крэдытаў.

    Хацелася дагнаць канал да палічкі, але не засталося крэдытаў

    Нагрузка на працэсар становіцца прыкметнай, аднак Load average не ідзе ні ў якое параўнанне з тэстамі ab.

    Нагрузка на працэсар становіцца прыкметнай, аднак Load average не ідзе ні ў якое параўнанне з тэстамі ab

  2. У заключэнне я склонировал звычайны невялікі інфармацыйны СДЛ і нацкаваў на яго Loadimpact з 8 розных пунктаў. Усе кропкі тэставання звярталіся да розных старонках сайта. За 10 хвілін колькасць SBU таксама дайшло да 100.

    За 10 хвілін колькасць SBU таксама дайшло да 100

    Аддача была вельмі раўнамернай, без якіх-небудзь відавочных запаволенняў.

    Аддача была вельмі раўнамернай, без якіх-небудзь відавочных запаволенняў

    Пры гэтым сервер гэтага тэсту практычна не заўважыў.

    Пры гэтым сервер гэтага тэсту практычна не заўважыў

замест заключэння

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

Як колькасна змяняецца хуткасць генерацыі старонкі?
Як змяняецца выкарыстанне памяці?
Што адбываецца пры павелічэнні колькасці паралельных запытаў?
1.info/products?