Transcript 웹 캐시 관리
OracleAS Web Cache 관리 및 설정 (9.0.4)
목차
설정 및 관리 – – 웹 캐시 관리 관리자 암호 설정 및 리슨 포트 설정 – – – Origin 서버 등록 사이트 정의 등록 사이트-서버 매핑 설정 컨텐트 캐시 컨텐트 부분 캐시(ESI 및 JESI) 액세스 로그 및 이벤트 로그 성능 이슈
목차
설정 및 관리 – – 웹 캐시 관리 관리자 암호 설정 및 리슨 포트 설정 – – – Origin 서버 등록 사이트 정의 등록 사이트-서버 매핑 설정 컨텐트 캐시 – – 캐시 룰 작성 및 설정 무효화 정책 설정 – 만기 정책 설정 컨텐트 부분 캐시(ESI 및 JESI) 액세스 로그 및 이벤트 로그 성능 이슈
웹 캐시 관리 ( 홈페이지 )
간단한 모니터링은 홈페이지에서 가능하나 다양한 설정 변경은 웹 캐시 관리 페이지에서 수행한다.
http://localhost:1810 클릭 시 IE에서는 제대로 동작하지 않으므로 http://host:4000/ 으로 접근하면 된다.
웹 캐시 관리 ( 관리 페이지 )
http://localhost:4000/webcacheadmin
웹 캐시 관리 (opmnctl 을 이용한 관리 )
opmnctl
을 이용해서 웹 캐시 프로세스들을 시작,정지 그리고 재시작 할 수 있다. 일반적으로 UNIX/Linux환경에서는 두개의 프로세스(관리 프로세스+캐시 프로세스)를 관리하게 되나 Windows환경에서는 하나의 프로세스안의 두개의 쓰레드 형태로 운영된다.
$ opmnctl startproc ias-component=WebCache $ opmnctl stopproc ias-component=WebCache $ opmnctl restartproc ias-component=WebCache Stand-alone 웹 캐시 설치시에는
webcachectl
을 이용하여 웹 캐시를 시작, 정지할 수 있다.
$ webcachectl start 이 외에 Oracle Enterprise Management를 이용하여 웹 캐시를 시작, 정지할 수 있다.
보안 설정 변경
① ② ③
리스닝 포트 설정
1024 이하 포트에서 웹 캐시 실행
Unix 환경에서는 처음 설치 후 웹 캐시의 실행파일( webcachectl) 이 1024 이하의 포트에서 바로 수행되 지 못한다. 이를 해결하기 위해 webcachectl 에 1024 이하 포트를 이용할 수 있도록 권한을 준다.
$ opmnctl stopproc ias-component=WebCache $ cd
$ORACLE_HOME
/webcache/bin $ su $
webcache_setuser.sh
setroot
oracle_user
위의 과정을 수행하다 웹 캐시가 “ libnnz9.so 열기 실패 ” 에러를 발생하고 시작이 안 되는 경우가 있다. 이때에는 다음의 작업을 수행해준다. (for Solaris) $ opmnctl stopproc ias-component=WebCache $ cd
$ORACLE_HOME
/webcache/lib/ $ make –f ins_calypso.mk install $ cd
$ORACLE_HOME
/webcache/bin $ su $
webcache_setuser.sh
setroot
oracle_user
Origin 서버 등록
① ②
사이트 정의
애플리케이션 웹 서버
www. 1st. comp.com:80
애플리케이션 웹 서버
www. 2nd. comp.com:80
호스트
1
호스트
2
브라우저 웹 캐시
애플리케이션 웹 서버
www. *. comp.com:80
호스트
3
호스트
4
호스트
5
사이트 정의 설정
① ②
사이트 서버 매핑 설정
① ②
목차
설정 및 관리 컨텐트 캐시 – – – – – 캐시 룰 개요 캐시 룰 작성 및 설정 만기 정책 설정 무효화 정책 설정 캐시 컨텐트 관리 컨텐트 부분 캐시(ESI 및 JESI) 액세스 로그 및 이벤트 로그 성능 이슈
캐시 룰 개요
캐시 룰은 특정 컨텐트 를 캐시 할 것인지 안 할 것인지를 명시하고 어떤 컨텐트를 캐시 할 지 결정하는 규칙이다.
– – 정적 문서 다중 버전 URL – – – – – 개인화된 페이지 세션 트랙킹을 지원하는 페이지 HTTP 에러 메시지 정규식에 규합되는 URL 하나의 문서나 서브 트리를 포함하는 URL 트리 캐시는 우선 순위 룰에 기반한다.(우선 순위 값이 작을 수록 먼저 처리된다) 캐시 룰에 의해 캐시된 컨텐트는 만기 정책과 무효화 정책에 의해서 캐시 내용이 갱신될 수 있도록 한다.
미리 정의된 캐시 룰
캐시 룰 작성 일반
① ②
캐시 룰 작성 캐시 가능성 규칙
① ②
만기 정책 설정
특정 컨텐트가 정해진 시간에 업데이트가 될 경우, 즉 컨텐트의 캐시 타임 아웃 시간이 예상 되는 경우에는 만기 정책을 이용할 수 있다.
① ②
무효화 정책
캐시 일관성을 위한 무효 – OracleAS Web Cache는 고객의 편의를 위해 Java 및 PL/SQL APIs와 함께 출하되어, 개발자 가 무효 로직을 자신의 애플리케이션에 직접 포함시킬 수 있게 되었습니다.
– JSP 개발자를 위하여 무효 프로세스를 좀 더 단순화하기 위해, Oracle JSP는 사용자 정의 태그 라이브러리와 함께 출하되며, 이것은 사용이 간편한
Trigger / Programmatic Programmatic
인터넷 사용자 인터넷
Web Cache OracleAS Manual or Scripted
관리자 데이타베이스
무효화 정책 설정
–
기본 캐시 컨텐트 무효화
① ② ③
무효화 정책 설정
–
고급 캐시 컨텐트 무효화
① ② ③
무효화 정책 설정
–
트리거를 이용한 무효화
1.
2.
PL/SQL 등록 – – $ORACLE_HOME/webcache/toolkit의 wxvutil.sql, wxvappl.sql를 등록한다.
wxvutil.sql : 무효화 HTTP request 만들어 를 보내는 PL/SQL 로직 – wxvappl.sql : wxutil.sql의 wrapper 테이블을 만든다.
CREATE TABLE EMPL (cust_id INTEGER, cust_name CHAR (50), cust_phone CHAR (50)); 3.
트리거를 만든다. (무효화 URL과 Invalidator의 Port, 암호 설정을 체크한다.) / CREATE OR REPLACE TRIGGER UTL_INVALID_TRIG AFTER DELETE OR INSERT OR UPDATE on empl BEGIN wxvutil.invalidate_reset; wxvutil.invalidate_uri('http://www.host.com/cache.htm', 0, null); wxvutil.invalidate_exec('webcache-machine', 4001, 'invalidator-password'); END; 4.
테이블의 데이터를 조작한다.
캐시 컨텐트 관리 자주 요청되는 페이지들
① ②
목차
설정 및 관리 컨텐트 캐시 컨텐트 부분 캐시(ESI 및 JESI) – 컨텐트 부분 캐시란?
– – – – – – ESI 소개 ESI 기본 구조 및 개발 과정 ESI 주요 특징 JESI 소개 JESI 모델 소개(Template/Fragment, Control/Include 모델) JESI 태그 설명 액세스 로그 및 이벤트 로그 성능 이슈
3.7 Caching
컨텐트 부분 캐시
부분 페이지 캐시과 개인화 된 페이지 어셈블리(ESI) – – – – – – 전체 페이지 캐시는 페이지가 각 사용자를 위해 고도로 사용자 정의되었을 경우에는 비효율적입니다.
오라클은 페이지에 대한 부분 캐시 정책과 다양한 만기 정책을 위해서 ESI (Edge Side Includes)라고 불리우는 부분-페이지 캐시 언어를 만들어 내었습니다.
• • 오라클과 Akamai에 의해 고안된 ESI는 W3C Note로 발표된 XML 스타일 스펙입니다.
웹 개발자들은 네트워크 에지에서의 동적 어셈블리를 위해서 컨텐트 단편이라고 불리는 페이지 요소를 식별하는데 있어서 ESI 마크업을 사용할 수 있습니다.
처음으로 혁신적인 ESI 사양을 지원하는 애플리케이션 서버로서, Oracle Application Server는 회사 네트워크 에지(Edge) 및 인터넷 에지 부분에서 부분-페이지 캐시, 개인화 및 동적 컨텐트 어셈블리를 수행하는 능력을 통해 이 분야의 산업을 이끌고 있습니다.
ESI를 이용하게 되면 웹사이트의 컨텐트 생성 메커니즘은 어셈블 및 전달 메커니즘으로부터 분리됩니다. 즉 OracleAS Web Cache는 캐시가 가능하지 않거나 만기된 부분들만 웹 서버로부터 가져와서 자신이 캐시하고 있는 부분들과 조합하여 사용자에게 전달하게 됩니다. 따라서 ESI모델은 전체 페이지를 읽거나 계산할 필요성 을 감소시키고, 웹 사이트 컨텐트 생성 인프라의 로드를 감소시키게 됩니다.
ESI를 통해 얻을 수 있는 혜택 • e-Business는 고도로 개인화 된 웹 기반 애플리케이션을 개발할 수 있으며, 이 애플리케이션은 성능 향 상을 위해 회사의 주 데이타 센터와 원거리 사무실 에지에서 조합 될 수 있고, 또는 공공 인터넷 경계선에 서 조합 될 수 있습니다.
• 에지 서버에서 컨텐트 집합 및 어셈블리를 함으로써, 신속하고 확장 가능하며 내구성을 지닌 애플리케이 션 제공에 드는 인프라 비용을 극적으로 감소시킬 수가 있습니다.
JESI (ESI for JAVA) – JSR 128 • Java 개발자들의 신속한 ESI 수용을 돕기 위해 발표된 스펙입니다.
• • JESI는 ESI 코드 자동 생성을 위해 개발자들이 사용할 수 있는 스펙 및 사용자 정의 JSP 태그 라이브러 리로서, ESI를 사용하여 JSP의 프로그래밍을 촉진시키고 있습니다.
OracleJSP(OracleAS Containers for J2EE의 일부)와 Oracle JDeveloper는 모두 ESI 및 JESI 사용을 지 원하며, 둘 다 JESI 태그 라이브러리와 함께 출하됩니다.
ESI 소개
사용자 브라우저 컨텐트 어셈블리
/
전달
Edge Server Edge Server Edge Server ESI
조각 컨텐트 생성
millions of requests Edge Server Edge Server millions of requests 1000s of requests 1000s of requests
Inexpensive Infrastructure Less Infrastructure Required
ESI는 에지 서버에서의 동적 컨텐트 어셈블리를 위해서 컨텐트 조각이라고 불리는 컨텐트 의 요소를 식별하는 마크업 언어이다.
ESI를 통해 동적 컨텐트에 대해 부분 캐시 정책과 다양한 만기 정책 적용할 수 있다.
ESI 기본 구조 및 개발 과정
ESI의 기본 구조는 하나의 컨텐트 (Template)를 여러 조각(Fragment) 으로 분리하여 그것을 다시 조합하 는 구조를 가집니다.
부분 페이지 캐시를 위한 개발과정 – 전체 페이지를 Templates와 Fragments 로 구성합니다.
– 각 Templates와 Fragments에 대 해 캐시 정책을 세웁니다.
– Web Cache는 Templates와 Fragments로부터 전체 페이지를 통합합니다.
Web Cache 는 자체가 네트웍 ESI (Edge Network) 에 프로세서를 내장하므로 에지 Akamai 와 같은 프로세서를 둘 필요가 없습니다 .
ESI 전용
ESI 주요 특징
포함 지원 – – ESI 프로세서는 동적 컨텐트 조각들을 어셈블한다. 각각의 조각들은 캐시 제어에 관련된 정보를 가진다.
–
JESI 소개
JESI는JSP에서 ESI를 쉽게 표현하기 위해 제공되는 태그 라이브러리이다.
JESI가 제공하는 것들 – – – – JSP 프로그래밍의 편리한 기능을 그대로 이용한다.
편리한 구문과 태그 속성을 지원한다.
애플리케이션 레벨의 속성 파일 사용을 지원한다.
예)무효화 시 사용되는 사용자 이름,패스워드, URL등 미리 지정 개발 모델: – Control / Include 모델 : 새 페이지 구성 시 이용 – Template / Fragment 모델 : 기존 페이지 재구성 시 이용
Control/Include 모델
Control / Include
예제
<%@ taglib uri="/WEB-INF/JESItaglib.tld" prefix= “ JESI" %>
Template/Fragment 모델
Template / Fragment
예제
<%@ taglib uri="/WEB-INF/JESItaglib.tld" prefix="JESI" %>
Control/Include모델에서 JSP페이지들의 캐시 정책을 설정해준다.
JESI:control 태그는 필수사항이 아니다. 없을 시에는 웹 캐시의 기본 캐시 정책을 따른다.
피해야 할 것들: – 한 페이지 내에서 여러 JESI:control 태그 사용 – 같은 페이지에서 JESI:template와 같이 사용 여러 컨텐트 조각을 포함하는 페이지의 JESI:control 태그는 그 페이지에 포함되는 페이지 에는 영향을 주지 않는다.
yes
| no | no-remote ” ] [Control = “ uninterpreted_string ” ] />
JESI:include는 jsp:include 태그와 비슷하게 다른 페이지의 결과를 동적으로 추가하는 태 그이다. 각각의 포함된 페이지는 별개의 캐시 가능한 오브젝트이다.
JESI:param 태그를 포함할 수 있다.
– jsp:include와는 달리 자신을 포함하는 페이지와 별개의 request, response를 사용한다.
false
” ] [copyparam = “ true |
false
” ] [flush = “ true |
false
” ] />
이미 존재하는 JSP 페이지 내에 ESI 템플릿을 정의하기 위해 쓰인다.
시작 태그는 페이지 내에서 어떤 JESI 태그보다 우선해야 하며 다른 HTML이 buffer flush 되기 전에 쓰여져야 한다. 끝 태그는 가장 마지막에 써준다.
JESI:template의 속성은 선택 사항이다. 속성 표시를 하지 않을 경우 웹 캐시의 기본 캐시 정책을 따른다.
한 페이지 내에서 여러 JESI:template는 사용하면 안된다.
JESI:template는 안에 포함된 JESI:fragment에 영향을 주지 않는다.
yes
| no | no-remote ” ] > ...
page content,JESI:fragment tags, JESI:include tags...
JESI:template내에 하나 이상의 JESI:fragment를 정의할 수 있다.
JSP 코드를 여러 개의 조각으로 나뉠 때 사용된다. JESI:fragment는 각각의 캐시 정책을 갖는다.
특정 조각이 요청될 때, ESI 프로세서는 그것을 포함하는 페이지 전체를 요청하지 않고 그 조각만을 애플리케이션 서버에 요청한다.
yes
| no | no-remote ” ] >
… JSP code fragment …
JESI:template내 JESI:fragment 밖에서 정의되어 선택적으로 사용되는 태그이다. 페이지 내의 코드 블록을 조건적으로 수행하기 위해서 사용된다.
– – – Template가 요청될 때만 수행 Any Fragments가 요청될 때만 수행 항상 수행
… Request dependent JSP content …
|
쿠키 정보를 통해서 페이지를 개인화 하기 위한 태그이다. Example: –
캐시된 객체들을 무효화 하고자 하기 위해 사용하는 태그 JESI:object - 무효화할 객체를 명시해준다.
JESI:cookie, JESI:header - 특정 쿠기값과 헤더값에 따라 다중버전으로 캐시된 객체를 무 효화한다.
subtags
• 필수 사항
“ no
”
]
[maxRemovalDelay = “ value ” ] />
• 선택 사항
Page Invalidation
...
...
Sample Application
main.jsp
"); %>
hi~"+name); %>
fragment
template
invalidate.jsp
목차
설정 및 관리 컨텐트 캐시 컨텐트 부분 캐시(ESI 및 JESI) 액세스 로그 및 이벤트 로그 – – 엑세스 로그 관리 이벤트 로그 관리 성능 이슈
액세스 로그 관리 (1)
① ③ ②
액세스 로그 관리 (2)
③ ④ ⑤
이벤트 로그 관리
① ③ ②
목차
설정 및 관리 컨텐트 캐시 컨텐트 부분 캐시(ESI 및 JESI) 액세스 로그 및 이벤트 로그 성능 이슈 – – – – – – CPU 및 메모리 네트웍 커넥션 유닉스 환경에서의 커넥션 설정 네트웍 관련 파라미터 설정 캐시 히트율 기타 이슈
CPU 및 메모리
CPU – 웹 캐시의 성능 향상은 CPU의 개수보다는 CPU의 속도에 큰 영향을 받는다.
– 웹 캐시의 캐시 서버는 Request 받는 부분과 Request 처리하는 부분으로 나뉘기 때문에 2개의 CPU구성이 최적이다.
– 결론적으로 OracleAS Web Cache를 가장 효율적으로 배치하는 방법은 빠른 두개의 CPU에 많 은 메모리를 가지는서버에 배치하는 것이다.
– 다시 말해, CPU의 4개인 장비에 Web Cache 두개를 올리는 것보다 CPU 2개인 장비 2대에 각 각 Web Cache를 설치하는게 훨씬 유리하다.
메모리 – 정확한 공식 계산은 환경에 따라 크게 다르나 기본적으로 모든 컨텐트를 메모리에서 캐시하기 때문에 많은 메모리 자원이 활용된다.
네트웍 커넥션
네트웍 동시 커넥션 개수와 응답 시간은 반비례 관계에 있다.
네트웍 커넥션은 다음과 같은 요인들을 고려하여 설정하여야 한다.
1. 최대 클라이언트 수 2. 요청 문서의 평균 사이즈 및 평균 요청 수 3. 네트웍 대역폭 4. 캐시 실패율 5. 클러스터 멤버 용량(다른 캐시 클러스터멤버로부터 들어오는 커넥션 수 설정) netstat -a 로 얼마나 많은 커넥션이 만들어졌는 지 체크, ttcp로 얼마나 빠르게 문서가 처 리되는지 체크한다.
Maximum Incomming Connections은 임의로 높게 설정하면 안된다. 보통 많은 UNIX 시 스템에서는5000을 사용하지만 잘못 설정할 경우 성능에 영향을 미친다.
Unix 환경에서의 커넥션 설정
Max_File_Desc : 설정하고자 하는 File Descriptor의 최대값으로서 이 값에 따라서 커넥션 개수를 설정할 수 있다.
Max_File_Desc = Current_ Max_Conn + Total_WS_Capacity + Outgoing_Cluster_Conn + 100
– Current_ Max_Conn : ( Properties>Resource Limits )에서 설정되는 Maximum Incomming Connections 개수이다. 클러스터 환경에서는 ( Properties>Clustering )에 있는 클러스터 멤버의 용량도 여기에 포함된다. * 클러스터 환경에서 클러스터끼리 통신하는데 캐시 컨텐트를 공유하기 위해 사용되는 커넥션 수 – Total_WS_Capacity : 설정된 모든 WS의 용량 ( 에서 설정된 값. 클러스터 환경에서는 Total_WS_Capacity = Sum_Web_Server_Capacity / n(n: 클러스터 멤버수) Origin Servers, Site, and LB >Origin Servers ) * 클러스터 환경에서 정의된 Origin Server설정은 같기 때문에 결국 Origin Server의 캐시 용량은 캐시 클러스 터 멤버끼리 공유하는 값이므로 n으로 나눠준다.
– Outgoing_Cluster_Conn : 캐시 클러스터에 있는 캐시 멤버들로 나가는 커넥션의 총 개수(캐시 클러스터 환경이 아니면 0) Outgoing_Cluster_Conn = Sum_Cluster_Capacity /(n-1) (n:클러 스터 멤버수) – 100 : Oracle Web Cache가 내부적으로 사용하기 위한 예약된 값
네트웍 관련 파라미터 설정
응답 속도가 느리다면 OracleAS Web Cache와 Web Server의 설정 변경을 통해서 응답 속 도를 향상 시킬 수 있다.
Web Cache – – Keep-Alive Timeout: Web Cache가 브라우저에게 응답을 보낸 후에 커넥션이 열려 있는 시간 을 정의한다. HTTP Client가 Web Cache에 여러개의 요청을 보내을 보낼 경우 Keep-Alive가 필요할 수 있다. 기본값으로는 5s이다. 만약 브라우저와 Web Cache사이의 네트웍 상황이 좋지 않다면 더 늘릴 수 있다. 하지만 이로 인해 Network Incomming Connection의 제약에 걸려 많 은 요청을 처리못하게 될 수도 있으므로 가능한한 기본값으로 설정하는 것이 좋다. (Properties > Network Timeouts)에서 설정한다.
Origin Server Timeout: 애플리케이션 웹 서버가 Web Cache에 응답을 하는데 걸리는 시간이다.
애플리케이션 서버로부터 응답시간이 가장 낮은 문서의 응답시간을 기준으로 설정한다. (Properties > Network Timeouts) Orign Server(OHS) – – KeepAlive: 하나의 클라이언트가 같은 커넥션을 통해서 여러개의 요청을 보낼 수 있다.
KeepAliveTimeout: 같은 클라이언트로 부터의 다음 요청까지 커넥션이 열려 있는 시간 – – – MaxkeepAliveRequests: 하나의 커넥션에 요청 가능한 최대 요청 수 MaxClients: 웹서버에 동시에 연결할 수 있는 최대 클라이언트 수 만약에 KeepAlive가 설정되어 있다면 가능한한 MaxClients를 최대값으로 설정할 필요가 있다.
클라이언트의 요청이 보통 응답시간이 짧다면 MaxClients의 수를 줄이는 것이 좋다.
MaxClients는 보통 Web Cache에서 설정한 Origin Server용량보다는 작아야 한다.
캐시 히트율
캐시 히트율을 높이기 위해 쿠키와 URL 파라미터를 사용한다.
– – – – Web Cache는 같은 URL에 대해서 쿠키나 헤더에 의해서 다양한 버전의 문서를 캐싱한다.
기본적으로 URL 파라미터에 의해 캐싱을 하지만 불필요한 URL파라미터에 의해 같은 문서가 여 러개 캐시될 수도 있다.
이런 점들을 해결하기 위해 불필요한 URL 파라미터는 줄일 필요가 있다.
특정 컨텐트에 개인화된 스트링 몇개를 제외하고 나머지가 같을 경우는 여러 버전으로 중복 캐 시를 하지말고 다른 방법을 찾아햐 한다.
예를 들어, 쿠키와 자바스크립트를 이용한다거나 ESI Personalize tag를 이용한다거나 하면 된 다.
캐시된 문서로 리다이렉션을 사용한다.
– – – 메인 페이지와 같은 문서에서는 주로 세션을 만들어주기 때문에 첫 페이지를 캐시하지 못하는 경우가 많다.
이럴 경우 세션 만들어주는 빈 페이지를 만들어 세션을 성립시켜주고 실제 페이지로 리다이렉 트를 시켜줄 수 있다.
또한 자바스크립트를 통해 실제 페이지에 세션 쿠키를 설정해줄 수 있다.
가능하다면 부분 페이지 캐시를 이용한다.
ESI Variables를 통해서 간단한 개인화된 부분을 보안해줄 수 있다.
기타 이슈
Maximum Incomming Connections 체크 Maximum Cache Size 체크 캐시 클러스터 환경에서 클러스터 멤버의 용량이 적당한지 체크 (너무 적으면 캐시 멤버로부터 컨텐트를 받지 못할 수도 있다.) 네트웍 대역폭 확인 CPU 사용에 관련한 성능 체크(2CPU에 Dedicated 서버로 배치)
별첨
웹 캐시 기타 이슈 및 Trouble Shooting
웹 캐시 클러스터 구성
캐시 컨텐트 공유
L4
공유 설정
Security Auto-restart Application Web servers Proxy servers Site definitions Site to srver mappings Caching rules Error pages Session management
Web Cache 1 Application Servers Web Cache 2
개별 설정
Process identity Network timeouts Resource limits End-User Performance Monitor Event logs Access logs Operations Listener ports Orign server wallet
Trouble Shooting ( 웹 캐시의 Origin 서버 Up/Down 탐지 문제 )
실제 Origin Server가 살아있어도 Down으로 표시되는 경우가 종종 발생한다. 그렇다고 강제로 Origin Server의 상태를 올릴 수는 없다.
<해결 방법> Origin Server에 등록된 ping url이 제대로 되어 있는지 체크한다.
별 문제가 없다면 텔넷을 이용하여 해당 ping url에 직접 요청을 해본다.
$ telnet <host_name>
Connected to dioh-kr.kr.oracle.com.
Escape character is '^]'.
GET ping_url HTTP/1.0
– 500 Internal Server Error가 떨어지는 경우에는 ping url을 다른 것으로 바꿔주기 바란다. (종종 브라우저에서는 제대로 보이나 telnet으로 보는 경우에는 잘 안나오는 경우가 발생한다.) 웹 캐시의 버전이 낮은 경우에 Origin 서버의 Ping URL 체크 시에 GET / HTTP/1.0 하고 난 다음에 \n\n을 붙여서 보내게 되는 경우가 있는데 만일 OC4J가 직접 Origin서버로 등록된 경우에 OC4J는 \r\n\r\n을 받아야 된다고 인식을 하고 있어 문제가 되는 경우가 종종 있다. – – – OHS의 경우에는 \n\n으로 와도 그걸 처리해준다.
이 경우에는 웹 캐시가 잘못 요청을 하는 경우인데 이것은 9.0.3.1 이전 버전의 버그로 등록되어 있다. 이와 같 은 경우에는 버그 패치 및 업그레이드가 필요하다.
사이트 마인더를 쓰는 사이트에서는 사이트 마인더가 ping url을 잡고 웹캐시의 응답에 대한 요청을 잘못 해주 는 경우도 있다. 이럴 때에도 제대로 Origin Server의 up/down을 파악하기가 쉽지 않다. <== 해결과제