Magentная аномалия. Настраиваем ngnix для работы с Magento - «Новости»

Вкратце о сервере

Итак, име­ем самый обыч­ный VDS с 39 Гбайт опе­ратив­ки, 12 ядра­ми и «Убун­той» на бор­ту. PHP 7.2, PHP-FPM, MySQL 5.7. Вер­сии ПО, может, нем­ного и древ­ние, но уста­нов­лены нес­прос­та: такая кон­фигура­ция обус­ловле­на тре­бова­ниями CMS Magento 2.3.4. Более новая вер­сия PHP пов­лекла бы за собой обновле­ние вер­сии CMS, а это­го по ряду при­чин делать было нель­зя.

Как обыч­но, все прек­расно работа­ло до одно­го момен­та: пока не начались тра­дици­онные новогод­ние рас­про­дажи и мар­кетоло­ги не при­тащи­ли на сайт кучу тра­фика. Вот тут и начались проб­лемы. Наибо­лее харак­терная из них — про­цесс php-fpm в паре с MySQL выжирал всю опе­ратив­ку. Переза­пуск сер­висов с добав­лени­ем 20 Гбайт сво­па проб­лему решил ненадол­го. Даль­ше пошел про­цесс нас­трой­ки nginx и php-fpm, преж­де все­го — пос­ледне­го, пос­коль­ку имен­но его парамет­ры вли­яют на экс­плу­ата­цион­ные осо­бен­ности CMS. Я не буду рас­смат­ривать уста­нов­ку и нас­трой­ку nginx с самого начала — ско­рее все­го, у тебя уже все нас­тро­ено. Даже если это не так, в сети мож­но най­ти мно­жес­тво ста­тей и руководств на эту тему. Скон­цен­три­руем­ся луч­ше на парамет­рах, непос­редс­твен­но вли­яющих на про­изво­дитель­ность сер­вера.

Конфигурационные файлы

Преж­де чем прис­тупить к даль­нейше­му чте­нию статьи, нуж­но понимать, что и где и редак­тировать. Кон­фигура­ция nginx хра­нит­ся в катало­ге /etc/nginx. Основной кон­фиг — nginx.conf, но вре­мена одно­го боль­шого фай­ла уже дав­но прош­ли, и в зависи­мос­ти от содер­жимого nginx.conf кон­фигура­ция веб‑сер­вера может быть раз­бро­сана по всей фай­ловой сис­теме.

Как пра­вило, кон­фиги сай­тов хра­нят­ся в катало­ге /etc/nginx/conf.d. Для каж­дого сай­та при­нято соз­давать отдель­ный кон­фиг. Далее нуж­но про­ана­лизи­ровать содер­жимое фай­лов кон­фигура­ции на пред­мет дирек­тивы Include. Если пер­воначаль­ную нас­трой­ку выпол­нял не ты, поищи во всех фай­лах катало­га nginx фай­лы с дирек­тивой Include — так ты пой­мешь, что и отку­да берет­ся. Нап­ример, в моем слу­чае кто‑то до меня добавил дирек­тиву include /var/www/www/nginx.conf, что­бы некото­рые парамет­ры мож­но было вынес­ти в каталог докумен­тов веб‑сер­вера и редак­тировать их без редак­тирова­ния основной кон­фигура­ции сер­вера. Что‑то вро­де .htaccess в «Апа­че», вот толь­ко пос­ле изме­нения это­го фай­ла все рав­но при­дет­ся делать reload сер­вису.

Да­лее перей­дем к парамет­рам PHP. У него есть нес­коль­ко кон­фигура­ций. Преж­де все­го вве­ди коман­ду php –v, что­бы выяс­нить номер вер­сии. Так вот, кон­фигура­ция тво­ей вер­сии PHP хра­нит­ся в катало­ге /etc/php/<номер версии>. В этом катало­ге ты най­дешь четыре под­катало­га. Да, это три раз­ные кон­фигура­ции и спи­сок модулей:

• apache2 — кон­фиг для модуля mod_rewrite «Апа­ча». Если у тебя «Апач», то нас­трой­ки PHP хра­нят­ся здесь;
  


• cli — парамет­ры кон­соль­ной вер­сии PHP, они всту­пают в силу, если ты запус­каешь выпол­нение скрип­та с кон­соли коман­дой php <имя_скрипта>;
  


• fpm — наш слу­чай, а имен­но кон­фигура­ция сер­виса php-fpm и самого PHP, работа­юще­го в связ­ке nginx, PHP-FPM и PHP;
  


• mods-available — дос­тупные рас­ширения PHP. Здесь хра­нят­ся .ini-фай­лы, по одно­му для каж­дого уста­нов­ленно­го рас­ширения. Заком­менти­ровав строч­ку extension внут­ри это­го фай­ла, ты можешь вык­лючить рас­ширение.
  

Что­бы узнать, какой имен­но файл кон­фигура­ции PHP исполь­зует­ся, помес­ти в корень сер­вера PHP-скрипт, вызыва­ющий php_info(). Эта фун­кция и покажет (кро­ме все­го про­чего) локацию и имя фай­ла кон­фигура­ции.

Включение HTTP 2.0

Ес­ли не счи­тать ста­тичес­кого кеша, то самое кру­тое, что ты можешь сде­лать в нас­трой­ках nginx, — это вклю­чить HTTP 2.0. Некото­рые адми­ны почему‑то забыва­ют об этом. В моем слу­чае так и было: я уже получил пред­нас­тро­енный под­рядчи­ком сер­вер, в котором почему‑то забыли вклю­чить вер­сию 2.0 про­токо­ла HTTP. Думаю, не нуж­но говорить о том, как мед­ленно работа­ла Magento.

Боль­ше дела, мень­ше слов: открой кон­фигура­цию сай­та в катало­ге /etc/nginx/conf.d/<имя_сайта>.conf. Най­ди блок server и добавь (если это­го еще не сде­лано) http2 в дирек­тиву listen. Дол­жно получить­ся так:

Но­мер пор­та и SSL уста­нови по сво­ему усмотре­нию, но пос­коль­ку при­мер реаль­ный, то SSL уже есть на тво­ем сай­те, так как это стан­дарт по умол­чанию.

OPcache: быть или не быть?

OPcache исполь­зует­ся для кеширо­вания ском­пилиро­ван­ного байт‑кода PHP-скрип­тов в опе­ратив­ной памяти. С одной сто­роны, при исполь­зовании OPcache повысит­ся про­изво­дитель­ность и сни­зит­ся наг­рузка на сер­вер — PHP уже не будет соз­давать байт‑код при выпол­нении скрип­та, а ста­нет исполь­зовать откомпи­лиро­ван­ную вер­сию из кеша. С дру­гой сто­роны, в про­цес­се исполь­зования слож­ных CMS вро­де Magento могут воз­никнуть проб­лемы. При уста­нов­ке рас­ширения это­го движ­ка про­исхо­дит так называ­емая переком­пиляция Magento. Луч­ше эту про­цеду­ру про­изво­дить при вык­лючен­ном кеше, а затем сно­ва его вклю­чить.

Для это­го редак­тиру­ется кон­фиг, перезаг­ружа­ется сер­вис php-fpm, про­изво­дят­ся необ­ходимые дей­ствия, а потом сно­ва все пов­торя­ется — редак­тирова­ние кон­фига и переза­пуск сер­виса. Так­же воз­никнут проб­лемы при исполь­зовании собс­твен­ной сис­темы кеширо­вания Magento. Здесь поможет исполь­зование Varnish. В общем, резюми­ровать мож­но сле­дующее: если ты решишь вклю­чить OPcache, то в слу­чае с Magento тебе при­дет­ся отка­зать­ся от исполь­зования собс­твен­ной сис­темы кеширо­вания и раз­бирать­ся с нас­трой­ками Varnish. Уста­нов­ка рас­ширений дос­тавля­ет мень­ше неудобств, пос­коль­ку выпол­няет­ся не так час­то.

Для вклю­чения OPcache нуж­но открыть кон­фигура­цию PHP, в нашем слу­чае это /etc/php/7.2/fpm/php.ini, и добавить в него все­го одну строч­ку:

Этим ты акти­виру­ешь opcache с нас­трой­ками по умол­чанию. Как минимум мож­но задать параметр opcache.memory_consumption, который регули­рует раз­мер памяти (в мегабай­тах), выделя­емый для OPcache. Зна­чение по умол­чанию — 128, минималь­но допус­тимое зна­чение — 8:

С осталь­ными нас­трой­ками OPcache мож­но озна­комить­ся здесь. На сво­ем сер­вере я отклю­чил OPcache по двум при­чинам. Во‑пер­вых, сайт активно допили­вает­ся, из‑за чего очень час­то при­ходит­ся добав­лять в него новые фун­кции или изме­нять уже име­ющиеся, что при вклю­чен­ном OPcache не сов­сем удоб­но. Во‑вто­рых, пока нет никако­го желания уста­нав­ливать Varnish, хотя в ско­ром вре­мени это при­дет­ся сде­лать. На дан­ный момент исполь­зует­ся штат­ная сис­тема кеширо­вания.

Запрещаем доступ ботов

Бо­ты во вре­мя сво­его обхо­да сай­та рас­ходу­ют дра­гоцен­ные ресур­сы. При неб­лагоп­рият­ном сте­чении обсто­ятель­ств (нап­ример, слу­чай­ные или намерен­ные визиты нес­коль­ких ботов сра­зу) сайт может упасть, не выдер­жав наг­рузки. Каж­дый GET-зап­рос стра­ницы тянет за собой исполь­зование ресур­сов сер­вера: заг­рузка эле­мен­тов стра­ницы (кар­тинки, CSS-таб­лицы и про­чее), обра­щение к базе дан­ных и, воз­можно, к сто­рон­ним ресур­сам. Бот — это не поль­зователь, который откро­ет одну стра­ницу и изу­чает ее кон­тент, бот откры­вает стра­ницу за стра­ницей, что может выз­вать негатив­ные пос­ледс­твия.