Натиснете ENTER, за да видите резултатите или ESC за изход.

Ускоряване на PrestaShop - от 5 секунди до 1 секунда (case study)

В статията „Скритият съпорт и грижата за Вашите сайтове“ извадихме наяве „невидимите” ежедневни дейности, които нашият СуперСъпорт извършва за сайтовете на нашите клиенти. И сега ще добавим още един пример за това, как приемаме присърце грижата за клиентите ни (и сайтовете им 🙂).

Скритият съпорт в действие

По време на ежедневна, „неангажираща“ клиента, проверка от наша страна, попаднахме на сайт, който отчетливо е повишил потреблението си на 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 мин/ден.

Най-важният резултат от решението на казуса, който е истинската награда за нас, е:

„Благодарна съм за проявената проактивност, толкова неща изчетох и променях, за да се подобри скоростта, а сега това ми идва като прекрасен подарък.“

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

Специалист Техническа Поддръжка

Меган е една от нашите super-support-гурута. СуперСилите ѝ се крият в таланта ѝ да разказва за технически „неща“ по разбираем и достъпен начин.

0 0 гласове
.
500px270px
SuperHosting.BG
Абониране
Уведоми ме при
guest
4 Коментара
Коментари към текста
Виж всички коментари

Privacy Preference Center

Necessary

Advertising

Analytics

Other

4
0
Какво мислите?x