Как да: Намалим процесорното време

Как да: Намалим процесорното време

Знаете за нашето Facebook предизвикателство, нали?

Днес ще ви представим статия в отговор на една от интересените теми зададени ни в нашата фейсбук страницата. Ето я и нея:

Nick Mirev: “Как да намалим изразходваното процесорно време? По възможност без да намаляваме crawl rate.” Тъй като често ни се случва да правим анализ откъде идва натоварването на сайтовете на клиентите ни, в тази статия ще опишем как протича един такъв анализ.

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

Процесорното време е мярка за количеството използвано време за обработка на специфични процеси/заявки на сървърния процесор. Много често се случва потребителите на хостинг услуги, да надвишават заделеното за тях процесорно време. Ето защо ние ще ви дадем няколко съвета как да избегнете това:

  • Редуцирайте броя на банерите и рекламите от други сайтове;
  • Избягвайте използването на прекалено много скриптове, и не натоварвайте HTML-а да поддържа код от страна на сървъра (като PHP и SHTML);
  • Колкото е възможно повече, избягвайте използването на https протоколи. Кодирането и разкодирането на комуникацията значително натоварва процесора много повече в сравнение с некриптираните комуникации;
  • Блокиране на SEO и агресивни ботове (различни от ботовете на Google, Bing и Yandex);
  • Сложете защита на формите за коментари и контакти с captcha, тъй като много ботове успяват да товарят по този начин;
  • Използване на LIMIT при извличане на информация от базата данни;
  • Използвайте кеширане;
  • Управлявайте ефективно процесорното време чрез следене на логове под SSH.

Ще разгледаме по-подробно управлението на процесорното време чрез SSH. Най-важното: Анализирайте лог-а! Всеки един анализ започвa от него, тъй като в над 70% от случаите на сериозно натоварване могат да бъдат открити в access_log-а. Използваме следната кратка команда (необходимо е да имате SSH достъп до акаунта си за да може да изпълните командите):

Влизаме в потребителската директория, където се намират логовете:

cd /home/potrebitel/access-logs/

с ls -la виждаме кой е най-големият лог файл и в долната команда заменяме “access_log” с името на този файл:

cat access_log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Тази команда ни дава информация за 20-те най-често посещавани ресурса от сайта:

6328 /wp-content/uploads/2015/01/magic-flowers-logo1.jpg

48 /wp-content/uploads/2015/03/Dostavka-cvetq-varnasmall2.png

43 /

29 /wp-content/uploads/2015/03/logo-dostakva-cvetq-varnasmall.png

25 /wp-content/uploads/2015/03/flowers-butterflies1.jpg

25 /wp-content/uploads/2015/03/b_white-flowers-against-a-white-background1.jpg

Изваждаме информация за 20-те най-чести посетителски IP адреса:

cat access_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

6349 91.215.216.37

1644 157.55.39.86

1491 157.55.39.180

1092 157.55.39.65

941 157.55.39.49

293 157.55.39.48

205 157.55.39.181

192 157.55.39.156

Извеждаме информацията за това какви User-Agent-и посещават сайта:

cat access_log | cut -d\ -f12- | sort | uniq -c | sort -rn | head -20

6336 "PHP/5.4.42"

6323 "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

212 "Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0"

195 "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36"

143 "Mozilla/5.0 (Linux; Android 4.4.2; GT-I9192 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.93 Mobile Safari/537.36"

Откриваме два притеснителни записа:

Сайтът има 6349 посещения от IP адрес 91.215.216.37, което е IP-то на сървъра. Обикновено това не е странно, но в случая това са твърде много посещения, които трябва да бъдат анализирани. Подробна проверка разкрива, че User-Agent-а използващ това IP е - PHP/5.4.42, което означава, че с PHP скрипт се извиква съдържание през http, което освен бавно е и тежко. Оптималният вариант е PHP скриптовете да извикват файлове локално.

Извадка от лога показва следното: 91.215.216.37 - - [03/Jul/2015:13:08:03 +0300] "GET /wp-content/uploads/2015/01/magic-flowers-logo1.jpg HTTP/1.1" 200 10517 "-" "PHP/5.4.42"

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

Втория притеснителен запис е:

6323 посещения от User-Agent "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"

Потребителят, следейки броячи като Google Analytics и Tyxo, вероятно вижда около 100-200 посещения в сайта си и смята, че няма как толкова посещения да товарят сайта му. Реално обаче посещенията са 6000+ заради подобни ботове, които няма как да бъдат отчетени от публичните броячи.

Хубавото в случая е, че този бот е „възпитан“ и може да бъде контролиран през Bing Webmaster tools и robotx.txt. Регистрирайки се и верифицирайки сайта си там, потребителят ще има възможност да намали честотата на обхождане на сайта си и по този начин да намали генерираното натоварване. Тази информация важи също така и за GoogleBot.

В случая препоръките ни към клиента са следните:

Премахване на функцията getimagesize, тъй като тя се изпълнява дори при посещение от ботове. Също така тя е напълно ненужна, ако не се променя ежедневно логото. Ако логото е избрано веднъж, то може да бъде описано в php/html файла. Ако все пак функцията е нужна, то може да бъде преработена да извиква файла локално, което ще намали натоварването и зареждането на сайта ще се ускори.

Какво можем да направим за crawl rate спрямо алгоритмите на Bing и Google:

Намаляването на Bing crawl rate-а ще намали посещението на Bing бота без това да доведе до негативни последици от SEO гледна точка. Негативни последици би могло да има единствено за новинарски сайтове и сайтове с активно обновяване на информацията. За блогове, електронни магазини и фирмени сайтове намаляването на честотата може да доведе само до ползи, тъй като ще ви позволи да разположите още един сайт в хостинг акаунта си заради намаленото натоварване например.

Google има сложен алгоритъм за определяне на crawl rate-а (честотата на обхождане) за всеки сайт. Целта е да се обходят максимално много страници от вашия сайт при всяко посещение без да претоварваме сървъра. Ако Google обхожда твърде често вашия сайт и забавя работата на вашия сървър можете да промените честотата на обхождане (времето, необходимо на Googlebot-a да обходи сайта ви) на страници, които са на ниво root – например www.icn.bg и www.blog.icn.bg. Промяната на честотата на обхождане може да доведе до проблеми (например, Google няма да има възможност да обходи страниците с бързината, която сте му задали), затова не променяйте това, освен ако не забележите специфични проблеми, причинени от прекалено честия достъп на Googlebot-а до вашия сървър.

Етикети: #kak-da #protsesorno-vreme #user-agents #crawl-rate #getimagesize #php-skript #bingbot #log-fajl