|
구분 |
지시어 |
기본값 |
|
|
|
WEB |
HTTP |
Timeout |
300 |
비활성화된 연결에 대하여 얼마나 오랫동안 HTTP 연결을 유지하고 있을지를 설정 |
|
KeepAliveTimeout |
15 |
아파치 프로세스 (또는 쓰레드) 가 클라이언트가 또다른 HTTP 요청을 보내기 전까지 대기해야 하는 시간을 설정 |
||
|
mod-jk |
socket_timeout |
0 |
mod-jkdhk was간 통신채널에서 사용하는 타임아웃, 정해진 시간동안 응답이 없으면 에러를 발생, 0으로 세팅하면 무제한 대기 |
|
|
socket_connect_timeout |
socket_timeout*1000 |
socket_timeout과 같지만 milliseconds 단위로 타임아웃을 설정할 수 있다 |
||
|
socket_keepalive |
FALSE |
웹서버와 WAS 사이에 방화벽이 있는 경우 사용된다. 이 플래그는 운영체제에 비활성화된 커넥션에 대해서 KEEP_ALIVE메세지를 보냄으로써 방화벽이 비활성화된 커넥션을 끊는 것을 방지한다. |
||
|
ping_timeout |
10000 |
Millisecond 단위의 타임아웃값. Cping 커넥션확인의 응답인 CPong 을 기다릴 때 사용된다 |
||
|
reply_timeout |
0 |
WEB에서 WAS가 처리되어 응답이 올때까지 대기시간 |
||
|
connection_pool_timeout |
0 |
mod-jk가 커넥션을 닫기 전에 몇초 동안 Cache의 Inactive소켓을 유지할지 결정하기 위하여 Cache timeout 프로퍼티가 connection_pool_minsize와 같이 사용된다 |
||
|
WAS |
HTTP/AJP |
connectionTimeout |
0 |
요청이 처리 될 때까지 커넥션을 유지하는 시간으로, 기본은 무제한 |
|
keepAliveTimeout |
- |
WAS에서 새로운 요청을 받기 전까지 대기하는 시간, 기본은 connectionTimeout 값을 따라감 |
||
|
session timeout |
30분 |
요청이 들어온 후 새로운 요청이 들어올때까지의 대기시간, 그시간안에 다시 요청이 오면 해당 값은 갱신됨 |
||
|
DB |
querytimeout |
0 |
JDBC 쿼리 타임아웃, 기본값음 제한없음 |
|
|
loginTimeout |
dbms별 확인필요 |
DBMS와 새로운 연결을 생성시 해당 DBMS에 Login 하고 Connection 을 획득할때까지 대기 시간 |
||
|
blocking timeout millis |
30000 |
Millisecond 단위로 커넥션을 가져올 때까지 대기할 수 있는 최대 시간지정 |
||
|
idle timeout minutes |
30분 |
풀에 있는 커넥션 중 사용하지 않는 커넥션에 대해 주기적으로 삭제, 해당 시간동안 사용하지 않은 커넥션을 삭제하며 검사주기는 지정값/2 |
||
|
set tx query timeout |
FALSE |
트랜잭션 타임아웃이 발생하기까지 남아있는 시간을 기준으로 쿼리 타임 아웃을 설정할 것인지를 설정 |
||
|
allocation retry |
0 |
커넥션을 가져올 때 예외가 발생할 때 재시도 횟수를 지정 |
||
|
allocation retry wait millis |
5000 |
연결 할당까지 대기하는 시간 |
||
조금 추가하면
Apache나 JBoss EWS 서버의 Timeout은 두가지 구분해서 보아야 한다.
1. Client의 send 메시지 이후 GET Method가 실제 Apache Listner로 들어오는데 까지의 시간
TCP의 3단계 연결 수립이 성공하면 클라이언트와 아파치서버간에는 TCP세션이 생성되고
브라우져는 GET 으로 URL Data를 전달하기 위해 send 메시지를 보내고 서버는 준비되었다는 의미로 ACK을 보내게 된다.
이때부터 실제 브라우져가 서버로 데이터를 보내는데 예를들어 "GET HTTP 1.1 /index.jsp" 이런 데이터가 전달된다.
웹서버에서는 TCP 연결 수 립 후 ACK를 보내고 난 이후 실제 데이터가 들어오는 동안의 시간을 카운트 한다. 만약 어떠한 이유로 Timeout 시간보다 길게 데이터가 들어오지 않는다면 broken pipe가 발생하고 해당 세션은 파기 된다.
2. Reqeust 처리를 위하여 mod_jk로 전달 후 대기하는 시간
위의 데이터를 전달 받아서 httpd 엔진이 분석 후 static contents는 자신이 처리한다. 이때 파일을 읽거나 전달 하는데 문제가 발생하는경우(이런 경우는 거의 없지만...doc root 가 NAS 인데 NAS통신에 장애가 있거나...등) 또는 dynamic contents를 WAS로 전달 하기 위해 mod_jk proxy모듈로 전달 하고 이에 대한 처리 값이 돌아오는 시간을 카운트 한다.
이경우 WAS가 처리하는 시간이 Timeout 보다 길어지면 broken pipe가 된다.
보통 이런 문제는 WAS가 외부 기관의 인터페이스와 통신하는데 문제가 있거나(실명인증, 포인트조회 등) 내부적으로는 DB에 전달한 쿼리의 수행이 timeout보다 오래 걸리는 등의 원인으로 발생한다.
일반적으로 웹 시스템은 2~3초 사이에 사용자에게 페이지를 표시해야 하므로
Timeout 60 같은 것으 사실 큰 의미는 없다고 보는 사람들이 많다... 사실 정상적으로 동작하는 시스템에서는 그러하다 (대부분의 다른 Timeout도 역시)
다만 이러한 값 들이 영향을 주는 경우가 있는데 장애상황이거나 서버자원이 부족한 경우 등에서 이다.
예를 들어 의미없다고 Timeout 값을 크게 잡고 운영하다가 WAS나 DB, 또는 연계 시스템에 문제가 있어서 응답이 지연되기 시작하면 Timeout이 짧은 시스템의 경우 해당 세션을 날려버리고 새로운 요청을 받아들이지만 (어짜피 처리는 안되지만 안정성 면에서 더 잘 버틴다)
길게 셋팅되어 있다면 요청들이 큐잉되다가 결국은 완전히 Hang 상태로 진행 될 수 있다.
그래서 일반적으로 Timeout 값은 기본 값에서 늘이지도 줄이지도 않는다(장애 발생시 걱정된다고 너무 짧게 잡으면 BI 나 통계시스템같이 오래 걸리는 비지니스가 있는경우 처리가 완료 되기 전에 끊어지는 상황이 될 수 있음)
다만 keepAlive는 사용자에게 좀 더 부드럽게 처리되는 느낌(?)을 주기 위해 사용하기 때문에 그 시간을 5초 수준까지 줄여도 별 문제가 없고(더 줄이려면 차라리 꺼라) 자원 사용량(netstat -an | grep 80 으로 보면)을 보면 값이 큰 경우보다 자원을 덜 소모하므로 운영에 도움이 된다.
댓글