1. ASP 캐싱이란 무엇이며 왜 캐시해야 합니까? ASP 기술을 사용하여 웹 사이트를 처음 구축할 때 ASP 동적 웹 페이지 기술이 제공하는 편리함과 자유로운 수정 및 무료 http 제어를 느낄 수 있습니다. 그러나 방문 횟수가 증가함에 따라 사이트 액세스 속도가 점점 느려지고 IIS가 점점 더 자주 다시 시작된다는 것을 확실히 알게 될 것입니다. 다음으로, 더 나은 성능으로 데이터베이스를 교체하고, 인덱스를 생성하고, 저장 프로시저를 작성하는 등 ASP를 최적화해야 합니다. 이러한 조치 중 일부에는 증가된 비용 압박이 필요하지 않지만 다른 조치에는 상당한 비용 압박(예: SQL에 대한 클러스터링 액세스)이 필요하며 그 효과가 반드시 확실하지는 않습니다.
웹 액세스 압박에 직면했을 때 가장 경제적인 방법은 캐시 최적화 기술을 사용하여 웹 서비스 압박을 완화하는 것이라고 생각합니다.
웹 트래픽 증가는 종종 다음 리소스에 대한 수요의 급격한 증가를 의미합니다.
1. 네트워크 카드 트래픽이 증가하면 네트워크 트래픽과 네트워크 I/O 스레드를 처리하기 위해 더 많은 CPU가 필요합니다.
2. 데이터베이스 연결을 더 자주 열고 닫아야 하는 필요성(데이터베이스 기술이 사용되는 경우 - 일반적으로 ASP는 데이터베이스를 데이터 저장소로 사용함), 리소스를 심각하게 소비하는 항목의 수, 리소스를 놓고 경쟁하는 트랜잭션으로 인해 발생하는 교착 상태로 인해 네트워크 I/O가 증가합니다. O 또는 CPU 소비.
3. 세션을 사용하면 IIS는 상태를 유지하기 위해 더 많은 메모리를 소비하게 되며, 메모리 소비로 인해 물리적 메모리가 부족해 물리적 메모리와 보조 메모리 간의 빈번한 교환이 발생하여 코드 실행이 일시 중지되고 웹 응답이 차단될 수 있습니다. .
4. 접속에 대한 적시 대응이 부족하여 웹 페이지 접속 실패로 인해 사용자가 새로고침을 하게 되어 CPU, 메모리 등 자원 수요가 가중됩니다.
실제로 일반적인 웹 애플리케이션을 고려하면 동적 코드 실행이 불필요한 경우가 많습니다.
2. ASP 캐시의 분류는 승인 없이 요약할 수 있으며 두 가지 범주로 나눌 수 있습니다.
1. 파일 캐싱. 소위 파일 캐싱은 특정 ASP의 특정 실행이 일정 기간 내에 크게 변경되지 않을 것이라는 논리적 판단에 기초합니다. 따라서 콘텐츠는 정적 HTML 형식으로 저장됩니다. 웹 리디렉션 기술은 고객이 정적 파일에 대한 엔드 투 엔드 액세스를 허용하여 CPU, 데이터베이스 리소스 등의 필요성을 줄이는 데 사용됩니다. 예를 들어, donews.com 포럼과 같이 많은 포럼에서는 게시물에 응답할 때 전체 게시물을 정적 파일로 다시 생성한 다음 리디렉션합니다. 정적이라는 부작용(이점)도 있습니다. Google과 같은 검색 엔진에서 쉽게 색인을 생성할 수 있습니다. 일부 소위 보도 자료 시스템에서는 이 기술을 채택했습니다.
2. 파일 조각 캐싱. 소위 파일 캐싱도 논리적 판단에 기반을 두고 있기 때문에 일반적으로 리소스를 소비하는 대용량 데이터베이스를 쿼리하여 얻은 데이터는 일정 기간 내에 변경되지 않습니다. 이러한 데이터를 파일 형식으로 저장할 수 있으며, 필요한 경우 데이터베이스에 대한 부담을 늘리지 않도록 파일을 읽어 데이터를 얻을 수 있습니다. 예를 들어, 우리는 일반적으로 일부 데이터를 XML 형식으로 저장한 다음 다음을 사용합니다. 이것이 CSDN 포럼이 처리되는 방식입니다.
3. 메인 메모리 캐시 또한, 메모리에 캐싱하여 시기적절한 응답이 필요한 콘텐츠를 메모리에 저장하고, 액세스가 필요한 경우 빠른 저장소에서 즉시 전송하는 것도 고려할 수 있습니다. 매우 많은 수의 액세스 요구 사항이 몇 개의 작은 페이지에 집중되어 있거나 메인 메모리가 충분히 큰 경우 메인 메모리 캐싱을 사용하면 확실히 웹 액세스 성능을 크게 향상시킬 수 있다고 생각합니다.
3. 캐시 구현/사용 방법 캐시를 구현하려면 다음 사항을 고려해야 합니다.
1. 단기간에 변하지 않는 페이지는 무엇입니까?
자신의 사이트를 분석해 보세요. 그러한 페이지가 많이 있습니다. 예를 들어, 웹 사이트에는 일반적으로 뉴스 및 정보 열이 있으며, 이러한 열은 일반적으로 하루 중 특정 시간에 사이트 관리자가 게시하며 그 이후에는 페이지가 거의 변경되지 않습니다. 그러면 이러한 페이지는 정적 파일 캐싱에 적합합니다. 실제로 이것이 소위 뉴스 릴리스 시스템이 수행하는 작업이므로 이러한 시스템의 아이디어를 참조하여 원래의 동적 ASP 페이지를 변환할 수도 있습니다.
2. 해당 페이지는 모든 방문자에 대해 동일한 논리를 사용하여 생성됩니다(즉, 방문자가 구별되지 않습니다).
모든 방문자가 동일한 인터페이스를 보는 뉴스 및 정보와 같은 열 외에도 포럼과 같은 리소스 소비 애플리케이션은 일반적으로 통일된 논리를 생성하도록 설계될 수 있습니다(동일한 게시물은 3명이 동일하게 볼 수 있음). 이러한 애플리케이션 페이지는 정적 캐싱을 사용하여 달성할 수도 있습니다. 또한 데이터를 조각화하고 스크립팅 기술을 사용하여 서버, 즉 클라이언트 브라우저의 처리 기능 이상으로 데이터를 처리하는 것을 고려할 수도 있습니다.
3. 캐싱 사용에 따른 비용 및 이점.
가장 중요한 것은 "(응답) 시간을 위한 공간"입니다. 캐싱 기술을 사용하여 향후 자주 필요한 콘텐츠를 전처리하여 웹 서버의 응답성을 향상시키고, 더 중요하게는 방문자의 호감을 얻습니다.
그 대가는 웹 공간에 대한 수요가 증가하는 동시에 접근 효과에 영향을 미칠 수 있다는 것입니다.
하지만 적절한 캐싱에는 단점보다 장점이 더 많다고 생각합니다.
4. 이러한 장소는 동적 쿼리 페이지를 캐싱하는 데 적합하지 않습니다. 모든 사람의 쿼리 내용이 다르기 때문에 표시 결과가 다르기 때문에 캐싱이 더 복잡해지고 캐시 활용률이 낮습니다. 관리 문제가 발생합니다. (1,000개의 쿼리 키워드를 캐시한다고 가정하면 이러한 키워드와 캐시 간의 대응 관계를 관리하는 것도 번거롭습니다.)
4. 분석 예시 제안 포럼의 원래 레이아웃은 다음과 같다고 가정합니다.
루트 디렉터리 아래:
default.asp 홈페이지, 일반적으로 하이라이트, 권장 사항 등
listBorad.asp 이 파일에는 모든 열의 이름과 소개가 나열되어 있습니다. 매개변수 MainBID가 있으면 해당 섹션 아래의 열이 나열된다는 의미입니다.
listThread.asp 이 파일에 매개변수가 없으면 모든 게시물을 나열한다는 의미이고, MainBID가 있으면 특정 블록의 모든 게시물을 나열한다는 의미입니다. subBID가 붙으면 특정 열에 게시물이 나열된다는 의미입니다. page 매개변수가 전달되면 주제가 페이지 단위로 나열됩니다.
ViewThread.asp는 게시물의 내용을 나열합니다. 게시물이 댓글로 표시되고 모든 댓글이 마지막에 나열된다고 가정합니다. ID 매개변수는 표시할 게시물입니다.
Reply.asp는 특정 게시물에 응답하고 특정 게시물에 응답하기 위해 매개변수 Id를 전달합니다.
위에서 보면 원본 ASP/PHP를 사용하여 모든 작업을 수행한다면 거의 모든 asp 파일을 실행하려면 데이터베이스 작업, 빈번한 쿼리 및 다중 테이블 쿼리가 필요하다는 것을 알 수 있습니다. 데이터베이스에 쿼리하면 결국 성능과 응답 속도가 저하되어 방문자의 탐색 속도가 느려지고 웹 품질에 도움이 되지 않는다는 점을 알아야 합니다. 더 중요한 것은 A와 B라는 두 사람이 ViewThread.asp 등에 액세스하면 ID가 동일하면 동일한 콘텐츠를 여러 번 보게 된다는 것입니다(브라우저에서 수신한 HTML 코드는 거의 동일), 그러나 이 "동일한 콘텐츠"의 경우 서버는 데이터베이스 연결 열기, 쿼리, 레코드 읽기, 표시, 레코드 닫기 및 데이터베이스 연결을 수행해야 합니다. . . . 서버 리소스를 소비하는 다음 작업에 더 많은 사람들이 액세스하면 최종 결과는 이러한 사람들이 서버 리소스를 더 많이 소비하게 됩니다. 실제로 "동일한 콘텐츠"에 대한 이러한 반복적인 노력은 최적화를 위한 캐싱 기술을 사용하면 피할 수 있습니다. 예를 들어:
reply.asp에 콘텐츠를 제출한 후 즉시 정적 함수를 호출하고 전체 게시물 콘텐츠를 viewThread_xxxx.htm과 같은 정적 html 파일로 저장합니다. 일반적인 상황에서 viewThread.asp?ID=xxxx에 액세스하면 시스템이 자동으로 리디렉션됩니다. 해당 정적 파일 viewThreadxxxx.htm에 추가합니다. 이러한 방식으로 게시물에 최신 릴리스가 없으면 항상 시청자에게 정적 콘텐츠가 제공됩니다. 새 제출물이 있으면 정적 파일로 업데이트되므로 많은 데이터베이스 작업이 저장됩니다. 그리고 응답 속도가 크게 향상됩니다.
listBorad.asp는 정적으로 구현될 수도 있습니다. 전달할 수 있는 매개변수를 분석하고, 캐시 파일 이름을 listBoard_xx.htm으로 설정하고, 새 열을 추가할 때 listBoard_xxx.htm을 업데이트할 수 있습니다. listThread.asp는 매개변수가 더 많기 때문에 캐시 파일이 많다는 점을 제외하면 유사합니다. listThread.asp? subBID=xxx&page=2를 캐시하려는 경우 해당 정적 파일은 listThread_xxx_p2.htm입니다. default.asp도 마찬가지입니다.
그렇다면 언제 업데이트해야 하는지 어떻게 알 수 있나요? 언제 업데이트되나요?
listThread.asp? subBID=xxx&page=2에 대해 논의하면 listThread.asp 실행 시 subID와 페이지를 추출한 후 listThread_xxx_p2.htm이 존재하는지 여부를 감지하여 파일을 생성하고 최종적으로 리디렉션합니다. 여기에 정적 파일이 있습니다. 여기에 없다는 것은 업데이트해야 할 새로운 콘텐츠가 있다는 것을 의미합니다.
그렇다면 파일이 존재하지 않게 만드는 방법은 무엇입니까? 삭제. 새 게시물을 게시하거나 게시물을 삭제하거나 게시물을 이동할 때 listThread_xxx_p2.htm과 같은 모든 정적 파일을 삭제할 수 있습니다. 이는 캐시할 시기를 알려줍니다.
이제 한 가지 질문이 남았습니다. 정적 파일을 생성하는 방법은 무엇입니까?
앞에서 언급한 "동일한 내용"에 주목합니다. 변환 전에 default_d.asp, listThread_2.asp라는 이름의 default.asp, listThread.asp 등의 복사본을 동일한 디렉터리에 만들 수 있습니다(이론적으로 listThtrad.asp?subID=123은 LISTtHREAD_D.ASP와 동일함). ? SUBID=123의 접속 결과는 내용이 동일하므로 정적 파일을 생성해야 하는 로직에서는 WEB 접속 요청을 통해 변환 전 복사본을 호출하여 html 코드를 얻어 정적 파일로 저장합니다. 이 웹 요청은 실제로 실제 브라우저가 정적 콘텐츠에 액세스하기 전에 출력될 HTML을 서버 자체에서 본 다음 이러한 코드를 반환하고 파일 작업 기능을 사용하여 정적 파일로 저장하는 것과 같습니다. 이렇게 하면 실제 뷰어보다 먼저 캐시 파일이 생성됩니다.
이러한 솔루션은 원래 레이아웃을 거의 건드리지 않으며 수정으로 인해 404와 같은 오류가 발생하는 경우도 거의 없습니다. 둘째, 정적 파일은 Google과 같은 검색 엔진에서 귀하의 사이트를 쉽게 색인화하는 데 도움이 됩니다. 왜 안 돼?
마지막으로, ASP 프로그래밍 환경에서는 웹 액세스를 통해 많은 사람들이 xmlHTTP 구성 요소를 사용하여 액세스하므로 많은 문제가 발생한다는 점을 상기시켜 드립니다. xmlhttp 자체는 요청된 리소스를 캐시하므로 이 구성 요소를 통해 요청하는 콘텐츠가 최신이 아니게 되어 논리적 혼란을 야기합니다. 따라서 웹 요청 리소스를 구현하려면 xml Server http 개체 또는 winhttp 구성 요소를 선택해야 합니다.
ASP에서 캐싱 기술을 사용하면 웹 사이트 성능이 크게 향상될 수 있습니다. 실제로 이러한 구현 방법은 서버에서 캐싱이 작동하는 방식과 ADO 연결 기술을 사용하는 방법을 설명합니다.
이러한 기술을 소개하기 전에 ASP 캐싱 기술이 정확히 무엇인지부터 설명하겠습니다.
소위 캐시는 실제로 데이터를 저장하기 위해 메모리에 공간을 열어주는 것입니다. 캐시를 사용하면 하드 디스크에 저장한 데이터에 자주 액세스할 필요가 없으므로 캐시를 유연하게 사용할 수 있습니다. 빈약한 하드디스크가 가득 차는 것을 보는 괴로움이 데이터를 읽는 데 괴로움을 줍니다. 쿼리를 실행하고 쿼리 결과를 캐시에 저장하면 데이터에 반복적으로 빠르게 액세스할 수 있습니다. 그리고 데이터를 캐시에 넣지 않으면 쿼리를 다시 실행할 때 서버는 데이터베이스에서 데이터를 가져오고 정렬하는 프로세스를 소비하게 됩니다.
데이터가 캐시에 저장될 때 다시 쿼리할 때 소요되는 시간은 주로 데이터를 표시하는 데 소요되는 시간입니다.
즉, 자주 변경되어야 하는 데이터를 서버의 캐시에 넣어서는 안 되며, 변경이 적지만 자주 액세스해야 하는 데이터를 캐시에 넣어야 합니다.
이제 ASP가 서버측에서 캐싱 기술을 사용하는 방법에 대해 설명하고 ASP가 클라이언트측에서 캐싱 기술을 사용하는 방법에 대해 설명합니다.
클라이언트에 표시해야 하는 많은 양의 데이터(정적, 즉 변경이 적은)가 있는 경우 서버 측 캐싱 기술 사용을 고려할 수 있습니다. 이 기술은 특히 디스플레이 스타일 일관성이 강한 웹사이트에 적합합니다. (하하, 비주류 웹사이트에서는 사용하기 쉽지 않습니다.)
실제로 구현 방법은 매우 간단합니다. 이해하려면 아래의 간단한 예만 보면 됩니다.
이것은 책 카테고리를 표시하는 예제 프로그램입니다.
DisplayBooks.ASP 파일:
< %@ LANGUAGE=JavaS
스크립트 % >
<html>
<본문>
<양식 방법=게시물>
도서 분류; < %= getBooksListBox() % >
<p>
< 입력 유형=제출 >
<%
함수 getBooksListBox()
{
BooksListBox = 애플리케이션("BooksListBox")
if (BooksListBox != null) return BooksListBox;
crlf = String.fromCharCode(13, 10)
BooksListBox = “< 이름 선택=책>” + crlf;
SQL = "* FROM Books 또는DER BY 이름을 선택하세요.";
cnnBooks = Server.CreateObject("ADODB.Connection");
cnnBooks.Open("도서", "관리자","");
rstBooks = cnnBooks.Execute(SQL);
fldBookName = rstBooks("책이름");
동안 (!rstBooks.EOF){
BooksListBox = BooksListBox + ” <옵션>” +
fldBookName + "" + crlf;
rstBooks.MoveNext();
}
BooksListBox = BooksListBox + ""
Application("BooksListBox") = BooksListBox
BooksListBox를 반환합니다.
}
%>
실제로 매우 간단한 응용 기술을 사용하며 차이점은 단 한 문장입니다.
Application("BooksListBox") = BooksListBox
확인해 보면 서버의 요청 수가 많이 줄어드는 것을 확인할 수 있습니다. 이 상황은 자주 업데이트되지 않는 웹 사이트 콘텐츠에 특히 적합합니다. 예를 들어 하루에 한 번(또는 오랫동안)만 업데이트합니다.
다음으로 클라이언트 측 캐싱 기술에 대해 설명하겠습니다. 이 기술은 연결 끊김 ADO 연결 기술이라고도 합니다(변환 수준이 너무 낮아서 왜 어색하게 들리나요?). 이 기술은 주로 사용자 비밀번호, 코드명 등 사용자의 개인정보를 저장하는 데 사용됩니다. 주로 ADO의 일부 속성을 사용합니다. 동시에 일부 네티즌들이 ADO 개체를 Applocation에서 사용할 수 있는지에 대해 언급한 질문에 대한 답변도 제공합니다. 설명이 명확하지 않습니다. 코드에서 설명하도록 하세요.
파일 GLOBAL.ASA:
< !–메타데이터 유형=”TypeLib” FILE=”C:Program FilesCommon
파일시스템adomsado15.dll”–>
< SCRIPT LANGUAGE=VBScript RUNAT=”서버” >
하위 애플리케이션_OnStart
SQL = "UserInfo에서 사용자 이름, 비밀번호 선택"
cnnUsers = “DSN=사용자”
rsUsers = Server.CreateObject("ADODB.Recordset") 설정
'다음 두 문장은 사용 가능한 연결 해제라는 ADO 기술을 구현하는 데 사용됩니다.
rsCustomers.CursorLocation = adUseClient
rsCustomers.Open SQL, cnnAdvWorks, adOpenStatic, AdLockReadOnly
' 데이터베이스에서 RecordSet 연결을 끊습니다.
rsCustomers.ActiveConnection = 없음
Application("rsCustomers") = rsCustomers 설정
서브 끝
파일사용자.ASP
<%
'Clone 메소드를 사용하면 각 사용자가 자신의 RecordSet 컬렉션을 가질 수 있습니다.
yourUsers = Application("rsUsers").Clone으로 설정하세요.
UserName = yourUsers("UserName") 설정
비밀번호 설정 = yourUsers("비밀번호")
yourUsers.EOF까지 수행
%>
사용자 이름: < %= UserName % > 사용자 비밀번호: < %= 비밀번호 % >
<%
yourUsers.MoveNext
고리
%>