Напрям із блоку корпоративного розвитку: підключається тоді, коли продукт із MVP перетворюється на MMP і MLP. Вартість напряму: $4700.
Коли система сповільнюється, перший імпульс: додати ресурсів. Це працює, поки проблема в нестачі потужності, і не працює ніколи, якщо проблема в запиті, який читає всю таблицю.
Повільна система коштує грошей щодня. Менеджер чекає, поки завантажиться список угод, і встигає опрацювати менше заявок. Клієнт іде зі сторінки каталогу, не дочекавшись товарів. Звіт для власника будується так довго, що його перестають відкривати. А рахунок за сервер зростає, хоча користувачі різниці не помічають. Оптимізація сервера повертає швидкість без нескінченної купівлі заліза.
Що входить
- Оптимізація БД (індекси).
- Кешування.
- Оптимізація алгоритмів.
- Підвищення продуктивності сервера.
Оптимізація бази даних
Знаходимо запити, які виконуються найдовше або найчастіше, і розбираємо, як база їх виконує. Додаємо відсутні індекси, переписуємо запити, що тягнуть зайві дані, прибираємо повторні звернення до бази в циклах. У стеку Ingello це MySQL, а оптимізацію запитів закладають ще на етапі серверної бізнес-логіки.
Кешування
Результати важких і рідко змінюваних обчислень зберігаються в кеші (у нашому стеку це Memcached), щоб не рахувати їх на кожен запит. Для кожного кешу заздалегідь визначаємо, коли він скидається, інакше користувач побачить застарілі дані.
Алгоритми та сервер
Іноді повільна не база, а логіка: перебір там, де потрібен пошук, перерахунок усього там, де змінився один запис. Окремо налаштовується сам сервер: фонові процеси виносяться з користувацьких запитів, важкі задачі йдуть у чергу.
Порядок дій важливіший за набір прийомів
Спершу вимірювання, потім зміна. Без заміру оптимізація перетворюється на прикрашання коду: час іде, а користувач різниці не помічає, бо лагодили не те місце.
Заміряємо те, що відчуває бізнес: час відповіді ключових екранів і операцій, найповільніші й найчастіші запити до бази, навантаження на сервер у пікові години. Ці самі цифри повторюємо після змін, щоб було видно, що саме дала оптимізація.
Кеш стоїть останнім, а не першим. Він ховає симптом і легко стає джерелом нових помилок: застарілі дані виглядають страшніше за повільну сторінку.
Ще до розробки на брифінгу ми питаємо, скільки людей працюватиме одночасно і який обсяг даних очікується за рік. Навантаження визначає архітектуру: те, що працює на 10 користувачах, ламається на 500.
Чого оптимізація не лікує
Неправильної моделі даних. Якщо звʼязки спроєктовано погано на етапі технічного завдання, жоден індекс не врятує: знадобляться рефакторинг і міграція.
Що отримує бізнес
- Замір до і після: які сторінки й операції були повільними і що змінилося.
- Швидкі екрани, з якими співробітники працюють щодня.
- Витрати на сервер, що зростають разом із бізнесом, а не разом із помилками в запитах.
- Перелік місць, де проблема в моделі даних, а не в продуктивності, з оцінкою рефакторингу.
Скільки коштує і від чого залежить
Напрям коштує $4700 за фіксованою ціною: оптимізація бази, кешування, оптимізація алгоритмів і продуктивності сервера. На консультації визначаємо, які операції критичні для бізнесу і яке навантаження система має витримувати. Якщо систему писала інша команда, спершу проводиться аудит наявної системи: $800 за текстовий звіт або $2400 із раннім прототипом доробки.
Що ламається, якщо заощадити
- Бюджет іде на дорожчий сервер, а повільний запит лишається повільним.
- Кеш, доданий без правил скидання, показує клієнтам старі ціни й залишки.
- Система тримається, поки даних мало, і падає в найзавантаженіший день сезону.
- Оптимізацію роблять «на око» й лагодять не те місце, яке гальмує.
Приклади з практики
Власний приклад. Під час аудиту нашого блогу зʼясувалося, що в 36 записів текст важить понад 100 000 знаків, бо картинки вшиті просто в текст статті у вигляді закодованого рядка. Такі сторінки майже неможливо проіндексувати через швидкість завантаження. Потужний сервер тут не допоміг би: проблема була в тому, як зберігаються дані. Ми перенесли зображення в окремі файли, і сьогодні жодна з 1700 статей блогу не містить вшитих картинок.
У проєктах із потоковою обробкою даних у реальному часі продуктивність видно особливо наочно. Якщо обробка не встигає за потоком, дані накопичуються в чергах, затримка зростає, і за хвилину розмова йде з відставанням у десять секунд. Правильна система вміє вчасно відкинути зайве, а не накопичувати його.
Куди далі
Суміжні напрями: кешування та офлайн і рефакторинг. Карту зібрано в стратегії розробки застосунку.
Якщо Ваша система гальмує, а купівля сервера допомагає дедалі менше, запишіться на безкоштовну консультацію з архітектором. Розберемо, де шукати причину, а після консультації надішлемо розрахунок ціни та строків за етапами.
