Аптымізацыя сервера пад Drupal з замерам вынікаў
- замест прадмовы
- эксперыментальная мадэль
- эксперыментальнае абсталяванне
- Дадзеныя «сырога» сервера
- аптымізацыя PHP
- аптымізацыя MySQL
- тэсты LoadImpact
- замест заключэння
Сама па сабе інструкцыя аб тым, дзе што падкруціць на сэрвэры, каб 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.
Акрамя таго, цікавасці дзеля я запусціў бясплатны тэст 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 паралельных запытаў
VPS, 10 паралельных запытаў
Е3-1230, 30 паралельных запытаў
VPS, 30 паралельных запытаў
Як можна заўважыць, на VPS разрыў паміж неоптимизированным MySQL і аптымізаваным прыкметней, чым на E3-1230. Мне здаецца, што гэта звязана з выкарыстаннем SSD дыскаў на VPS. Цяпер усё больш папулярнымі становяцца канфігурацыі сервераў, у якіх базы дадзеных выносяцца на SSD. Улічваючы, наколькі істотна за апошні час яны патаннелі, такое рашэнне не моцна б'е па кішэні і ў многіх выпадках дазваляе прыкметна паскорыць працу сайтаў. Плюсам у карысць SSD, на маю думку, з'яўляюцца і два наступныя графіка.
E3-1230, 50 паралельных запытаў
VPS, 50 паралельных запытаў
Як бачым, на серверы з SATA дыскамі буферызацыя з кэшаваннем вельмі хутка пачынаюць захлынацца. Пры гэтым на VPS з SSD дыскамі агульная тэндэнцыя захоўваецца. На VPS я паспрабаваў яшчэ павялічыць значэння key_buffer_size і query_cache_size, дзякуючы чаму атрымаў нязначны, але стабільны прырост прадукцыйнасці (крывая MySQL 2). Зрэшты, на гэтым этапе на абедзвюх канфігурацыях ўжо пачынае захлынацца працэсар.
тэсты LoadImpact
Праведзеныя з дапамогай утыліты ab тэсты паказваюць ня рэальную загрузку старонак сайта, а хутчэй якаснае змяненне прадукцыйнасці. Для нейкіх больш набліжаных да жыцця дадзеных я правёў пару тэстаў з дапамогай Loadimpact .
- На галоўную старонку тэставага сайта былі нацкаваныя да 100 SBU, прыкладна раўнамерна размеркаваных па 5 розных лакацыях (2 у ЗША, 2 у Еўропе, 1 у Аўстраліі). Сумарны графік не дазваляе ўбачыць, напружыла Ці сервер гэтая нагрузка хоць колькі-небудзь.
Але ўзрастанне нагрузкі становіцца больш прыкметнымі, калі глядзець графікі асабліва па еўрапейскіх кропках, з якімі звязнасць лепш.
Пры гэтым агульны струмень дадзеных быў блізкі да 90 Мбіт / с. Хацелася дагнаць канал да палічкі, але не засталося крэдытаў.
Нагрузка на працэсар становіцца прыкметнай, аднак Load average не ідзе ні ў якое параўнанне з тэстамі ab.
- У заключэнне я склонировал звычайны невялікі інфармацыйны СДЛ і нацкаваў на яго Loadimpact з 8 розных пунктаў. Усе кропкі тэставання звярталіся да розных старонках сайта. За 10 хвілін колькасць SBU таксама дайшло да 100.
Аддача была вельмі раўнамернай, без якіх-небудзь відавочных запаволенняў.
Пры гэтым сервер гэтага тэсту практычна не заўважыў.
замест заключэння
Я разгледзеў ўплыў на хуткасць працы сайта ўсяго двух істотных параметраў, таму буду ўдзячны ўсім, хто зможа даць дадатковыя карысныя парады па закранутай тэме. Акрамя таго, дзе-то дзён 5 пасля публікацыі тэставыя асяроддзя яшчэ будуць заставацца жывыя, і калі ў Вас ёсць яшчэ нейкія рэкамендацыі па аптымізацыі ці прапановы па тэставанні, я паспрабую за гэты перыяд ўвасобіць іх у жыццё і дадаць у артыкул. Заклікаю ўсіх абменьвацца уласным вопытам аптымізацыі і сваімі хітрасцямі. І дзякуй, што цярпліва дачыталі.
Як колькасна змяняецца хуткасць генерацыі старонкі?Як змяняецца выкарыстанне памяці?
Што адбываецца пры павелічэнні колькасці паралельных запытаў?
1.info/products?