В статията „Скритият съпорт и грижата за Вашите сайтове“ извадихме наяве „невидимите” ежедневни дейности, които нашият СуперСъпорт извършва за сайтовете на нашите клиенти. И сега ще добавим още един пример за това, как приемаме присърце грижата за клиентите ни (и сайтовете им 🙂).
Скритият съпорт в действие
По време на ежедневна, „неангажираща“ клиента, проверка от наша страна, попаднахме на сайт, който отчетливо е повишил потреблението си на MySQL процесорно време. Тази проверка е част от дейностите на скрития съпорт и е инициирана от нотификация за бавни SQL заявки, изпълняващи се на хостинг сървъра.
Завишеното потребление на процесорен ресурс не е категоричен индикатор за проблем и може да е естествен резултат от пиков прилив на посетители в сайта.
От проверката установихме, че сайтът е онлайн книжарница за антикварни книги – https://knigite.eu. Това, което ни направи голямо впечатление (докато разглеждахме каталога 🙂) е, че отварянето на която и да е страница от сайта отнема приблизително 5 секунди. Това е твърде много време за зареждане на онлайн магазин и чакането определено не е добро потребителско изживяване.
5 секунди за зареждане на страница в сайта е прекалено много време. Дори да е с най-полезното и търсено съдържание сред конкурентите си, сайтът ще губи посетители и позиции в търсачките.
Не искахме просто да уведомим клиента за високото потребление на ресурси от неговия сайт, а да предложим решение, което да ускори зареждането му.
Затова направихме задълбочено и подробно проучване на възможните причини за забавянето. Извършихме анализи и тестове на различни решения, за да можем едновременно да ускорим сайта и да намалим потреблението на процесорни ресурси.
Всички тестове и проверки се извършиха на предварително създадено тестово копие на сайта. А резултатите от приложеното решение върху това копие, бяха представени на клиента, преди да се приложат на реалния му сайт.
Данни за сайта
- Сайтът използва хостинг план СуперХостинг, който е подходящ за онлайн магазини.
- Сайтът е тип онлайн книжарница, използващ уеб CMS платформа PrestaShop версия 1.6.
- Параметрите на хостинг плана са напълно достатъчни за посещенията от потребители.
Казусът
Повишеното потребление на MySQL процесорно време се оказа, че е често срещан казус при версия 1.6 на платформата PrestaShop.
Казусът е комбинация от изпълнението на неоптимална SQL заявка върху голямо количество информация в само една таблица в базата данни.
За да стигнем до решението на този казус, извършихме много проверки. Разгледахме подробно с xdebug и strace за възможни причинители на забавеното зареждане. Опитахме различни варианти за намаляване на обръщенията към базата данни, дори и с кеширащи механизми. За съжаление, това не даде добър резултат.
Междувременно, една бавна SQL заявка ни насочи към проблемната таблица ps_configuration:
# User@Host: cpuser_myshop[cpuser_myshop] @ localhost []
# Query_time: 3.273069 Lock_time: 0.000123 Rows_sent: 660005 Rows_examined: 660015
SELECT c.`name`, cl.`id_lang`, IF(cl.`id_lang` IS NULL, c.`value`, cl.`value`) AS value, c.id_shop_group, c.id_shop
FROM `ps_configuration` c
LEFT JOIN `ps_configuration_lang` cl ON (c.`id_configuration` = cl.`id_configuration`);Самата SQL заявка е част от функционалностите на използваната платформа PrestaShop. Неоптималното ѝ изпълнение е пряко свързано с това, че в таблицата ps_configuration в базата данни на електронния магазин, е налично голямо количество информация.
За да разберем защо в тази таблица, която стандартно трябва да съдържа само конфигурационни данни за сайта, има толкова много информация, проверихме множество записи в нея, един по един.
Открихме много записи за изоставените колички в магазина, а това е информация, която не би трябвало да се намира в конфигурационната таблица. И докато проучвахме защо тази информация е там, стигнахме до откритието, че тази таблица е hardcode-ната (директно зададена като име в кода) в един от системните файлове на сайта, и по този начин тя се пълни с излишни данни. Колкото повече се пълни таблицата, толкова по-бавни стават заявките към нея, и толкова по-бавен става сайта.
Голямото количество информация в посочената таблица засяга пряко скоростта, с която се зареждат всички страници в сайта. Причината за това е, че при много голяма част от действията в електронния магазин, се изпълняват заявки към конфигурационната таблица ps_configuration.
Решението
След като завършихме анализа на различни методи, с които може да се подобри скоростта на зареждане на сайта, стигнахме до комплексното решение на казуса.
За разрешаването на казуса, приложихме три промени и оптимизации върху сайта, файловете и базата му данни.
Прилагане на patch в един файл на системата
За да се коригира директното задаване на таблицата в кода на системата, приложихме малка, но много съществена поправка в един системен файл – /home/cpuser/public_html/classes/Configuration.php.
Поправката представлява редакцията на кода от:
446: -$result &= Db::getInstance()->insert('configuration', $data, true);на:
446: +$result &= Db::getInstance()->insert(self::$definition['table'], $data, true);Тази промяна е одобрена от разработчиците на PrestaShop с pull request от потребител, който също е забелязал подобен казус със сайта му.
Изчистване на ненужните записи в таблица ps_configuration
След като записването на излишна информация в тази таблица вече е преустановено, остава да се изчисти вече записаната такава в нея.
От предварителната проверка видяхме, че много от информацията представлява дублирани записи в тази таблица ps_configuration. За да видим информация за количеството дублирани записи, направихме следната SQL заявка:
SELECT count(*),name FROM ps_configuration group by name order by count(*) DESC След като вече знаехме коя е информацията, изчистихме всички ненужни записи в таблицата ps_configuration. Това почистване намали размера на базата данни с над 200 MB и от 670 MB стана 420 MB.
Резултати
Резултатите от решението на казуса са само положителни, за нас, за клиента, и за неговите клиенти.
Ускоряване на сайта
Най-осезаемият резултат от разрешаването на казуса, е забележителното ускоряване във времето за зареждане на сайта и страниците му.
От средно 5 секунди, времето за зареждане на сайта падна до средно 1 секунда. Това вече е добра предпоставка за по-добро потребителско изживяване, което помага за изграждане на лоялна клиентска база. Посетителите вече няма да се „редят на опашка” за книги, а ще си ги поръчват на момента 🙂. Не може да не споменем и по-голямата обич от търсачките към бързия сайт, което ще допринесе за разширяване на бизнеса.
Началната страница на онлайн книжарницата вече зарежда за под секунда (~600 милисекунди) 👀 , дори без активиран кеш в браузъра.
Страницата за продукт зарежда за около 2 сек., а страницата за категория/резултати от търсене за около 1 сек.
Тъй като от прилагането на решението в сайта мина известно време, вече може да се отчете и промяна в броя на посещенията му. За януари 2019г. вече има 2 пъти повече посетители месечно.
Намалено потребление на процесорен ресурс
Другият резултат от решаването на казуса, е в намалено потребление на процесорни ресурси за хостинг акаунта. CPU минутите намаляха от около 150-200 мин/ден до 25-50 мин/ден.
Най-важният резултат от решението на казуса, който е истинската награда за нас, е:
„Благодарна съм за проявената проактивност, толкова неща изчетох и променях, за да се подобри скоростта, а сега това ми идва като прекрасен подарък.“
Освен чисто техническите положителни резултати, получихме голямо удовлетворение от това, че сме помогнали на клиент в нужда, както и от получената благодарност за извършените от нас действия.
