Звідки береться повільність
Код, який працював на тисячі записів, не обов'язково працює на мільйоні. Запит без індексу на маленькій таблиці непомітний, на великій він займає секунди. Цикл, який робить окремий запит до бази на кожен елемент списку, при ста елементах терпимий, при десяти тисячах кладе сторінку. Звіт, який рахує все з початку часів при кожному відкритті, з часом просто перестає відкриватись.
Це нормальна історія росту, а не помилка попередніх розробників. Просто настав момент, коли на неї треба подивитись.
Де шукаємо спочатку
База даних. Повільні запити видно в логах, і зазвичай кілька найважчих дають більшу частину проблеми. Індекси, які не поставили, запити, які тягнуть усі колонки, коли потрібні дві, звіти, що рахуються наживо замість заздалегідь.
Потім код навколо бази: N+1 запити в Eloquent або Doctrine, завантаження всієї таблиці в пам'ять, щоб відфільтрувати в PHP, відсутність кешу там, де дані міняються раз на день.
Далі те, що робиться синхронно, а має робитись у черзі: відправка листів, генерація PDF, виклики зовнішніх API під час запиту користувача.
І лише наприкінці сервер. Збільшити його завжди можна, але без виправлення причин це купує кілька місяців, після яких проблема повертається дорожчою.
Що робимо
Спочатку вимірюємо: профілювання, логи повільних запитів, реальні цифри по найважчих сторінках. Без вимірювань оптимізація перетворюється на здогадки. Потім виправляємо від найбільшого ефекту до найменшого, і після кожного кроку вимірюємо знову. Ви бачите, як змінився час відкриття кожної сторінки, а не чуєте «стало краще».
Найчастіше перші кілька кроків дають основну частину результату, і на цьому можна зупинитись.
Коли справді потрібна архітектура
Іноді проблема глибша: система від початку побудована так, що при поточному обсязі даних вона не може працювати швидко. Тоді потрібні зміни в структурі, черги, окремі сховища для звітів. Це вже не оптимізація, а модернізація, і про неї ми говоримо окремо, з оцінкою по етапах. Але спершу завжди дешеві кроки: вони часто виявляються достатніми.