Или как събирането и обработката на две допълнителни статистики могат да струват скъпо!
Всички знаем, че статистиката е полезна. Дава ни бърз достъп до обобщена информация и възможност за качествен анализ на данните и на нейна база взимаме решения. Събирането и обработването на статистики обаче е процес, който може да отнема много повече ресурс от предварително планирания.
Днес ще ви разкажем един реален пример от работата ни или как два статистически модула, добавени в хостинг услугата, могат да доведат до покачване на потреблението на ресурс от хостинг услугата повече от два пъти.
Модул Piwik – един от най-популярните софтуери за статистика. Системата може да се инсталира в хостинг услугата. Събира и предоставя статистика за посещенията на вашия сайт, информация за потребителите, за търсещите роботи и ключовите думи, по които е намерен сайта и др.
Нашият клиент Димитър Димитров от Inbound.bg използва Managed VPS. Един ден мониторингът на услугата ни показа, че броят PHP процеси започва да се запълва.
Екипът ни разгледа внимателно причината за запълването на процесите и установи причината.
Клиентът ни отскоро ползва Piwik като втори източник на статистически данни освен Google Analytics. Piwik системата се използва в няколко проекта. В един от уеб проектите по същото време има активна промоционална кампания и е с по-голяма посещаемост от обичайното.
Когато се зарежда сайт, в който е добавен Piwik, към системата на Piwik се прави заявка, за да се запишат данните. Заявката се обработва чрез PHP скрипт. При по-голям брой посещения на сайта се увеличават и броя заявки, които се извикват в Piwik системата.
След този анализ екипът ни се свърза с клиента и увеличи параметрите на памет и брой процеси на Managed VPS плана.
Ще цитираме и Димитър Димитров (с негово позволение):
„Виж ти как един софтуер, супер орязан с пет модула, може да им струва много на хората”, каза той гледайки графиката на системни параметри…, “А аз го сложих ей така, като втори източник.” 🙂
Анализът на изчерпването на PHP процесите беше една от стъпките, преди да анализираме и покачването на изразходваното процесорно време. Процесорното време включва времето за обработка на PHP заявките и времето за обработка на MySQL заявките. Забеляза се драстична разлика спрямо двата параметъра – PHP времето в най-високите стойности достига почти 78 минути, но MySQL времето беше над 1433 минути! Това е повече от 18 пъти!
Да, вече нямаше съмнение, че трябваше да се анализира какви заявки се изпълняват към базите данни. Наблюдавахме MySQL съръвъра и ни направи впечатление, че към една от базите данни се изпълнява SQL заявка, която не е оптимална.
И тук „виновникът“ се показа веднага – HeatMapTracker. Системата дава възможност да проследите къде потребителите кликат из вашия сайт, кои страници от сайта привличат вниманието им или биват избягвани, дали скролират и къде и други.
Системата по аналог на Piwik е инсталирана в хостинг услугата и съхранява данните в база данни. С времето информацията се натрупва и това води до по-голям обем от данни.
Едно от неписаните правила при работата със софтуер гласи: Ако има неоптимални процеси при обработка на данни, те се виждат веднага при големи обеми от данни.
Тук неоптимално изпълнение на SQL заявка доведе до излишно потребление на ресурс.
Какво означава една SQL заявка да се изпълнява оптимално?
За уеб проекти е прието заявки, с които се извлича информация от база данни, да се изпълняват под една секунда. За оптимално изпълнение можем да кажем обаче, че е комбинация от два фактора:
- време на изпълнение на заявка;
- честота на изпълнение на заявка.
Ако SQL заявка се изпълнява повече от една секунда и се изпълнява веднъж на няколко секунди, то считаме това за неоптимално. Това води до две последствия:
- покачване на изразходваното процесорно време;
- забавяне в работата на сайта при тази функционалност, която изчаква резултата от заявката.
При нашия клиент се открои една SQL заявката от системата, която се изпълнява повече от една секунда и много интензивно. Заявката е:
# User@Host: user[user] @ localhost [] # Query_time: 1.683540 Lock_time: 0.000094 Rows_sent: 1 Rows_examined: 63160 SELECT * FROM hmtrack_main_8053a0fc9dec652dba7f3c9b05c3531e6fcbf31e WHERE session_id = '0' AND `project` = 'project';
Обикновено при добре структурирана SQL заявка целта е да се обработват оптимален брой редове. За целта могат да бъдат добавени индекси към таблиците или да се преработи заявката.
Добавихме индекс на колоната session_id. След тази промяна заявката се изпълнява за 0.0009 секунди. Или времето за изпълнение намаля 1870 пъти!
А процесорното време – вижте сами 😉
Съвет от съпорта: Managed VPS услугите разполагат с повече ресурси и възможност за повече процесорно време. Въпреки повечето ресурс обаче, не го харчете безразборно.
Подхождайте внимателно при ползването на статистически модули. Направете оценка на източниците и възможностите за анализ, които ви дават, но не подценявайте ресурса, който ползват.
