데이터 테이블에 수천 개의 레코드 데이터를 저장하고 포스트 백에서 유지 관리해야합니다. 어느 옵션이 나 viewstate (내가 사용하는) 나 세션에 적합합니다. 내가 viewstate를 사용하면 그것을 저장하기위한 숨겨진 필드가 생성되고 페이지 로딩 속도가 느려집니다. 그래서 세션에 저장하는 데 오버 헤드 (서버 측 메모리 소비 및 응답 지연)가 있습니다. 솔루션을 제안 해주세요.성능 뷰 상태 또는 세션에 더 좋습니다
대용량의 데이터의 경우 세션이 훨씬 효율적입니다. 사용자가 특정 데이터 블록을 완료했을 때이를 감지 할 수 있으면 세션 변수를 null로 설정하여 메모리 오버 헤드를 줄일 수 있습니다. 항상 그렇게 할 수는 없지만 세션이 만료되고 메모리가 회수됩니다. 세션 제한 시간을 낮추면 일부는 도움이되지만 너무 작게 설정하지 않으면 사용자를 차단하지 않으려 고합니다. Web.config 파일에서 세션을 사용하도록 설정해야합니다.
의 ViewState :
여기 ViewState에 대 세션에 대한 기본적인 지침의 viewstate가 이진 데이터 구조를 Base64 그것을 수단 페이지에 배치되는 부호화 1.3333 배 (8/6) 크기이며 원래 이진 데이터의 이 데이터는 각 페이지보기마다 업로드되고 다운로드됩니다. ViewState에 많은 정보가있는 경우 페이지 응답 시간에 영향을줍니다. Base64 인코딩은 매우 최적화되어 있으므로 성능에 영향을 미치지 않습니다. 각 페이지 요청은 ViewState의 공간을 할당 한 다음 확보하고 장기간 메모리에 저장하지 않습니다. 데이터는 페이지에 있기 때문에 만료되지 않습니다.
세션 : 세션의 모든 데이터가 페이지로드 사이에 웹 서버에 보존됩니다. 이렇게하면 페이지가 작게 유지되고 세션 식별자 만 전달하면됩니다. 아래쪽면에서 세션에 데이터를 저장하는 데 사용되는 메모리는 세션이 만료 될 때까지 할당 된 상태로 유지됩니다. Session이 바이너리 데이터를 복사하는지 또는 포인터 만 유지하는지 궁금하다. Base64 인코딩과 마찬가지로 고도로 최적화되어 있기 때문에 발생하는 경우 성능이 저하되지 않습니다. 사용자가 페이지 뷰 사이에서 너무 오래 기다리는 경우 세션이 만료 될 수 있습니다. 세션이 만료되면 웹 페이지의 알려진 상태로 사용자를 되돌려 보내야합니다.
다른 하나의 문제는 세션에 정보를 저장하는 경우 세션 ID가 클라이언트 브라우저의 여러 탭에서 공유 될 수 있다는 것입니다. 세션에 저장된 데이터를 어떻게 사용하는지 조심해야합니다. 이를 테스트하여 사용자가 예기치 않은 결과를 얻지 않도록하십시오.
(참고 : 사용의 ViewState는 평온, 세션은 없습니다.)
viewstate 대신 전체 세션 변수를 사용하면 어떻게됩니까? –
Viewstate는 사용자 브라우저에서 유지 관리하므로 더 오래 지속됩니다. 따라서 사용자가 한 시간 동안 페이지에 앉아서 어딘가에 클릭해도 페이지는 여전히 뷰 상태를 유지하지만 세션은 만료되었을 것입니다. 트릭은 올바른 균형을 찾는 것입니다. – gmlobdell
네 말이 맞지만 뭔가 다른 걸 원한다. 두 경우 모두 페이지를로드하는 동안 필요한 메모리 소비와 시간은 얼마 일까? –
당신은 세션이나 뷰 상태의 레코드 만 저장해서는 안된다. –
다음에 가장 좋은 방법은 무엇입니까 –
페이지에 필요한 데이터 만 가져옵니다. 그리드를 바인딩하기 위해 데이터 테이블을 사용하는 경우처럼. 그런 다음 데이터 테이블에는 gridview의 현재 페이지에서 필요한 데이터 만 포함되어야합니다. –