Проблемы балансировки нагрузки ASP.NET AJAX

Question

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

Если файл в папке App_Code и сайт предварительно не скомпилирован, iis будет генерировать случайные имена файлов для этих файлов.

server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"

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

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

Answer 1

У вас на обоих серверах установлено одинаковое значение?

Вы можете переопределить файл machine.config в web.config, чтобы установить это. Это должно соответствовать, иначе вы можете получить странные ситуации, подобные этой.

Answer 2

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

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

Чтобы еще проще, включите опцию «Использовать фиксированные имена и одностраничные сборки». Это обеспечит одинаковое имя для каждой компиляции, поэтому вы просто протестируете, а затем замените измененные DLL-файлы.

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

Answer 3

Поддерживает ли ваш балансировщик нагрузки липкие сеансы? При этом балансировщик будет многократно маршрутизировать один и тот же IP-адрес на один и тот же сервер в течение определенного промежутка времени. Таким образом, все запросы (AJAX или другие) от одного клиента всегда будут попадать на один и тот же сервер в кластере / ферме.

Answer 4

Я думаю, что модель asp.net имеет небольшую зависимость для шифрования и машинно-зависимого хранилища, поэтому я не уверен, работает ли она, чтобы избежать залипания IP для сеанса.

Я не знаю о ASP.NET AJAX (вместо этого я использую MonoRail NJS), но состояние сеанса может быть проблемой для вас.

Вы должны убедиться, что состояния сеанса сериализуемы, и не использовать сеанс InMemory. Вероятно, вам нужно запустить ASP.NET Session State Server, чтобы убедиться, что вся ферма внешнего интерфейса использует одно и то же хранилище сеансов. В таком случае сессия должна быть идеально сериализуемой (поэтому ни один объект в сессии не является предпочтительным, вы должны всегда использовать ID, и я держу пари, что MS придерживается этого ограничения, когда они делают разработку библиотеки AJAX)

Answer 5

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

Answer 6

Похоже, что это только для шифрования ViewState. Это не влияет на имена файлов для автоматически скомпилированных сборок.

Answer 7

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

Answer 8

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

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