Чи дійсно важливий час запуску веб-додатків?

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

Я пам'ятаю, як читав подібні поради щодо питань щодо SO деякий час тому, коли люди радили ініціалізувати під час запуску, а не на доступ до сторінки з маркою "якщо ви можете дозволити собі штраф".

Я працював з веб-програмами, які починалися від 30 секунд до 4-5 хвилин, але, коли вони в Інтернеті, вони хитнулися

То що мені не вистачає? Якщо це не життєво важливе застосування, як ... я не знаю ... для фінансового ринку, медичних застосувань, космічних досліджень тощо, чи справді це важливо час запуску?

PS Я чітко маю на увазі веб-програми, настільні додатки змушені швидко починати блискавки.

Це може бути важливим фактором під час розробки: якщо ваша платформа не підтримує зміну коду в запущеному додатку, то час запуску стає частиною вашого циклу зворотного зв’язку, і там навіть 30 секунд є болючими та загрозою для продуктивності.

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

Я вважаю, що це той випадок, коли насправді діє відомий діалектичний принцип Гегеля про перехід від кількості до якості.

Розумієте, терміни завжди важливі. Я погоджуюся зі словами Майкла Боргвардта про важливість швидкої побудови під час розробки / тестування, але я наполягаю на тому, що це (можливо, інакше) це також дуже важливо для виробництва.

Кожен розробник, який розгорнув у виробництві якийсь поганий код, знає, що виправлення, надане за 5 хвилин і за 1 хвилину, - це справді, дуже різні речі.

Справжні питання - чи працюватиме програма без ініціалізації. У нас з’являються нові наймачі, які нав'язують «продуктивність», моя акція відповідає, що мені байдуже, як швидко ви даєте неправильні результати. Вирізання кутів IMHO, алгоритми керування, оскільки "це буде швидше таким чином" та інші чудові ідеї лише вводять помилки.

Якщо потрібна ініціалізація, зробіть це. Скільки часу буде витрачено даремно, коли кінцеві користувачі отримають неправильні результати, врешті-решт з’ясують, що веб-додаток невірний, зателефонує вам та скаржиться, і вам доведеться повертатися назад та налагоджувати / виправляти / випробовувати / повторно використовувати? тепер запитайте колегу, як заощаджено час. (і я би ставлю на облік, що сердечні сердечники на 99% простоюють)

Це питання не задається про якусь конкретну платформу. Є платформи, на яких час запуску дійсно дуже важливий.

Наприклад, на Google App Engine; якщо до вашої сторінки не можна отримати доступ (а точніше, до неї звертаються рідше, ніж інша програма на тому ж вузлі), вона буде завантажуватися періодично.

Таким чином, якщо ви знаходитесь у нижній частині 99% частоти доступу до сайту, то час запуску - це час доступу; ваша програма перезапускається майже при кожному доступі. якщо ви знаходитесь в топ-1%, то ваша програма запускається на багатьох вузлах, і хоча багато звернень до сторінки повертаються з уже запущеного екземпляра, деякі все ще не будуть, і тому у вас буде переривчастий довгий час доступу .

Це ж стосується багатьох інших середовищ хостингу. Витоки в сторонніх бібліотеках або навіть у вашому власному коді, які просто ухиляються від відкриття, можуть означати, що єдиний надійний спосіб запустити вашу веб-службу - це перезавантажувати кожну стільки запитів (часто від 100 до 10000) тощо час запуску оплачується часто. Використання цього шаблону є прийнятним, коли додаток є герметичним, але швидко запускається; це нездійсненно, коли для запуску програми потрібно більше декількох секунд.

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

Програмування може зайняти більше часу для того, щоб ледаче завантажувати додаток, але лише зацікавлені сторони можуть визначити, чи варто це. У мене був звіт, який пробіг за 55 сек. і ми знизили його до 35. Ніхто не помітив. Хоча я витратив удвічі більше часу, отримуючи його від 35 до 18, всі помітили і були вдячні та вражені. Переходити від 5 до 3 хвилин на додаток, який використовується декілька разів на рік, не велика справа. Користувачам просто буде менше часу проводити у Facebook чи отримувати каву.

Сприйняття - це ключ. Якщо компанія не задоволена командами з розвитку в цілому, а саме цим додатком, можливо, ви захочете створити трохи доброї волі та прискорити роботу.