Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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