Действительно ли время запуска веб-приложения так важно?

Разговаривал с кем-то о добавлении кода инициализации при запуске приложения, и он жаловался на то, что это приводит к увеличению времени запуска. Он не мог на самом деле указать причину (чувство кишки или что-то, не знаю). Это не интенсивное приложение, которое запускается примерно через минуту, мы развертываем несколько раз в год.

Я помню, как читал такой совет по вопросам, связанным с SO, когда-то, люди, которые советуют инициализировать при запуске вместо доступа к странице со штампом «если вы можете позволить себе штраф».

Я работал с веб-приложениями, которые запускались с 30 секунд до 4-5 минут, но когда они были в сети, они качались.

Так чего мне не хватает? Если это не жизненно важное приложение, такое как ... я не знаю ... для финансового рынка, медицинских приложений, исследования космоса и т. Д., Действительно ли это так важно для времени запуска?

PS Я строго имею в виду веб-приложения, настольные приложения должны начать молниеносно.

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

Для производственной среды это действительно не имеет значения; Либо небольшое время простоя приемлемо, а 5 минут все еще не много, либо это не так, и вам нужно реализовать какое-то переключение в реальном времени.

Я считаю, что это тот случай, когда знаменитый диалектический принцип Гегеля о переходе от количества к качеству действительно работает.

Видите ли, время всегда важно. Я согласен со словами Майкла Боргвардта о важности быстрой сборки во время разработки / тестирования, но я настаиваю на том, что (может быть, каким-то другим образом) это также очень важно для производства.

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

Реальный вопрос заключается в том, будет ли приложение работать без инициализации. У нас есть новые сотрудники, которые помешаны на «производительности», мой стандартный ответ: мне все равно, как быстро вы дадите неправильные результаты. ИМХО срезать углы, искажать алгоритмы, потому что «так будет быстрее», и другие отличные идеи только вносят ошибки.

Если требуется инициализация, сделайте это. Сколько времени будет потрачено впустую, когда конечные пользователи получат неправильные результаты, в конце концов обнаружат, что веб-приложение не так, позвонят вам и пожалуются, и вам придется вернуться и отладить / исправить / проверить / повторно развернуть? Теперь спросите своего коллегу, как сэкономлено время. (и я бы поспорил, что ваши серверные ядра в любом случае на 99% простаивают)

Этот вопрос не задает ни о какой конкретной платформе. Есть платформы, на которых время запуска действительно очень важно.

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

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

То же самое верно для многих других сред хостинга. Утечки в сторонних библиотеках, или даже в вашем собственном коде, который просто ускользнул от обнаружения, могут означать, что единственный надежный способ запустить ваш веб-сервис - это перезагружать его каждые столько запросов (часто от 100 до 10000) и т. Д. время запуска оплачивается часто. Использование этого шаблона допустимо, когда приложение имеет утечку, но запускается быстро; это невозможно, если запуск приложения занимает более нескольких секунд.

Вы рискуете, если ваше приложение будет признано не соответствующим стандарту или еще хуже - вашей способности к разработке. Теперь, это приложение может сэкономить кому-то так много времени и / или сделать такую ​​необходимую задачу, что благодарные пользователи могут смотреть сквозь долгий запуск.

Чтобы запрограммировать загрузку приложения таким способом, может потребоваться больше времени, но только заинтересованные стороны могут определить, стоит ли оно того. У меня был отчет, который работал за 55 секунд. и мы получили его до 35. Никто не заметил. Хотя с 35 до 18 лет я потратил вдвое больше времени, все это заметили, были благодарны и впечатлены. Переход от 5 до 3 минут для приложения, используемого несколько раз в год, не представляет особой проблемы. У пользователей просто будет меньше времени, чтобы тратить на Facebook или кофе.

Восприятие является ключом. Если компания не довольна командами разработчиков в целом и этим приложением, в частности, вы можете развить добрую волю и ускорить процесс.