ASP.NET AJAX 부하 분산 문제
https://stackoverflow.com/questions/50771
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
App_Code 폴더에 코드가 있고 하드웨어 로드 밸런서를 사용하는 모든 사람에게 질문이 될 것입니다.문제를 해결하기 위해 하드웨어 로드 밸런서를 고정 세션으로 설정할 수 있다는 것은 사실이지만 완벽한 환경에서는 이 기능을 끄고 싶습니다.
App_Code 폴더에 있는 파일과 사이트가 미리 컴파일되지 않은 경우 iis는 이러한 파일에 대해 임의의 파일 이름을 생성합니다.
server1 "/ajax/SomeControl, App_Code.tjazq3hb.ashx"
server2 "/ajax/SomeControl, App_Code.wzp3akyu.ashx"
따라서 사용자가 페이지를 게시하고 다른 서버로 전송되면 아무 것도 작동하지 않습니다.
누구든지 이것에 대한 해결책을 가지고 있습니까?미리 컴파일된 웹사이트로 변경할 수 있지만 QA 부서가 변경된 파일을 홍보할 수 있는 능력을 잃게 됩니다.
해결책
QA 부서가 전체 라이브러리를 승격할 수 있는 경우 app_code에 있는 모든 내용을 외부 클래스 라이브러리로 이동할 수 있습니다.미리 컴파일된 사이트로 전환하는 편리하거나 허용 가능한 방법을 찾을 수 없다면 끈적끈적한 세션에 갇혀 있는 것 같습니다.
다른 팁
두 서버의 <machinekey> 노드가 동일한 값으로 설정되어 있습니까?
web.config의 machine.config 파일을 재정의하여 이를 설정할 수 있습니다.일치해야 합니다. 그렇지 않으면 이와 같은 이상한 상황이 발생할 수 있습니다.
로드 밸런서가 고정 세션을 지원합니까?이 기능을 켜면 밸런서는 특정 시간 내에 동일한 IP를 동일한 서버로 반복해서 라우팅합니다.이렇게 하면 한 클라이언트의 모든 요청(AJAX 또는 기타)이 항상 클러스터/팜의 동일한 서버에 도달하게 됩니다.
좋아, 먼저 할 일이...MachineKey는 사실입니다.이는 로드 밸런싱된 모든 머신에서 절대적으로 동일하게 설정되어야 합니다.그것이 영향을 미치는 모든 것을 기억하지는 못하지만 어쨌든 그렇게 하십시오.
둘째, 사이트를 미리 컴파일하세요.페이지가 다시 컴파일되는 페이지에 대한 .cs 파일이 있을 때마다 실제로 새 버전을 내보낼 수 있습니다.까다로워지는 것은 단일 dll로 컴파일되는 app_code 파일입니다.그러나 거기에 변경 사항이 있으면 새 dll을 업로드할 수 있으며 다시 모든 것이 정상일 것입니다.
작업을 더욱 쉽게 하려면 "고정 이름 지정 및 단일 페이지 어셈블리 사용" 옵션을 활성화하세요.이렇게 하면 각 컴파일에서 항목의 이름이 동일하므로 변경된 .dll 파일을 테스트한 다음 교체하면 됩니다.
즉, 현재대로 문제가 있어서는 안 됩니다.요청은 IIS로 전달되며, IIS는 페이지를 제공하고 필요에 따라 컴파일합니다.뒤에 숨은 코드가 각 컴퓨터마다 다르다면 실제로는 중요하지 않습니다. 코드는 동일하며 해당 컴퓨터는 자체 코드를 참조합니다.실제 요청/포스트백은 이에 대해 전혀 모르거나 신경쓰지 않습니다.위에서 말한 모든 내용은 작업을 단순화하는 데 도움이 되지만 어쨌든 작동해야 합니다...아마도 기계 키 문제 일 것입니다.
하드웨어 로드 밸런서인 경우 서버가 요청된 페이지를 컴파일하고 제공하는 요청 URL만 알려져 있으므로 문제가 발생하지 않습니다.
내가 생각할 수 있는 유일한 문제는 세션 및 보기 상태에 관한 것입니다.
문제를 해결하기 위해 하드웨어 로드 밸런서를 고정 세션으로 설정할 수 있다는 것은 사실이지만 완벽한 환경에서는 이 기능을 끄고 싶습니다.
ViewState 암호화에만 사용되는 것으로 보입니다.자동 컴파일된 어셈블리의 파일 이름에는 영향을 주지 않습니다.
asp.net 모델은 암호화 및 시스템별 저장소에 대해 상당한 의존성을 갖고 있다고 생각하므로 세션에 대한 고정 IP를 피하는 데 작동하는지 잘 모르겠습니다.
ASP.NET AJAX에 대해서는 모르지만(대신 MonoRail NJS 접근 방식을 사용합니다) 세션 상태가 문제가 될 수 있습니다.
세션 상태가 직렬화 가능한지 확인해야 하며 InMemory 세션을 사용하지 마세요.전체 프런트엔드 팜이 동일한 세션 저장소를 사용하고 있는지 확인하려면 ASP.NET 세션 상태 서버를 실행해야 할 수도 있습니다.그러한 경우 세션은 완벽하게 직렬화 가능해야 합니다(그래서 세션의 개체가 선호되지 않고 항상 ID를 사용해야 하며 MS가 AJAX 라이브러리 개발을 수행할 때 이 제한을 고수할 것이라고 확신합니다).
