문제

나는 최근에 세션 변수에 모든 DB 데이터 개체와 심지어 DB 연결 개체까지 포함하여 많은 항목을 저장하는 ASP 1.1 웹 응용 프로그램을 발견했습니다.그것은 결국 거대해집니다.웹 세션 시간이 초과되면(사용자가 애플리케이션 사용을 마친 후 4시간) 데이터베이스 트랜잭션이 롤백되는 경우가 있습니다.IIS가 세션을 종료할 때 DB 연결이 제대로 닫히지 않기 때문이라고 가정합니다.

어쨌든 내 질문은 세션 변수에 무엇이 있어야 하는가입니다.분명히 거기에 몇 가지가 있어야합니다.사용자는 메인 화면에서 편집하려는 계획을 선택하므로 계획 ID가 세션 변수에 들어갑니다.사용자(및 관리자 등)에 대한 모든 세부 정보와 사용자가 편집 중인 계획을 세션 변수에 저장하여 DB의 부하를 줄이는 것이 더 낫습니까? 아니면 세션 변수의 내용을 최소화하려고 노력해야 합니까? Page_Load 이벤트에 필요한 모든 것을 DB에 쿼리하시겠습니까?

도움이 되었습니까?

해결책

이는 응용 프로그램마다 다르기 때문에 답변하기가 매우 어렵지만 다음은 제가 사용하는 몇 가지 지침입니다.

  1. 세션에는 가능한 한 적게 참여하십시오.
  2. 특정 방문 동안에만 지속되어야 하는 사용자별 선택은 좋은 선택입니다.
  3. 사용자가 사이트를 방문하는 동안 여러 페이지에서 액세스할 수 있어야 하는 변수(페이지에서 페이지로 전달되는 것을 방지하기 위해)도 세션에 넣는 것이 좋은 경우가 많습니다.

귀하의 응용 프로그램에 대해 귀하가 말씀하신 내용을 토대로 아마도 DB에서 데이터를 선택하고 세션을 로드하는 대신 해당 쿼리의 영향을 최소화하는 방법을 찾으려고 노력할 것입니다.

다른 팁

하다 ~ 아니다 세션에 데이터베이스 연결 정보를 넣습니다.

캐싱에 관해서는 가능하면 캐싱용 세션을 사용하지 않을 것입니다. 다른 사람이 사용자가 사용 중인 데이터를 변경하는 문제가 발생할 수 있으며 사용자 간에 캐시된 데이터를 공유할 수 없습니다.ASP.NET 캐시 또는 기타 캐싱 유틸리티(예: Memcached 또는 Velocity)를 사용하세요.

어디까지나 ~해야 한다 세션에 들어가십시오. 모두 사용자가 사이트에 대해 연 브라우저 창(로그인, 보안 설정 등)은 세션에 있어야 합니다.어떤 객체가 보거나 편집되고 있는지 같은 것은 실제로 화면 사이에 전달되는 GET/POST 변수여야 합니다. 그러면 사용자는 여러 브라우저 창을 사용하여 응용 프로그램을 사용할 수 있습니다(이를 방지하려는 경우는 제외).

하지 마라 UI 개체를 세션에 넣습니다.

그 외에도 다양하다고 말하고 싶습니다.세션이 너무 많으면 직렬화 + 공급자 속도가 느려지기 때문에 진행 중인 세션을 사용하지 않는 경우 속도가 느려질 수 있습니다.캐시와 세션은 아껴서 주의해서 사용해야 합니다.당신이 할 수 있거나 편리하다는 이유만으로 세션에 참여하지 마십시오.그것이 의미가 있는지 앉아서 분석해 보세요.

이상적으로 ASP의 세션은 사용할 수 있는 최소한의 데이터를 저장해야 합니다.시스템 리소스를 열어둔 개체(특히 데이터베이스 연결)에 대한 참조를 저장하는 것은 확실히 확장성을 저하시키는 요소입니다.또한 커밋되지 않은 데이터를 세션 변수에 저장하는 것은 대부분의 경우 나쁜 생각입니다.전반적으로 현재 구현은 세션 개체를 남용하여 무상태 환경에서 상태 저장 애플리케이션을 시뮬레이션하려고 시도하는 것처럼 들립니다.

비록 악의적이지만 숨겨진 필드를 통해 자동으로 상태를 관리하는 ASP.NET 모델은 실제로 세션 변수에 무엇이든 유지할 필요성을 대부분 제거해야 합니다.

내 경험상 앱의 확장성(사용자/조회수 측면에서)이 높을수록 세션 상태를 사용하여 벗어날 수 있는 부분이 적어진다는 것입니다.그러나 절충안이 있습니다.사용자가 동일한 데이터에 반복적으로 액세스하고 일반적으로 사이트 사용당 세션이 상당히 긴 웹 응용 프로그램의 경우 일부 캐싱(세션 개체에 필요한 경우)은 실제로 DB 서버의 로드를 줄여 확장성에 도움이 될 수 있습니다.여기서의 아이디어는 백엔드 DB보다 프레젠테이션 계층을 파밍하는 것이 훨씬 저렴하고 덜 복잡하다는 것입니다.물론 모든 면에서 이 조언은 적당히 받아들여야 하며 모든 상황에 적용되지는 않지만 상당히 간단한 내부 CRUD 앱의 경우에는 도움이 될 것입니다.

매우 비슷한 질문 이전에 PHP 세션에 관해 질문을 받았습니다.기본적으로 세션은 여러 페이지 로드에 걸쳐 액세스해야 하는 사용자별 데이터를 저장하기에 좋은 장소입니다.세션은 데이터베이스 연결 참조를 저장하기에 좋은 장소가 아닙니다.일종의 연결 풀링 소프트웨어를 사용하거나 각 페이지가 로드될 때 연결을 열고 닫는 것이 좋습니다.세션에서 데이터를 캐싱하는 경우 이는 세션 데이터가 저장되는 방식, 필요한 보안 정도, 데이터가 사용자에게 특정한지 여부에 따라 달라집니다.더 나은 방법은 데이터 캐싱을 위해 다른 것을 사용하는 것입니다.

세션에 탐색 신호를 저장하는 것은 까다롭습니다.동일한 사용자가 여러 개의 창을 열면 변경 사항이 혼란스러운 방식으로 전파될 수 있습니다.DB 연결은 분명히 저장되지 않습니다.ASP.NET은 사용자를 위해 연결 풀을 유지 관리하므로 사용자가 직접 마법을 사용할 필요가 없습니다.짧은 기간 동안 항목을 캐시해야 하고 데이터 세트 크기가 상대적으로 작은 경우 가능한 옵션으로 ViewState를 살펴보십시오(페이지 크기에 더 많은 대량을 로드하는 대신).

ㅏ:한 명의 사용자와 관련된 데이터입니다.즉:사용자 이름, 사용자 ID.~에 최대 사용자를 나타내는 객체입니다.때로는 URL 관련 데이터(예: 누군가를 데려갈 곳) 또는 오류 메시지 스택이 세션에 푸시하는 데 유용합니다.

잠재적으로 여러 사용자 간에 자료를 공유하려면 애플리케이션 스토어나 캐시를 사용하세요.그들은 훨씬 우수합니다.

스티븐,
"I"로 시작하고 "BC"로 시작하는 웹사이트를 운영하는 회사에서 근무하시나요?그것은 제가 처음 .net에서 개발을 시작했을 때(어리고 멍청했던) 제가 했던 것과 정확히 같습니다. 세션과 애플리케이션에 제가 생각할 수 있는 모든 것을 집어넣었습니다.말할 필요도 없이 그것은 두 배 이상 좋지 않은 일이었습니다.
일반적으로 세션을 최대한 피하세요.확실히 직렬화 가능하지 않은 객체(데이터베이스 연결 등)는 여기에 저장되어서는 안 되지만, 직렬화 가능한 대형 객체도 저장되어서는 안 됩니다.당신은 오버 헤드를 원하지 않습니다.

나는 항상 세션 중에 정보를 거의 유지하지 않았습니다.세션은 비용이 많이 드는 서버 메모리 리소스를 사용합니다.세션에 너무 많은 값을 저장하면 서버의 부하가 증가하고 결국 사이트 성능이 저하됩니다.로드 밸런싱 서버를 사용할 때 세션 사용에 문제가 발생할 수 있습니다.그래서 제가 하는 일은 세션을 최소화하거나 전혀 사용하지 않고, 정보가 그다지 중요하지 않은 경우 쿠키를 사용하고, 숨겨진 필드와 데이터베이스 세션을 더 많이 사용하는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top