Problemas de balanceamento de carga ASP.NET AJAX

Question

Esta seria uma pergunta para quem possui código na pasta App_Code e usa um balanceador de carga de hardware.É verdade que o balanceador de carga de hardware pode ser configurado para sessões fixas para resolver o problema, mas em um mundo perfeito, eu gostaria que o recurso fosse desativado.

Quando um arquivo está na pasta App_Code e o site não é pré-compilado, o iis irá gerar nomes de arquivos aleatórios para esses arquivos.

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

Então, quando um usuário posta a página e é transferido para outro servidor, nada funciona.

Alguém tem uma solução para isso?Eu poderia mudar para um site pré-compilado, mas perderíamos a capacidade do nosso departamento de controle de qualidade apenas promover os arquivos alterados.

Answer 1

Você pode mover o que quer que esteja em seu app_code para uma biblioteca de classes externa se seu departamento de controle de qualidade puder promover toda a biblioteca.Acho que você ficará preso em sessões fixas se não conseguir encontrar uma maneira conveniente ou tolerável de mudar para um site pré-compilado.

Answer 2

Você tem o nó <machinekey> em ambos os servidores configurado com o mesmo valor?

Você pode substituir o arquivo machine.config em web.config para definir isso.Isso precisa corresponder, caso contrário você poderá ter situações estranhas como esta.

Answer 3

O seu balanceador de carga oferece suporte a sessões fixas?Com isso ativado, o balanceador roteará o mesmo IP para o mesmo servidor repetidamente dentro de uma determinada janela de tempo.Dessa forma, todas as solicitações (AJAX ou não) de um cliente sempre atingiriam o mesmo servidor no cluster/farm.

Answer 4

Ok, as primeiras coisas primeiro...a coisa do MachineKey é verdade.Isso deve ser absolutamente igual em todas as máquinas com balanceamento de carga.Não me lembro de tudo o que isso afeta, mas faça mesmo assim.

Segundo, vá em frente e pré-compile o site.Na verdade, você ainda pode enviar novas versões, sempre que houver um arquivo .cs para uma página, essa página será recompilada.O que fica complicado são os arquivos app_code que são compilados em uma única dll.No entanto, se uma alteração for feita lá, você poderá fazer upload da nova dll e novamente tudo ficará bem.

Para tornar as coisas ainda mais fáceis, ative a opção "Nomenclatura fixa usada e montagens de página única".Isso garantirá que as coisas tenham o mesmo nome em cada compilação, então você apenas testa e substitui os arquivos .dll alterados.

Dito isso, você não deveria estar tendo um problema como está.A solicitação vai para o IIS, que apenas exibe a página e compila conforme necessário.Se o código por trás for diferente em cada máquina, isso realmente não importa, o código é o mesmo e essa máquina fará referência ao seu próprio código.A solicitação/postback real não sabe nem se preocupa com nada disso.Tudo o que eu disse acima deveria ajudar a simplificar as coisas, mas deveria estar funcionando de qualquer maneira...então provavelmente é um problema de máquina.

Answer 5

Se for um balanceador de carga de hardware, você não deverá ter problemas, pois tudo o que se sabe é a URL da solicitação, na qual o servidor compilaria a página solicitada e a serviria.

o único problema que consigo imaginar é com a sessão e o estado de visualização.

Answer 6

É verdade que o balanceador de carga de hardware pode ser configurado para sessões fixas para resolver o problema, mas em um mundo perfeito, eu gostaria que o recurso fosse desativado.

Answer 7

Parece que é apenas para criptografia ViewState.Isso não afeta os nomes dos arquivos para assemblies compilados automaticamente.

Answer 8

Acho que o modelo asp.net tem bastante dependência de criptografia e armazenamento específico da máquina, então não tenho certeza se funciona para evitar IP fixo para sessão.

Não conheço o ASP.NET AJAX (em vez disso, uso a abordagem MonoRail NJS), mas o estado da sessão pode ser um problema para você.

Você precisa garantir que os estados da sessão sejam serializáveis ​​e não use a sessão InMemory.Você provavelmente precisará executar o ASP.NET Session State Server para garantir que todo o farm de front-end esteja usando o mesmo armazenamento de sessão.Nesse caso, a sessão deve ser perfeitamente serializável (é por isso que nenhum objeto na sessão é preferido, você deve sempre usar o ID, e aposto que a MS mantém essa limitação quando desenvolve a biblioteca AJAX)