ViewState가 기본적으로 서버에 저장되지 않은 이유를 다른 사람이 알 수 있습니까?기본적으로 ViewState가 서버에 저장되지 않는 이유는 무엇입니까?
왜 ViewState 대신 작은 세션 토큰을 보내면 ViewState가 서버에 필요한 모든 ViewState 정보에 매핑되어 전체 ViewState가 여러 번 게시 및 전달되는 것을 방지 할 수 있습니다.
내가 누락 된 항목이 있습니까?
메모리에 ViewState를 저장하는 데는 여러 가지 문제가 있습니다.
응용 프로그램이 재활용되면 응용 프로그램을 사용하는 모든 사용자의 VS가 손실됩니다.
응용 프로그램의 메모리 소비가 증가합니다. 서버에 호스팅 된 앱이 몇 개 밖에없는 경우에는 문제가되지 않습니다. 하나의 상자에 여러 웹 사이트가 호스팅 될 수있는 경우가 있습니다.
확장 성; 응용 프로그램이 활성화 될수록 더 많은 VS를 저장해야합니다. 그리고 당신은 1-1 (1 사용자 - 1 VS)을 추측 할 수 없습니다. 사용자는 여러 개의 탭을 열고 다시 돌아갈 수 있으며 탭을 비활성 상태로 유지할 수 있습니다 ...
VS 저장 기간은 얼마입니까? 페이지에 인코딩 된 데이터를 유지하면 사용자가 잠시 동안 사이트를 열어두면 데이터가 그대로 유지됩니다.
웹 팜에서 호스팅되는 경우 어떻게됩니까? 사용자가 각 요청에 대해 동일한 기계를 사용할 것이라고 보장 할 수는 없습니다. - 저장 VS 분산 메모리에서 Memcache를 사용
말했다되고 있다는 몇 가지 해결책이 있습니다. 이는 이상적이지 않습니다. 서버가 VS를 해당 서버에 저장 한 사람이 없으면 VS를 다운 시키지만 문제없이 응용 프로그램 풀을 재설정 할 수 있습니다.
SQL-Viewstate - VS를 SQL 데이터베이스에 저장합니다. 이렇게하면 요청 당 최소 1 개의 DB 읽기와 1 개의 DB 쓰기가 추가됩니다.다시 말하지만 이상적이지는 않지만 VS가 관리 할 수 없게되어 데이터베이스에서 VS를 설정하는 것이 HTTP를 통해 보내고받는 것보다 빠릅니다.
Filesystem-Viewstate - VS를 파일 시스템에 저장합니다. SQL 연결보다 비용이 적지 만 파일 서버가 분산 환경에서 작동해야합니다.
확장 성 - 1M 사용자가 복잡한 WebForms 페이지를 볼 때 얼마나 많은 서버 리소스가 필요한지 상상해보십시오. 서버는 최소한 세션 시간 초과 기간 동안 ViewState를 유지해야합니다. viewstate의 자동 서버 쪽 정리도 문제가 될 수 있습니다. 사용자가 한 번에 여러 페이지를 볼 수 있으므로 모든 페이지의 ViewState를 유지해야합니다.
편집 서버에 viewstate가 이동하는 방법에 대한 these posts에서 논의 된 몇 가지 기술이있다. 그러나 그렇게하기 전에 필요하지 않은 컨트롤/페이지에서 불필요한 viewstate를 제거하는 것이 좋습니다 (예 :보기 전용/다시 게시 렌더링 없음).
지금은 추측하고 있지만 viewstate가 10 년 전 설계되었을 때 32 비트 서버의 1GB RAM은 그만큼 좋았으며 아마도 MS는 부하 100 대를 원하는 호스팅 제공 업체를 생각해야만했을 것입니다 서버 당. 따라서 대역폭은 아마도 서버 RAM 및 디스크 스토리지보다 더 저렴한 것으로 간주되었을 것입니다.
서버가 메모리의 모든 것을 유지할 필요가 없으므로 확장 성이 향상됩니다. viewstate를 세션에 저장할 수는 있지만 일반적으로 권장되지 않습니다.
근본 원인은 클라이언트 쪽보기 상태를 사용하여 서버가 페이지의 현재 상태를 알 수 없다는 것입니다.
사용자가 걱정할 경우 응답을 기다리지 않고 페이지를 여러 번 (부분) 다시 게시하면 브라우저에서 여러 개의 부분 다시 게시 요청을 보내고 각 요청은 서버 측에서 새보기 상태를 만들어 결국 플러시됩니다. 브라우저에서 초기 뷰 상태를 종료합니다. 마지막으로 사용자가 마지막 포스트 백을 수행하면 그 시점에서 초기 복사본이 사라지고 예외가 발생합니다.
또한 서버 쪽보기 상태는 서버 성능과 사용자 환경에 영향을줍니다. 사용자가 하루 또는 오랜 시간 동안 페이지와 상호 작용하지 않으면 서버의보기 상태가 만료됩니다. 사용자가 나중에 페이지를 다시 게시하면 예외가 발생합니다.
예를 들어 길이 40 분인 YouTube 비디오를 봅니다. 어제는 전반부를 지켜 보았지만 탭을 닫지는 않았지만 컴퓨터를 허들로 쳤습니다. 오늘 저는 지난 반기를 계속 지켜보고 무언가를 다시 게시하면 뷰 상태가 서버에 있고 만료 된 경우 페이지에 오류가 발생합니다.
ViewState가 서버 메모리 문제 (많은 사용자가 있더라도)를 유발할만큼 충분히 크면 HTTP를 통해 전송하면 안되는만큼 충분히 커질 것이라고 생각했을까요? – Flash
ViewState는 '인스턴스'페이지 당 제공됩니다. 따라서 페이지 당 10KB, 1M 사용자, 각 사용자가 3 페이지를 열어도 서버의 30GB RAM 또는 디스크를 볼 수 있습니다. – StuartLC
동시 사용자 수는 백만 명입니다.이 경우 대처하는 서버는 어떤 경우에도 많은 양의 RAM이 필요할 수 있습니다. – Flash