Подтвердить что ты не робот

Как люди решают проблемы с пулом приложений при развертывании с большими приложениями?

В настоящее время после сборки/развертывания нашего приложения (58 проектов, большой asp.net MVC 3 front end) занимает ~ 15-20 секунд для загрузки, поскольку он проходит через всю "рециркуляцию пула приложений" (настройка выпуска).

У нас есть веб-ферма, если это изменяет ответы на людей, но на самом деле вопрос:

Что делают люди в приложениях большого масштаба, где окно обслуживания не является жизнеспособным (мы являемся 24/7 очень активным веб-сайтом), чтобы свести к минимуму первоначальный "первый удар" в утилите пула приложений после развертывания?

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

4b9b3361

Ответ 1

По умолчанию - если вы одновременно изменяете 15 файлов в приложении ASP.NET(даже через FTP), пул приложений автоматически перерабатывается. Вы можете изменить количество файлов, но как только файлы web.config и bin будут изменены, тогда его необходимо переработать. Поэтому, на мой взгляд, идеальным решением для такой среды, как ваша, было бы следующее:

4 веб-сервера (это произвольное число) каждый сервер имеет status.aspx, на который смотрит балансировщик нагрузки - используйте TeamCity, чтобы взять 2 из этих серверов "выключен" (от балансировки нагрузки) и подождать 20 секунд для фильтрации трафика. Распределенный кеш поможет сохранить проблемы с пользователем.

Используйте TeamCity для развертывания на этих двух серверах - выполните автоматические тесты и т.д., и как только вы счастливы вернуть их обратно в ферму, а затем отпустите остальные 2 в автономном режиме и разверните их

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

Это хорошая старомодная Canary Releasing - здесь есть несколько шаблонов http://continuousdelivery.com/patterns/, чтобы помочь принять во внимание. Id также предлагает копию этой книги непрерывной доставки - ее как непрерывную библию доставки и вывел меня из нескольких ситуаций:)

Ответ 2

На самой базе вы можете запустить tinyget script против приложения после завершения развертывания, которое будет "разминать" приложение, однако, если клиент попадет на ваш сайт до запуска script, он все равно столкнется с задержка. Что у вас сейчас есть, какие шаги после развертывания у вас есть?

В среде фермы вы также можете развертывать развертывания, поэтому извлеките один сервер из баланса нагрузки, обновите его, а затем принесите его в сеть после развертывания и вытащите другого, завершите развертывание, а затем снова вставьте в ферму. Как настроен ваш SQL Server - кластеризованный?

Ответ 3

скопируйте и вставьте из моего сообщения здесь

Мы используем стратегию развертывания Blue/Green на архитектуре с 4 уровнями, которая имеет веб-сайт на 4 серверах на верхнем уровне. Из-за сложности архитектуры, внедренной для развертывания, нам нужен был способ развертывания без нарушения какого-либо трафика на "живой" сайт. Следуя совету Fowler, но не совсем таким же образом, мы придумали решение, которое означает, что у нас есть 2 сайта на каждом сервере (синий и зеленый, или в нашем случае сайт A и сайт B). На живом сайте есть соответствующий заголовок хоста, и как только мы развернемся и протестируем на неживой сайт, мы перевернем заголовки двух сайтов так, чтобы то, что когда-то было живым, теперь является неживым сайтом, и наоборот, Эффект - это надежное развертывание, которое можно выполнить в рабочее время и с наивысшим уровнем уверенности.

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

Ответ 4

Во-первых, если вы не управляете Google или чем-то большим, загружается ли 15-20-секундное время в 3 часа, так как немногие пользователи действительно сильно влияют на это? Я бы сказал, что усилия, направленные на устранение случайного отставания, намного перевесят неудобства в 15-20 лет от нескольких пользователей.

К сожалению, я считаю необходимым зло использовать ASP.NET. Использование предварительно скомпилированного сайта (.DLL вместо файлов с кодом) уменьшит время, но не обязательно устранит его.

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

Ответ 6

не зная ничего о вашем сайте, моя первая мысль заключается в том, что вы можете разбить его на более мелкие сайты, чтобы они начинались быстрее по отдельности.

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

Ответ 7

Вы можете использовать aspnet_compiler.exe, чтобы предварительно скомпилировать ваше приложение, потому что я думаю, что задержка после развертывания вызвана фазой компиляции, а не "всей утилизации пула приложений".