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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

В самом начале вы можете запустить крошечный сценарий для приложения после завершения развертывания, что «прогреет» приложение, однако, если клиент посетит ваш сайт до запуска сценария, он все равно столкнется с задержкой.Что у вас есть на данный момент, какие этапы после развертывания у вас есть?

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

Answer 3

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

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

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

Answer 4

Вы также можете попробовать этот подход: http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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