Matomo Analytics. Покращення продуктивності системи

Нещодавно стикнувся з декількома проблемами при роботі з Matomo Analytics, помилка 503 що з'являється постійно, та довге завантаження звітів. Дослідження помилки показало, що в систему зберігається багато даних, та MySQL з PHP просто не витримує запитів.

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

Перед тим як робити зміни, будь ласка, зробіть бєкап системи!

Вводна інформація

Почну з того, що в систему аналіти яку я налаштовував дані приходили з чотирьох сайтів. Сумарна кількість запитів на один день ~ 250 000 тисяч сторінок.

Характеристики сервера (це Droplet на DigitalOcean): 2 RAM / 2 CPU / 25 SSD

Налаштування MySQL для генерації звітів

Перед початком додайте кілька корисніх опції в MySQL:

  1. увімкнути режим завантаження даних з файлів — local_infile
  2. налаштувати синхронізацію запису журналу транзакцій з диском — innodb_flush_log_at_trx_commit

Перевірте чи активовані ці опції. Для цього авторизуйтесь у MySQL будь яким чином та виповнить команди:

SHOW GLOBAL VARIABLES LIKE '%local_infile%';
SHOW GLOBAL VARIABLES LIKE '%innodb_flush_log_at_trx_commit%'

Результат гарній, і нічого не потрібно робити

Результат негарний, потрібно вносити налаштування в MySQL

Для нашаштування треба внести коррективи в файлі /etc/mysql/my.cnf і додати 2 строки у секцію [mysqld]:

innodb_flush_log_at_trx_commit = 2
local-infile = 1

Або від root користувача MySQL виповнити SQL-запит:

SET GLOBAL local_infile=true;
SET GLOBAL innodb_flush_log_at_trx_commit=2;

А краще за все залучити адміна 🤣, звісно якщо є така можливість

Як налаштувати автоматичну архівацію звітів у Matomo Analytics

Налаштування MySQL зробили, їдемо далі.

Відразу зроблю відсилання на офіційну документацію де я брав інформацію для цього розділу — https://matomo.org/faq/on-premise/how-to-set-up-auto-archiving-of-your-reports/

Тож спочатку я увійшов у налаштування системи та вимкнув архівування звітів при перегляді з браузера, та встановив Архівувати звіти щонайбільше кожні X секунд на 1800

Далі потрібно налаштувати cron job який буде генерувати звіти (у рамках статті я не розповідаю як треба додавати cron jobs, сподіваюсь ви знаєте що це таке 😉):

5 * * * * /usr/bin/php {/path/to/matomo/}/console core:archive --url={https://pontyk.com.ua/matomo/} > /dev/null

Де {/path/to/matomo/} — це шлях до папки з інстальованим Matomo, {https://pontyk.com.ua/matomo/} — сайт де ви передивляєтесь звіти. Cron job буде запускатися щогодини кожної пʼятої хвилини.

Доречі, дуже раджу ось такий сайт де можно дуже в наглядній формі налаштовувати час для cron jobs https://crontab.guru/

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

По-перше, частота запуску cron job була що години, це дуже рідко. По-друге, так як сервер не дуже потужний траплялись помилки при виконанні cron job. Для вирішення проблемі я зробив наступнім чином: запуск cron job зробив кожні 15-16 хвилин, та підрахунок звітів розбив по сайтам:

Таким чином данні сталі поступати частіше, помилки при генерації зникли я та замовник задоволені 😌.

Декілька порад, по-перше запустіть спочатку консольні таски руками, без параметрів, щоб ви побачили яки дані вони можуть віддавати (приклад):

По-друге, ознайомтесь яки параметрі можно передавати щоб зробити гнучкіше оновлення звітів — https://matomo.org/faq/on-premise/how-to-set-up-auto-archiving-of-your-reports/#help-for-corearchive-command

Як нашаштувати зберігання данних у чергу в Matomo Analytics

Для покращення продуктивності час пікових навантажень допоможе плагін — https://plugins.matomo.org/QueuedTracking. Завдяки цьому плагіну усі запити на відстеження пишуться не одразу в основні таблиці а в чергу Redis або MySQL.

Для інсталяції плагіна зайдіть у Marketplace -> Browse (ось інструкція як встановлювати плагіни у Matomo), у переліку знайдіть QueuedTracking.

Після інсталяції зайдіть у System -> General settings -> QueuedTracking.

У полі Backend оберіть опцію саме для вас.

QueuedTracking дозволяє записати дані у Redis чи MySQL, в моємо випадку Redis на сервері не доступен, тому я використовую MySQL (але дуже раджу саме Redis, він набагато швидший)

Number of queue workers — вказує, скільки потоків або процесів будуть використовуватись для обробки черги. Чим більше workers, тим більша швидкість обробки подій. Однак, важливо не перевантажувати сервер, тому розумний підхід полягає у встановленні приблизно 2-3 робітників на процесорний ядро сервера. Наприклад, якщо у вас є сервер з 4 ядрами, ви можете встановити 8-12 workers.

Number of requests that are processed in one batch — вказує, скільки запитів буде оброблено за один раз перед вставкою. Вибір оптимального значення залежить від пропускної здатності сервера та мережевої інфраструктури. Зазвичай рекомендується встановлювати значення між 20 і 50, але можна спробувати різні значення та визначити оптимальну налаштування для вашого середовища.

Process during tracking request — ця опція вказує як саме буде опрацьована черга. Може бути опрацьована під час запиту на відстеження (коли опція автована), або за допомогою cron job (коли опція деактивована). Так я тут говорю про покращеня продуктивності, то встановив cron job.

Мої налаштування:

Виконання сron job встановів щохвилини:

/usr/bin/php {/path/to/matomo/}/console queuedtracking:process > /dev/null 2>&1

Де {/path/to/matomo/} — це шлях до папки з інстальованим Matomo.

Висновки по статті

Після виконная всіх дій ви одразу побачите що система буде працювати шустріше, але, дані будуть доходити трохи з затримками.

В моєму випадку ці, так би мовити, «жертви» потрібні щоб система процювала стабільно, а затримка у 1 хвилину та 15 допустімі.

Сподіваюсь стаття стане вам у нагоді.