Чому ваше ПЗ стає повільнішим зі зростанням - і як це виправити

Майже кожен бізнес, що росте, впирається в одну стіну: застосунок, що на старті відчувався миттєвим, з кожним місяцем стає повільнішим. Сторінка, що відкривалася вмить, тепер крутиться кілька секунд. Люди це помічають - і починають уникати повільних місць.

Нещодавно ми виправили саме це для клієнта: місячний звіт, що відкривався 47 секунд, тепер вантажиться за 3. Ось що насправді відбувається - без технічного жаргону.

Чому воно сповільнюється

Коли даних було мало, ПЗ могло дозволити собі працювати неощадливо - перераховувати все з нуля на кожен клік було нормально. Зі зростанням даних той самий підхід тихо стає вузьким місцем:

• Більше записів - більше обчислень на кожен запит
• Застосунок часто перераховує ті самі числа знову і знову
• Дрібні неефективності, що не мали значення на 1 000 записів, стають болючими на 1 000 000

Повільне ПЗ - зазвичай не «поганий код». Це код, що був правильним для меншого бізнесу й ніколи не оновлювався під більший.

Як ми це виправили

Ми не переписували все наново, а просто зробили розумніше:

• Ми порахували важкі числа один раз і зберегли результат, замість повторювати на кожне відкриття
• Організували дані так, щоб звіт миттєво знаходив потрібне

Зміна була невеликою. Ефект - прискорення у 15 разів: з 47 секунд до 3.

Чотири причини, які зазвичай і гальмують

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

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

Як зрозуміти, що саме у вас

Щоб звузити коло, читати код не обов'язково:

• Повільно завжди, навіть без нових даних: щось перераховується. Перший рядок.
• Швидко для старих клієнтів, повільно для найбільшого: індекс або запит, що росте з кількістю рядків. Другий рядок.
• Тим повільніше, чим більше елементів на екрані: запити в циклі. Третій рядок.
• Повільно лише при збереженні, відправці чи експорті: робота відбувається всередині запиту. Четвертий рядок.

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

Що це означає для вас

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

1. Пошук роботи, яку ПЗ виконує без потреби повторно
2. Виконання цієї роботи один раз
3. Організація даних навколо того, як вони реально використовуються

Це швидше й дешевше, ніж очікують - а користувачі відчувають результат одразу.

До речі, місячна звітність - один із процесів, які найчастіше автоматизують повністю: ми зібрали 10 прикладів AI-автоматизації для малого бізнесу з цінами й строками окупності.

Часті запитання

Чи означає повільне ПЗ, що потрібне переписування? Зазвичай ні. У більшості продуктів, що ростуть, причина - одна з чотирьох: числа перераховуються при кожному відкритті, немає індексу, дані забираються в циклі або повільна робота відбувається всередині запиту. Кожне лікується точково, а не перебудовою.

Скільки часу треба, щоб знайти причину? Зазвичай пів дня. Характер симптому звужує коло ще до читання коду: повільно завжди - це перерахунок, повільно лише для найбільшого клієнта - індекс, повільніше з кожним рядком на екрані - запити в циклі.

Скільки коштує виправлення продуктивності? Оцінюємо після короткого дзвінка, бо відповідь повністю залежить від того, яка з чотирьох причин у вас. Приклад вище, звіт із 47 секунд до 3, був невеликою зміною, а не переписуванням.

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

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