약간 더 큰 ASP를 작성해 본 사람이라면 누구나 Session 개체를 사용하여 사용자의 개인 데이터 변수를 기록하는 데 사용할 수 있으며 이는 안전하고 편리하다는 것을 알고 있습니다. 하지만 세션이 어떻게 작동하는지 정말로 알고 있나요? 약간 더 큰 ASP를 작성해 본 사람이라면 누구나 Session 개체를 사용하여 사용자의 개인 데이터 변수를 기록하는 데 사용할 수 있으며 이는 안전하고 편리하다는 것을 알고 있습니다. 하지만 세션이 어떻게 작동하는지 정말로 알고 있나요? 아마도 그것을 이해한 후에는 이 사랑스럽고 미워하는 물건을 더 이상 감히 사용하지 않을 것입니다. 대체 방법은 약간 번거롭기는 하지만 장기적으로 고려한 후에 수행해야 합니다.
먼저 세션의 이점에 대해 이야기해 보겠습니다. 세션은 클라이언트의 개인 데이터 변수를 기록하는 데 사용할 수 있으며 시간 범위 내에서 사라지지 않습니다. 이는 특히 사용해야 하는 멤버가 있는 시스템의 경우 정말 중요한 기능입니다. 회원의 로그인 계정, 시간, 상태 및 기록해야 하는 많은 실시간 데이터(예: 사용자의 장바구니에 있는 항목을 기록하는 쇼핑 시스템 등) 이 정보는 각 사용자에게 개인적으로 필요하며 일반적으로 개발자가 사용합니다. . 세션 기록 처리.
그러나 ASP의 세션은 쿠키로 구성되며, 서버는 세션에 기록된 모든 데이터를 쿠키의 형태로 사용자의 브라우저에 전송합니다. 일반적으로 일반 브라우저는 사용자가 링크를 클릭하고 서버에 다시 연결할 때마다 이러한 쿠키를 저장하여 처리를 위해 서버로 다시 보냅니다. 이것이 Session의 운영 원리입니다. 데이터의 양이 많아지면 내보내고 다시 가져와야 하기 때문에 회선 대역폭을 소모할 뿐만 아니라 서버가 온라인 처리 및 재구성에 더 많은 리소스를 소비해야 하므로 성능이 저하됩니다. 메모리. 초기 동작. 이제 여러분은 "이 기능을 사용해야 하므로 희생해야 한다"고 생각할 수도 있습니다. 그러나 이 기사는 한편으로는 Session을 덜 사용하도록 가르칩니다. 다음으로 나타나는 것은 Global.asa에도 속한다는 것입니다.
애플리케이션은 임시 데이터를 기록하고 처리하는 데에도 능숙합니다. 기능과 사용법은 모든 측면에서 Session과 동일하지만, 기록하는 데이터는 공개, 즉 모든 사용자가 공유할 수 있는 가변 공간입니다. Session과 달리 Application은 사용자에게 데이터를 전송하지 않고 다음 연결에서 다시 읽어오기를 기다립니다. 이에 비해 Session보다 성능이 훨씬 빠릅니다.
Application 객체가 공개되기 때문에 가장 먼저 해야 할 일은 세션 시뮬레이션 목적을 달성하기 위해 각 사용자가 데이터를 기록할 자신만의 영역을 가질 수 있도록 각 사용자에 대한 공통 영역을 계획하는 것입니다. 현재 두 가지 접근 방식이 있습니다.
1. 서버가 활성화될 때 사용자 메모리 공간을 미리 초기화하고 생성하고 할당합니다. 일반적으로 이 방법은 서버가 시작되자마자 많은 리소스를 차지하지만, 사용자가 매번 할당해야 하는 수고를 덜어줍니다. 미래에는 온라인 상태입니다. 하지만 이 방법은 활성화되자마자 초기화되기 때문에 제한이 있습니다. 채팅방 같은 것 말이죠.
2. 이 방법은 대규모 응용 프로그램에 더 적합하다고 간주되어야 합니다. 이 방법은 동적 할당 방법을 채택하고 사용자가 서버에 처음 연결할 때 사용자에게 리소스 할당을 시작합니다. 이 두 가지 Session 시뮬레이션 방법의 목적은 Session 자원의 소모를 줄이는 것이지만 결국 완전히 대체할 수는 없습니다. 섬기는 사람.
첫 번째 옵션
먼저 첫 번째 솔루션의 구현을 시작합니다. 활성화 중에 애플리케이션이 초기화되므로 Global.asa에서 시작해야 합니다.
초기화가 완료되었는데 어떻게 사용하나요? 계좌 번호, 로그인 시간 등 원래 Session을 사용하여 저장된 데이터를 사용자가 로그인하는 곳에서 생성한 Application 개체로 변경하기만 하면 됩니다.
다음과 같이 코드 코드를 복사합니다.
'사용하지 않는 공간을 찾아보세요
i = 1 애플리케이션(ClientMax)으로
Application(User_Status_ & i) = 0인 경우
'사용자 임시번호
세션(인덱스) = i
'잠금
애플리케이션 애플리케이션.잠금
'사용된 상태로 설정
Application(User_Status_ & i) = 1 '변수 데이터 입력
애플리케이션(User_Account_ & i) = 계정
애플리케이션(User_Logtime_ & i) = 현재()
'터놓다
응용 프로그램.잠금 해제
종료 대상
종료 조건
다음
사용자 관련 변수 데이터를 얻으려면 다음을 수행하십시오.
Response.Write(애플리케이션(User_Account_ & 세션(인덱스))
Session을 사용하지 말라고 되어 있지 않나요? 그렇다면 위 소스코드에는 왜 Session이 여전히 존재하는 걸까요? 앞에서 언급했듯이 이 대안은 세션을 완전히 대체할 수 없습니다. 브라우저가 항상 서버와 온라인 상태인 것은 아닙니다. 그러면 다음 번에 동일한 사람이 연결되어 있는지 어떻게 알 수 있습니까? 이때 우리는 Session에 의존해야 합니다. 우리는 사용자에게 실시간 숫자 집합을 제공합니다. 이 숫자는 은행에 있는 사용자의 변수 공간 수입니다. 열쇠와 열쇠 그 위에 숫자가 있고, 열쇠에 적힌 숫자를 통해 점원이 당신을 당신의 금고로 안내할 것입니다. 이 방법에는 여전히 개선 사항이 있지만 소규모 응용 프로그램에는 충분합니다.
두 번째 옵션
이전 솔루션의 경우 Session을 사용하여 사용자 정의된 숫자가 기록된다고 생각할 수도 있습니다. 숫자에 대해 말하면 Session 개체는 "SessionID" 메서드를 제공합니다. 그렇습니다. 사용 여부에 관계없이 서버는 각 사용자에게 자동으로 번호를 할당하며 이 번호는 Session.SessionID를 사용하여 가져오지 않습니다. 이 번호 매기기는 우리가 직접 작성한 번호 매기기 프로그램을 대체하는 데 사용할 수 있는 작업으로, 많은 노력을 절약하고 더 큰 확장성을 제공합니다. 그러나 기본적으로 위의 첫 번째 솔루션은 인원 수를 제한하는 채팅방과 같은 소규모 애플리케이션과 같은 용도로 사용됩니다. 다음 대안은 대규모 시스템을 위한 것입니다.
초당 수백, 수천, 심지어 수만 명의 방문자가 있는 웹 사이트의 경우 이전 솔루션은 확실히 작동하지 않습니다. 인원수 상한을 10,000으로 설정했다고 가정하면, 서버는 10,000명의 사용자에 대해 10,000개의 영역을 잘라내도록 도와주며, 한 개의 변수가 32바이트를 차지하면 10,000개 이상을 차지하게 됩니다. 320000K(320MB) 이상, 서버 활성화되자마자 너무 많은 쓰레기가 메모리에 채워지고, 전장에 들어가기 전에 성능이 많이 저하될 수밖에 없습니다. 이 작은 숫자를 보지 말고 512MB가 될 것이라고 생각하십시오. 위 수치는 최소 수치를 가정한 수치이며, 메모리를 구성할 때 서버가 얼마나 많은 추가 리소스를 사용할지는 알 수 없으므로 그 이상만 될 것입니다. 따라서 사용자 변수 공간을 동적으로 구성하고, 사용자가 서버에 접속할 때만 영역을 잘라내는 것이 유일한 해결책이다. 이렇게 하면 대용량 메모리를 미리 구성할 필요가 없다.
두 번째 옵션은 구현하기가 비교적 간단합니다. 첫 번째 옵션의 모든 내용을 삭제하세요. Global.asa를 건드릴 필요는 없습니다. 사용자 로그인 위치와 기타 유용한 위치만 변경하면 됩니다.
다음과 같이 코드 코드를 복사합니다.
'LockApplicationApplication.Lock'변수 데이터 입력
애플리케이션(User_Account_ & Session.SessionID) = 계정
Application(User_Logtime_ & Session.SessionID) = Now() '응용 프로그램 잠금 해제.Unlock
사용자 관련 변수 데이터를 얻으려면 다음을 수행하십시오.
다음과 같이 코드 코드를 복사합니다.
Response.Write(애플리케이션(User_Account_ & Session.SessionID))
예전에 세션이 리소스를 많이 소모하므로 사용하지 않으려고 노력하지만 필요할 때는 사용해야 한다는 책을 많이 읽었으며, 그 책에서는 더 이상 적절한 해결책을 가르쳐주지 않았습니다. 이제 세션을 교체하는 방법을 이해했으므로 이를 활용해 보세요! 아마도 늘 고민했던 성능 문제가 많이 개선될 수 있을 것 같아요!