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

Question

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

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

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

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

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

Answer 1

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

Answer 2

Установлен ли для узла <machinekey> на обоих серверах одинаковый параметр?

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

Answer 3

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

Answer 4

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

Во-вторых, продолжайте и предварительно скомпилируйте сайт.На самом деле вы все еще можете выпускать новые версии всякий раз, когда для страницы есть файл .cs, и эта страница перекомпилируется.Что становится сложнее, так это файлы app_code, которые компилируются в одну библиотеку dll.Однако, если там будут внесены изменения, вы можете загрузить новую библиотеку dll, и снова все должно быть в порядке.

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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