이전에 프로젝트에서 SqlServer/StateServer를 초기에 사용하라는 조언을 들었으므로 크기를 조정할 때 직렬화 할 수없는 개체 인 InProc을 사용하는 개발자의 함정에 빠지면 SqlServer/StateServer로 이동할 때 문제가 발생합니다. 후에.InProc에 대해 직렬화 가능한 세션 상태 액세스를 적용 하시겠습니까?
우리가 방금 시작한 것처럼 SqlServer 세션 상태의 InProc을 사용할 필요는 없지만 합리적으로 신속하게 확장해야 할 것입니다.
누구나 InProc을 사용할 때 직렬화 가능한 객체를 강제 실행하는 데 어떤 reccomendations가 있습니까? 아마도 래퍼를 만드는 것일까?
SqlServer/StateServer를 사용할 때 중요한 것은 웹 팜만 확장하는 것만은 아닙니다. 하나의 서버에서도 InProc 세션을 사용할 때 문제가 발생할 수 있습니다. 기본적으로 InProc을 사용할 때 응용 프로그램 풀이 재활용 될 때 "라이브"인 세션이 손실됩니다. 문맥에 맞게 말하면 구매 깔때기를 달리고 세션에 중요한 프로세스를 저장하고있는 것입니다 (왜 나쁜 습관은 다른 대화 일 수 있습니다). 어쨌든, 해당 세션 정보가 손상되거나 손실되면 사용자는 계속할 수 없습니다. 따라서 앱 풀은 현재 실시간 세션을 재활용하고 잃게되므로 현재 구매 유입 경로에있는 모든 고객이 이탈하여 잠재적으로 손실 될 수 있습니다.
그 이유만으로도 항상 최소한 (로컬로) SqlServer 세션을 실행하는 것이 좋습니다. 아키텍처를 개선하면 일반적으로 성능 문제가 무효화됩니다. 성능 문제가 발생하면 타사 StateServer 구현에서 잠재적으로 빨라야합니다.
라이브 서버에서 실행중인 InProc의 단점을 읽은 후에도 여전히 그렇게하고 있다면 기꺼이 할 수 있습니다 (사용자의 이유이므로 괜찮습니다). 권장 할 수있는 유일한 방법은 개발자 서버를 변경하는 것입니다. 테스트)를 실행하여 SqlState를 사용하고 Live 실행중인 InProc을 종료합니다. 그렇게하면 InProc을 사용하지 않는 환경에서 발생하는 문제를 볼 수 있으며 아무런 환경에서도 문제를 해결할 수 있습니다. 그런 다음 Live over를 전환하기로 결정하면 추가 개발 노력이 필요하지 않으며 모든 것이 잘 될 것입니다.
고마워요. @Paul. –