Оптимизиране на процесорното време на сайт

Тази публикация е за сайтове разположение на споделен хостинг, но може да даде някои идеи за оптимизиране за всеки динамичен сайт без значение какъв хостинг ползва.

Какво е процесорно (CPU) време на сайт?

Когато един сайт се хоства на споделен хостинг, за него обикновено има ограничение на ресурсите, които може да използва. Например 30 минути на месец. Това се прави с цел да се гарантира нормалната работа на всички сайтове, които споделят общи сървърни ресурси. В тези минути се включва, както времето за обработка на заявките към базата данни - SQL сървъра, така и времето за обработка на скриптове като PHP файлове и др. - тези две времена са напълно независими и се сумират. Тази статия разглежда специално случая за оптимизиране на времето за обработка на скриптове. За оптимизиране на времето за обработка на заявките към базата данни виж статията Оптимизация на ресурсите на сайт

В CPU времето не се включва времето за сервиране на статично съдържание, като JS, CSS, IMG, HTML, PDF  и др. Но ако има включено излишно компресиране на статични файлове, това ще натовари сървъра допълнително. При пресмятане на времето трябва да се има предвид, че 1 минута процесорно време е времето, за което едно процесорно ядро ползва процесора на 100% или 2 ядра ползват процесора половин минута на 100%. Съвременните процесори имат 8 и 16 ядра и обикновено  си разпределят натоварването така, че никога не ползват 100%, а по-малък процент дори при тежки операции. Също така, обикновено един скрипт се изпълнява за хилядни части от секундата и само прекалено честото му изпълнение може да доведе до значително увеличаване на времето. Ето защо 30 минути на месец обикновено е достатъчно процесорно време, дори за силно посещавани сайтове.

Какво се случва, ако превишите това CPU време?

В най-добрия случай ще започнете да получавате уведомителни имейли от хостинг доставчика, че трябва да оптимизирате сайта, за да не отнема над разрешените сървърни ресурси или да закупите повече ресурси - по-висок ценови план. Важно е да направите едно от двете, в противен случай сайта може да бъде временно спрян, до отстраняване на проблема. Важно е да се отбележи, че скоростта на сайта и процесорното време не винаги са свързани. Често, когато един сайт е бавен, той има и завишено процесорно време, в такъв случай задължително трябва да се открие проблема и сайта да се оптимизира. Но е възможно сайта да върви бързо и да не може да се оптимизира повече, в такъв случай повишеното процесорно време се дължи на увеличените посещения и единственото решение е закупуване на повече ресурси. Звучи ли ти сложно? 🙂 Всъщност наистина е сложно, защото причините за превишено процесорно време може да са много различни и понякога причината не е само една.

Често срещани причини за превишено CPU време на хостинг сървър

Преди всичко проблемът трябва да се изследва, като се прегледат сървърните логове и статистики, за най-често ползваните скриптове и от къде най-често се посещава сайта. След това може да се измери всеки един от модулите на сайта, колко процесорно време изразходва. Най-честите причини за превишени сървърни ресурси са:

1. Софтуер, който зарежда излишно множество софтуерни библиотеки. Ако сайтът е WordPress се ползва тежкка дизайн тема или разширения (plugins).

2. Неправилно използване на кеширането на диска и в паметта. Ако сайтът е WordPress, неправилно настроено разширение за кеширане. Например грешни настройки на W3 Total Cache (W3TC) или грешни настройки за кеширане от хостинг панела cPanel.

3. Използване на онлайн чат за връзка с клиентите, когато се ползва сървърен скрипт, например live chat или ShoutBOX.

4. Динамични картинки - динамични размери на малки изображения (thumbnail) или слагане на воден знак (watermark) в реално време върху изображенията.

5. Статистически модули, собствено хостван уеб брояч или модули за рейтинг на публикации.

6. Софтуер за управление на реклами (ad server), хостван на същия уеб сървър.

7. Завишено посещение от роботи - автоматични скриптове паяци обхождащи сайта. Например Majestic, Ahrefs и др.

8. Автоматичен крон скрипт, който периодично изпълнява тежка операция, като преиндексиране, архивиране на SQL таблици или файлове и др.

Оптимизация на процесорно време на WordPress сайт

Това е един практически случай на оптимизация на сайт базиран на платформата WordPress. На изображението горе се вижда графика на процесорното време на сайта и как превишаваше лимита (червената хоризонтална линия). Вижда се, че SQL заявките бяха в норма, а само CPU времето нужно за обработка на PHP беше проблем. Всичко това при сайт с едва 200-300 уникални посещения на ден. Случаят беше интересен, защото причините бяха няколко.

Сайтът вече ползваше стандартни плъгини за кеширане.

Започнахме с анализ в AWStats и анализиране на логовете от сървъра на хостинга.

Ако в access лога има редове подобни на:

162.213.24.36 - - [15/Mar/2014:21:36:46 +0200] "POST /xmlrpc.php HTTP/1.1" 500 35646 "-" "GoogleBot/1.0"

или с други думи обръщение към файла xmlrpc.php като не е подаден параметър в предпоследното "-" това е знак, че има опит за атака.

Нормалният ред трябва да съдържа нещо като:

74.80.148.202 - - [14/Mar/2014:18:09:16 +0200] "POST /blog/xmlrpc.php HTTP/1.0" 200 504 "https://ganbox.com/blog/xhtml-%D0%B8-embed/" "PHP/5.2.10"

Освен, че има данни в предпоследната позиция, в последната се вижда, че обръщението не е от бот, който се представя за Googlebot, а от  PHP скрипт - това нормално е някой плъгин.

В този случай адресът  162.213.24.36 е на хостинг доставчик, вместо на посетител и може да се блокира в htaccess с директива:

deny from 162.213.24.36

.

Също така инсталиране на WordPress плъгин P3, който измерва кой плъгин изразходва най-много ресурси.

Пробвахме с изключване на няколко от най-тежките плъгини, но това не даде резултат.

Имаше множество посещения от ботове, някои от които не се идентифицираха с User-agent. Добавихме в robots.txt:

Crawl-delay: 20

Филтрирахме няколко IP адреса, на някои от най-активните ботове и тези, които не посочват User-agent с директивите:

RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule .* - [F]

Пренасочихме трафика към сайта през CDN услуга, което даде възможност за филтриране на посещенията от някои държави като Китай, Корея и др., както и спестяване на трафик при повторно ползване на статично съдържание от сайта.

Това даде само частичен резултат.

Оказа се, че има и опити за хакване по два вектора - опити за налучкване на паролата за админ панела и заявки към xmlrpc.php файла, с което се опитват да публикуват отдалечено. След вземане на мерки по тези две направления вече разликата беше чувствителна, но все още на границата.

И като крайна мярка спряхме вграденият крон на WordPress, който се стартираше прекалено често. В конфигурационния файл се добавя:

define('DISABLE_WP_CRON', true); # спира крон, пусни в cPanel

и го заменихме с извикване на крон скрипта през cPanel по веднъж на ден:

cd /home/domain/public_html && php -q wp-cron.php

И накрая намаляване честотата на автоматичното записване в режим на редакция на публикация. Оказа се, че става много забавно, когато започнеш да пишеш публикация, прекъснеш и забравиш редактора на браузъра отворен - на всяка минута, чрез Ajax се прави заявка за запис на текущата версия на публикацията. Това увеличава неочаквано много CPU времето.

define('AUTOSAVE_INTERVAL', 300);  # в секунди. Ganbox.com: за понижаване на натоварването на CPU на всеки 5 мин. вместо стандартното 1 минута
define('WP_POST_REVISIONS', 5);  # max 5 ревизии. Ganbox.com: за олекотяване на базата и ускоряване на сайта

Тук вече проблемът беше решен.

Като допълнителна мярка ползвахме плъгин WP Clean Up за почистване на базата данни от стари версии на публикации, кеширани мета данни и др. Понеже сайтът имаше стотици публикации и всяка с много ревизии, едно такова почистване оказа голямо влияние и след тази оптимизация, сайтът излетя 🙂

Може да се очаква, че това ще окаже положително влияние на SEO оптимизацията на сайта.