Праблемы прадукцыйнасці сайтаў на «1С-Битрикс»

Генеральны дырэктар ITSumma

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

З 2015 года мы выконваем афіцыйную паслугу «1С-Битрикс» - аўдыт прадукцыйнасці сайтаў . У рамках аўдыту мы не проста аналізуем наладу і канфігурацыю сервера, але таксама праглядаем код: пераносім праект да сябе на стэнд, дзе вывучаем што менавіта можна змяніць у кодзе і канфігурацыі кампанентаў так, каб сайт працаваў хутчэй.

Аднак спачатку давайце пагаворым пра тое, ад чаго наогул залежыць хуткасць загрузкі старонак і прадукцыйнасць сайта. Існуе, на наш погляд, памылковае меркаванне, што ўсе праблемы хуткасці загрузкі сайта можна вырашыць аптымізацыяй налад або зменай хостынгу. Гэта сапраўды дапамагае ў выпадку некалькіх класічных памылак налады, якія мы разгледзім ніжэй, аднак, асноўныя праблемы часцей за ўсё хаваюцца ў неаптымальнай алгарытмах, наладах «1С-Битрикс», праблемах з кэшаваннем.

Тлумачыцца гэта даволі проста: сучасныя працэсарныя тэхналогіі дасягнулі піка частоты аднаго ядра. Што гэта азначае для нас? Ва ўмовах, калі адзін запыт выконваецца на адным ядры працэсара - няма практычна ніякіх магчымасцяў паскорыць час выканання запыту ў два разы. Хутчэй за ўсё, у працэсара на вашым серверы ўжо высокая частата і са зменай сервера яна не стане ў два разы вышэй. Серверы на хостынгавых пляцоўках часцей адрозніваюцца колькасцю аператыўнай памяці і колькасцю ядраў / працэсараў, на іх размешчаных.

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

Такім чынам, пісьменны аналіз прадукцыйнасці праекта ўключае ў сябе:

• аналіз карэктнай налады сервера, аўдыт сервернай канфігурацыі і магутнасцяў (раптам усё-такі «касір» вельмі павольна працуе сам па сабе - тады любы працэдура будзе здавацца нам павольнай, і мы не зможам зразумець што ж менавіта аптымізаваць);
• алгарытмічная аналіз праекта, прафіляванне часу загрузкі старонак, аналіз працы гэтых старонак як з кэшаваннем так і без яго (аналіз аптымальнасці працэдуры куплі на сайце);
• аналіз хуткасці загрузкі сайта ў браўзэры, аптымальнасці фронтенда.

Разгледзім гэтыя пункты ў падрабязнасцях.

Аўдыт сервернай канфігурацыі

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

1. Размешчаны Ці сайт на віртуальным хостынгу, VPS / VDS, віртуальнай машыне?

На жаль, практычна ва ўсіх выпадках віртуальны хостынг так ці інакш прадае кліенту больш апаратных магутнасцяў, што мае на самай справе фізічна. Следствам гэтага можа быць недахоп дыскавай падсістэмы ў пікавыя гадзіны, можа быць недахоп працэсарнага часу. Акрамя некалькіх сітуацый мы рэкамендуем выкарыстанне вылучанага сервера на сапраўднай апаратнай базе для e-commerce праекта, які прыносіць грошы. Так, розніца кошту паміж віртуальным і «сапраўдным» выдзеленым серверам можа складаць дзесяткі разоў. Аднак гэтая эканомія не варта таго патэнцыйнага шкоды (як фінансавага, так і рэпутацыйнага), які можа быць нанесены ў выпадку аварыі на хостынгу.

2. Якія версіі ПА устаноўлены на сэрвэры?

PHP малодшай версіі 5.5 і MySQL версіі малодшай 5.5 мы рэкамендуем да апгрэйду. Важна: у выпадку калі праблемы праекта перш за ўсё звязаны з кодам - ​​апгрэйд PHP не прывядзе да паскарэнню сайта. Але калі код аптымальны і падтрымлівае такі пераход - выкарыстанне PHP версіі 5.5 і вышэй можа прывесці да паскарэння часу генерацыі старонкі на 20-30%, а выкарыстанне PHP7 (у выпадку калі праект PHP7-сумяшчальны) - да двухразовага росту прадукцыйнасці на ўзроўні PHP. Варта памятаць, калі ваша старонка генеруецца за 1000мс, з якіх 800мс займаюць неаптымальныя запыты да БД - нават двухразовае паскарэнне PHP7 прывядзе да паскарэння толькі на 100мс (час адказу стане 900мс замест 1000мс). Час працы з базай дадзеных ад змены версіі PHP не зменіцца.

3. Ці варта аптымізатар PHP-кода?

У сапраўдны момант стандартам індустрыі і рэкамендаваным аптымізатарам PHP з'яўляецца opcache. Акрамя зусім унікальных выпадкаў выкарыстанне opcache з'яўляецца абавязковым. Прекомпиляция PHP-кода, якую ажыццяўляе PHP-аптымізатар, паскарае час апрацоўкі PHP-скрыпту на 80-90%. Аптымізатар PHP займаецца трансляцыяй PHP-кода ў байт-код, які значна бліжэй да машыннай. Пры выкарыстанні аптымізатар гэтая трансляцыя становіцца разавай працэдурай, а пры яго адсутнасці PHP выконвае трансляцыю пры кожным карыстацкім запыце.

4. Адключаны Ці адладчык XDebug?

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

5. Праверка engine табліц у MySQL

Нягледзячы на ​​тое, што ў 2016 годзе MyISAM лічыцца састарэлым «рухавічком» табліц, мы сустракаем яго выкарыстанне на баявых сайтах. Магчыма, прычына ў пераносе табліц з выкарыстанай пры распрацоўцы базы дадзеных, дзе тып рухавічка не моцна крытычны. Магчыма на гэта проста не звярнулі ўвагу, а магчыма гэты тып табліц выкарыстоўвалі з гістарычна якія склаліся прадузятасцяў. У любым выпадку для тыпавых задач варта выкарыстоўваць InnoDB і яго вытворныя. MyISAM па сваёй структуры мала чым адрозніваецца ад вядомага ўсім старога фармату dbf-файлаў, не прызначанага для прамысловага выкарыстання ў шматкарыстальніцкай асяроддзі. MyISAM часта схільны блакаванням на ўзроўні табліцы (калі адзін запыт сайта заблакуе ўсе астатнія запыты), вельмі адчувальны да падзенням MySQL (аварыйны падзенне можа прывесці да крытычнай страты дадзеных), з цяжкасцю паддаецца рэзервоваму капіяванню на лета (рэзервовае капіраванне вялікі табліцы прывядзе да блакавання сайта ). Ўсіх гэтых праблем у InnoDB няма, аднак, ён павінен быць карэктна наладжаны.

6. Карэктнасць налады InnoDB

Перш за ўсё размова ідзе аб памеры buffer pool - ўнутраным кэшы MySQL. У выпадку, калі аператыўнай памяці дастаткова, а памер дадзеных невялікі, мы рэкамендуем выставіць buffer pool вышэй, чым памер дырэкторыі з дадзенымі (такім чынам кэшаваць ўсе дадзеныя). Пры аўдыце добра дапамагаюць інструменты Percona Tools - у нашым блогу ёсць аглядная артыкул . Тэма цюнінгу MySQL даволі аб'ёмная, больш падрабязна пра яе пагаворым у адной з бліжэйшых артыкулаў.

7. Маніторынг працы сервера, праверка выкарыстання swap-а

Ніводная аптымізацыя не дапаможа, калі сервер ляжыць пад велізарнай нагрузкай з-за наплыву наведвальнікаў, або працэсам не хапае памяці і частка іх выгружаная ў swap. Swap-файл працуе з жорсткага дыска, які ў любым выпадку ў сотні разоў больш павольна аператыўнай памяці. Мала таго, звычайна працэсы настолькі актыўна выкарыстоўваюць аператыўную памяць, што ў выпадку выгрузкі яе на дыск - дыскавая падсістэма сервера неадкладна дасягае сваёй мяжы і сайт перастае адказваць. На сэрвэры павінен стаяць маніторынг: у момант «тармазоў» важна разумець, што стала іх прычынай - моцнае выкарыстанне дыскавай падсістэмы, недахоп сервернага CPU, а можа быць наогул вычарпанне прапускной здольнасці сеткавага інтэрфейсу?

Аўдыт кода праекта

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

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

Для першапачатковага аналізу доўгіх месцаў сайта мы выкарыстоўваем манітор прадукцыйнасці 1С-Битрикс. Знаходзім самыя наведвальныя з доўга адказваюць старонак - іх паскарэнне прывядзе да адчувальнага зніжэння нагрузкі на сервер. Калі не ўлічваць папулярнасць старонкі, а звяртаць увагу толькі на хуткасць адказу, то можна выдаткаваць час на аптымізацыю старонкі, якую запытваюць раз у месяц і якая не стварае рэальнай нагрузкі.

Манітор прадукцыйнасці ўключаецца наступным чынам: у адміністрацыйнай панэлі сайта выбіраем у меню «Настройкі» -> Панэль прадукцыйнасці -> Кнопка «Тэставаць прадукцыйнасць». Па заканчэнні збору дадзеных ва ўкладцы «Распрацоўка» будзе табліца з усімі наведванняў старонак і часам іх генерацыі.

Пасля таго як мы абралі доўгія старонкі на асобным сэрвэры (мы ведаем магутнасці гэтага сервера, і мы ведаем, што сервер не загружаны) аналізуем час стварэння гэтых старонак у рэжыме выпраўленьня, глядзім на час генерацыі асобных кампанентаў і разумеем, на што менавіта варта звярнуць увагу у аналізе кода гэтых старонак. У першых ітэрацыі мы правяраем як працуюць старонкі ў рэжыме з выкарыстаннем кэшавання, а ў апошніх - вывучаем працу сайта без кэша. Нярэдка старонкі, якія адкрываюцца даволі хутка з выкарыстаннем кэша, без яго пачынаюць адкрывацца за 30-60 секунд. Здавалася б, сітуацыя калі кэш скончыўся на рэдка наведвальных старонках не страшная, аднак, які прыйшоў у каталог пошукавы бот можа сур'ёзна нагрузіць сервер, пачаўшы абыходзіць такія старонкі.

Рэжым адладкі ўключаецца непасрэдна на старонцы сайта: у панэлі адміністратара неабходна знайсці пункт «Адладка» і ў выпадальным меню абраць пункт «Сумарная статыстыка». Калі неабходна праверыць працу кэша, то дадаткова адзначце галачкай пункт «Дэталёвая статыстыка кэша».

У некаторых выпадках гэтай інфармацыі не хапае - калі некаторыя часткі кода не трапляюць у рэжым адладкі ці калі хочацца дэталёва вывучыць структуру ўкладзенасці выклікаў PHP. У такіх выпадках мы падлучальны модуль прафілявання XHProf, які дазваляе адсачыць час выканання як усяго PHP скрыпту, так і ўкладзеных функцый.

Разгледзім выкарыстанне рэжыму адладкі і ўтыліты XHProf на прыкладзе старонкі каталога з часткамі. Праблема: пры ўключаным кэшаванні кампанент Bitrix: catalog.section павольна выконваецца.

Крок 1. Звяртаем увагу, што кампанент ня кэшуецца і выконваецца вельмі павольна. Пры гэтым выкананне запытаў займае прыблізна 16% ад часу выканання кампанента. Відавочна, што прысутнічаюць нейкія праблемы ў рэалізацыі кампанента.

Крок 2. Для адладкі PHP выкарыстоўваем XHProf. Абгортваюцца патрэбны нам кампанент у код ўтыліты XHProf.

Крок 3. Які абнаўляецца старонку, каб XHProf сабраў патрэбныя нам дадзеныя.

Крок 4. Адчыняны старонку з дадзенымі XHProf.

Крок 5. Знаходзім падлучэнне патрэбнага нам кампанента Bitrix: catalog.section. Адкрываем і бачым наступнае:

Выкананне шаблону кампанента Bitrix: catalog.section займае 1,5 секунды, гэта вялікая частка часу генерацыі ўсёй старонкі.

Крок 6. Ідзем далей па стэку выклікаў і знаходзім выклік скрыпту result_modifier.php. Калі прайсці далей, то можна ўбачыць карыстацкую функцыю, у якой выконваюцца запыты:

Уласна, гэтая надбудова ў выглядзе result_modifier.php з'яўляецца прычынай павольнай генерацыі. Такім чынам, выправіўшы праблему кода ў дадзенай надбудове, можна вырашыць праблему з павольнай загрузкай старонкі з часткамі каталога.

Давайце зараз пройдземся па самым частым праблемах, якія мы сустракаем у выніку аўдыту канфігурацыі 1С-Битрикса.

Аўдыт канфігурацыі «1С-Битрикс»

Няправільная структурная арганізацыя инфоблоков

Мабыць, гэта найбольш распаўсюджаная праблема - сустракаецца ў 90% праектах. Калі ўсе тавары «складаюць» у адзін инфоблок. У такога инфоблока назапашваецца вялікая колькасць уласцівасцяў ўсіх тавараў, гэта багата вялікімі выбаркамі і павольным імпартам. Разгледзім на прыкладзе абстрактнага спартыўнага крамы, у якога ў асартыменце адзенне, лыжы, ровары (і ў кожнага віду тавараў свае ўласцівасці). Ўласцівасці тавараў трапляюць у адзін инфоблок, ровары атрымліваюць ўласцівасці лыж і адзення (і, адпаведна, наадварот - дадзеныя віды тавараў атрымліваюць ўласцівасці ровараў). Уявіце, колькі «залішніх» уласцівасцяў назапашваецца, калі катэгорый тавараў у крамы шмат.

Пры гэтым аднойчы мы сутыкнуліся з процілеглага праблемай: у праекта была правільная структура инфоблоков, але таксама было шмат агрэгуе выбарак (навінкі, акцыі, хіты). Атрымалася, што замест аднаго запыту ў «доўгую» инфоблок для генерацыі выбаркі адпраўлялася па запыце ў 50+ хуткіх инфоблоков і затым яшчэ адбывалася іх сумяшчэнне ў кодзе. З-за гэтага кампанент у цэлым стаў працаваць больш павольна. Так што калі праекту неабходна такая функцыянальнасць, то трэба распрацоўваць запасны план - ствараць асобную табліцу ў базе дадзеных (рабіць «денормализацию» структуры инфоблоков), альбо праз знешнюю агрэгацыю, альбо нешта яшчэ.

«Самописные кампаненты»

Часта сустракаюцца сітуацыі, калі праграмісты і вэб-студыі выкарыстоўваюць іншыя, «аўтарскія» кампаненты, якія пры гэтым не выкарыстоўваюць існуючыя магчымасці платформы 1С-Битрикс. Напрыклад, самописные «разумныя фільтры» не выкарыстоўваюць фасетные індэксы - гэта значна павялічвае час выканання кампанента. Здараецца, што праграмісты не вывучаюць дэталёва які ўсталёўваецца кампанент і выпускаюць з выгляду памылкі і праблемы, якія ён дадае. Рэкамендуем старанна аналізаваць усталёўваныя кампаненты.

Праблемы з вонкавымі сэрвісамі

Гэта не звязана з самім кодам 1С-Битрикс, але сустракаецца ў многіх кліентаў. Так ці інакш многія сайты выкарыстоўваюць знешнія сэрвісы для дадатковай функцыянальнасці на сайце: абнаўленне курсу валюты, разлік часу і кошту дастаўкі тавару, API партнёраў і да т.п. Калі такі знешні сэрвіс пачынае доўга адказваць - пачынае доўга адказваць і сам сайт. На жаль, многія знешнія сэрвісы заўсёды адказваюць доўга. Магчымае рашэнне праблемы - перыядычная загрузка дадзеных па заданні праз Cron, і лепш калі гэта будзе адбывацца ў найменш загружанае час працы праекту.

Праблемы з фасетными індэксамі

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

Памылкі выкарыстання API 1С-Битрикс

Выбарка уласцівасцяў у цыкле пасвіліся GetList, калі ІХ можна абраць у GetList. Сартаванне І фільтраванне сродкамі PHP намеснік д выкарыстання arFilter І arSort. У API 1С-Битрикс існуе Вялікая колькасць тэнзараў, аптыміза для нагрузкі на сервер. Распрацоўніку неабходна ведаць гэтыя функцыі І ўмець ІХ ужываць. Рэгулярнай памылкай з'яўляецца, напрыклад, атрыманне спісу тавараў І наступнае атрыманне ІХ уласцівасцяў Ў цыкле, у той час, калі ўласцівасці можна атрымаць у асноўным запыце. Такім чынам, напрыклад, атрымаўшы 100 тавараў, мы ствараем дадаткова 100 запытаў ды базе даных для атрымання уласцівасцяў. Не варта таксама выбіраць таварах для ІХ падліку - у API 1С-Битрикс ёсць для гэтага спецыяльная функцыянальнасць. Дзіўна, але вельмі часта мы бачым як тавары выбіраюцца для таго, каб палічыць частка з іх па нейкім ўласцівасці.

Праблемы пры генерацыі меню

У вялікіх праектах становіцца праблемай генерацыя меню (альбо секцый каталога) з падлікам колькасці элементаў у катэгорыях / секцыях. Зыходзячы з гэтай колькасці элементаў як раз і будуюцца вышэйпаказаныя вобласці. Для аптымізацыі хуткасці працы праекта мы не рэкамендуемы выкарыстаць дадзеную функцыю. Падрабязны кейс быў падрабязна разгледжаны у супольнасці распрацоўнікаў Битрикс .

Яшчэ даволі часта назіраем праблемы з дапрацаванымі меню. Да прыкладу, распрацоўшчыкі не звярнулі ўвагу, што меню не кэшуецца выснову пра шаблон і напісалі меню з уключэннем у яго самога папулярнага тавару па кожнай катэгорыі. Атрымалася, што пры праглядзе карыстальнікам меню на кожны элемент ствараюцца запыты да базы (што, натуральна, запавольвае працу праекта). Сам 1С-Битрикс рэалізуе дадзеную "кастомную» функцыянальнасць праз уключэнне кампанентаў з такімі элементамі ў result_modifier.php.

уключаны антывірус

Вэб-антывірус займаецца праверкай старонак сайта на шкоднасны кантэнт, які мог быць дададзены ў выніку ўзлому / мадыфікацыі старонак. Хоць гэтая функцыянальнасць і карысная, мы, звычайна, рэкамендуем адключаць гэты модуль, пакінуўшы уключаным модуль проактивной абароны - адключэнне вэб-антывіруса можа паскорыць загрузку старонкі на 100-200 мс.

Прыклад загрузкі старонкі з уключаным антывірусам:

І тая ж старонка з выключаным антывірусам:

Усталяваны модуль кампрэсіі

Модуль кампрэсіі прызначаны для хостынгавых пляцовак, у якіх ўключыць кампрэсію на ўзроўні вэб-сервера не ўяўляецца магчымым - у асноўным на «старажытных» shared-хостынгах. У выпадку, калі gzip-кампрэсію на ўзроўні вэб-сервера вы ўключыць можаце (а ў большасці выпадкаў гэта магчыма) - мы рэкамендуем адключыць гэты модуль.

Агенты выконваюцца на хітах

Яшчэ адна гістарычная функцыянальнасць, якая вельмі часта сустракаецца на праектах кліентаў. «Агенты» - рэгулярна выконваюцца заданні ў 1С-Битрикс, могуць выконвацца альбо праз традыцыйны для нас cron, альбо ўнутры кода, выкліканага карыстацкім запытам - гэты рэжым называецца «Агенты на хітах». У такім рэжыме 1С-Битрикс кожны запыт карыстальніка правярае не прыйшло Ці час выканаць рэгулярную працэдуру (напрыклад рассылку), і калі час спрацавала - пачынае выконваць гэтую задачу. Праблема заключаецца ў тым, што ўвесь час выканання задачы карыстальнік не будзе атрымліваць вынік старонкі, а калі ў наладах вэб-сервера Вы абмежаваныя ў час выканання скрыпту - такі агент ніколі не будзе выкананы і пошта не сыдзе. «Агенты на хітах» створаны для тых пляцовак, дзе вы не можаце паставіць рэгулярнае выкананне агентаў на cron, цяпер такіх хостынгавых пляцовак засталося вельмі мала і мы рэкамендуем ўсім адмовіцца ад выканання агентаў на хітах. Больш падрабязна аб пераключэнні агентаў на крон можна прачытаць у артыкуле Мікалая Рыжонина І у запісе Антона Долганина . Дарэчы, пры ўключэнні стэнда, на якім мы правяраем код праекта, абавязкова першым крокам правяраем у MySQL ці ўключаны агенты на хітах (і не апынецца Ці так, што ў момант калі мы зойдзем на сайт, мы выканаем якое-небудзь рэгулярнае заданне).

Некарэктнае выкарыстанне кэшавання

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

З іншага боку, у шэрагу самописных кампанентаў мы сустракалі выпадкі, калі ў кэш загружалася занадта вялікая выбарка дадзеных. Ўнутры кэша 1С-Битрикс знаходзіцца сериализованный масіў, і калі памер адной сутнасці, якая ляжыць у кэшы, становіцца больш некалькіх сотняў кілабайт (ды і гэтага шмат), накладныя выдаткі на выгрузку дадзеных з кэша станавіліся мацней, чым эканомія звароту ў базу даных.

Праблемы з кампазітным кэшам

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

Яшчэ нярэдка ў выніку распрацоўкі дадаецца новы невялікі кампанент, ня які падтрымлівае кампазіт, з-за чаго кампазіт са старонак «злётае». Трэба сачыць за тым, каб ён захоўваўся.

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

Праверка кліенцкай часткі

Выявы без аптымізацыі

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

Праблемы з JS / CSS файламі

Тут рэгулярна сустракаюцца дзве праблемы: гэта падключэнне JS / CSS файлаў нестандартным для Битрикса спосабам і выкарыстанне необъединённых JS / CSS файлаў. Пост у супольнасці распрацоўнікаў на гэтую тэму .

Самае важнае - няправільнае падключэнне адмяняе магчымасць аўтаматычнага аб'яднання JS / CSS файлаў, і таксама адмяняе аўтаматычнае забеспячэнне правільнага парадку іх падгрузкі (спачатку CSS файлы, потым JS-файлы).

Некалькі разоў сустракалася праблема з лішкам JS - літаральна на кожны элемент каталога Наважваюць падзея асобным скрыптам. Пры ўключэнні опцыі «пераносіць JS ў канец старонкі» ўзнікала магутная нагрузка на сервер.

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

Аддача статыкі вэб-серверам Apache

Як ні дзіўна, але да гэтага часу мы даволі часта сустракаем сітуацыі, калі легковесные статычныя файлы аддаюцца ня праз фронтенд ў выглядзе nginx або яму падобны лёгкі вэб-сервер, а праз Apache, з якога часта (асабліва пры выкарыстанні Bitrix Env) раздаецца дынаміка . Пры гэтым кожны такі запыт стварае дадатковае спажыванне аператыўнай памяці (Apache значна цяжэй) і нагрузку на працэсар. Мы настойліва раім пераканацца, што аддачай статыкі займаецца nginx.

Адсутнасць кампрэсіі на ўзроўні вэб-сервера

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

падводзім вынікі

Значнасць хуткасці загрузкі сайтаў расце: пашукавікі рыхтуюць штрафы ў пазіцыях выдачы для павольных сайтаў, карыстальнікі караюць «рублём» і сыходзяць да больш шустрым канкурэнтам. Мы хочам, каб добрых і хуткіх сайтаў было як мага больш. Выкарыстоўвайце рэсурсы хостынгу і платформы 1С-Битрикс пісьменна, каб атрымаць якасны ва ўсіх адносінах праект, які не сорамна размясціць у партфоліо. Спадзяемся, нашы рэкамендацыі дапамогуць вам у вырашэнні праблем прадукцыйнасці праекта. І не забудзьцеся падзяліцца артыкулам у соцсетях, калі для вас яна апынулася карыснай.