was마다 기본적으로 제공하는 servlet의 이름 및 위치가 정해져있다.
■ was 별 default servlet name
Tomcat : default
Resin : resin-file
Weblogic : FileServlet
WebSphere : SimpleFileServlet
jetty : default
jboss : default
Jeus : WorkerServlet
- jar위치 : ${JEUS_HOME}\lib\system\jeus.jar
-class위치 :
WAS
- [JEUS]WAS별 기본 servlet 2021.03.09
- [MW]미들웨어 구성 시 유의사항 2020.11.05
- [JEUS]WAS의 JDBC연결 설정 시 RAC 구성한다면 고려해야 할 점 2019.04.04
[JEUS]WAS별 기본 servlet
[MW]미들웨어 구성 시 유의사항
1. 웹서버
1.1 KeepAlive
웹 서버와 웹 브라우저가 연결이 되었을 때 KeepAlive 기능이 켜져 있지 않으면, 매번 HTTP 연결을 맺었다 끊었다가 하는 작업을 반복한다.
1.2 KeepAlive Timeout
이 설정은 초 단위로 KeepAlive가 끊기는 시간을 지정, 즉 마지막 연결이 끝난 이후에 다음 연결이 될 때까지 얼마나 기다릴지를 지정함.
2. WAS
2.1 DB Connection Pool 및 Thread Pool 설정
최소 및 최대 값을 동일하게 하는 것이 좋음(Thread Pool, DB Connection Pool 공통), 만약 사용자 수가 갑자기 증가하면 DB Connection Pool의 개수도 증가되어야 하고, 증가할 때 대기 시간이 발생할 확률이 크기 때문(Thread Pool 또한 대기 시간 발생)
DB Connection Pool은 보통 40~50개로 지정하며, Thread Pool은 이보다 10개 정도 더 지정. 이렇게 지정하는 이유는, Thread Pool의 수가 DB Connection Pool의 개수보다 적으면 적은 수만큼의 연결은 필요 없기 때문 (모든 애플리케이션이나 화면이 DB에 접속하는 것은 아님)
그러나 최종적인 DB Connection Pool 과 Thread Pool의 수는 성능 테스트를 통해 결정하여야 함.
2.2 WAS 인스턴스 개수 설정
CPU 소켓당 1인스턴스를 하는 것이 좋음. 여러개의 인스턴스에서 경합을 하면서 CPU를 차지하려고 하기 때문에..
Memory의 경우 Full GC가 발생할 때마다 많은 시간이 소요될 확률이 커지기 때문에 가급적이면 512MB~2GB 사이에서 지정
단독 인스턴스를 구성하여 사용하는 것은 서버에 예기치 못한 상황이 발생했을 때 서비스가 불가능해지므로 되도록 피해야 함. 장비가 한 대여도, 두 개 이상의 인스턴스가 서로 클러스터링하도록 지정하여 사용자의 세션 정보를 공유하도록 하는 것이 좋음.
Thread Pool 과 DB Connection Pool의 개수가 많을때 (통상적으로 100) 또한 인스턴스를 분리하는 것이 좋음.
2.3 Session Timeout 시간 설정
WEB-INF 폴더 하단의 web.xml 파일 통해 설정
해당 설정을 하지 않으면 세션정보를 삭제하지 않으니 필히 할 것.
2.4 GC 설정
GC야 말로 정답이 없음. 반드시 성능 테스트를 통해 최적의 퍼포먼스가 나오는 값을 찾아야 함.
'IT > MiddleWare(WEB WAS)' 카테고리의 다른 글
[WEBTOB]HSTS 설정 (0) | 2020.11.23 |
---|---|
[JEUS]jsper jsp파서 사용 (0) | 2020.11.11 |
[JEUS]JDBC 연결이 되지 않을 시 확인사항 (0) | 2020.10.08 |
[JEUS]servlet 버전 차이에 따른 url slash 결과 차이 (0) | 2020.06.09 |
[WEBTOB]하나의 LISTEN PORT에서 다중의 SSL인증서 적용 (0) | 2020.05.20 |
[JEUS]WAS의 JDBC연결 설정 시 RAC 구성한다면 고려해야 할 점
AP서버에서 WAS의 JDBC Connection이 JDBCConnectionTimeout 발생
현상
DB서버(2대-RAC구성) 재기동 이후 JDBC Connection 시도 시 JDBCConnectionTimeout 발생
원인
1) 비정상 JDBC Connection을 확인하여 제거하는 WAS의 JDBC Connection 설정이 없음
2) DB서버에 대해 RAC 구성이 되어 있지만, 설정의 primary가 크로스로 구성되어 있지 않았음.
AP1 - DB2 , AP2 - DB2 =====TO-BE======> AP1 - DB1 , AP2 - DB2
3) 현상 유발원인 예상 시나리오
1. DB2의 서버 종료
2. AP1, AP2 모두 DB1로 fail-over
3. DB2의 서버 기동
4. DB1의 서버 종료
5. AP1, AP2 에 DB1로의 비정상 연결이 잔재
해결방안
1) WAS에 아래의 설정을 추가하여 비정상 JDBC Connection을 제거 할 수 있도록 함.
※Tmax사의 권고 사항으로 RAC구조의 Datasource 설정을 할 시에는 아래의 설정이 필수
<check-query>SELECT 1 FROM dual</check-query>
-> 어플리케이션이 JDBC 커넥션 요청을 했을 때(getConnection) 특정 select 쿼리를 보내서 커넥션의 상태를 점검(validation)하는 기능이다.
<check-query-period>120000</check-query-period>
-> JDBC 커넥션을 일정 시간마다 체크하여 문제가 있는 커넥션을 닫아준다.
<check-query-timeout>15000</check-query-timeout>
-> check-query를 했을 때 DB 상황에 따라서 JDBC 드라이버가 응답을 못 받고 계속 기다릴 수 있다. 그에 대한 timeout
<non-validation-interval>5000</non-validation-interval>
-> connection 단위로 check-query를 할 때 마지막으로 커넥션을 사용한 시각과 현재 시각과의 차이가 어떤 시간 간격보다 작으면 체크하지 않는다.
<destroy-policy-on-check-query>AllConnections</destroy-policy-on-check-query>
->JDBC 커넥션 유효성 체크가 실패했을 경우 해당 커넥션 풀에 있는 커넥션들을 어떻게 할지 정책을 결정하는 옵션이다.
해당 설정으로 인해 fail-bak이 실패한 모든 커넥션이 종료되고 새로이 커넥션을 맺으면서 문제가 없어짐.
하지만 Tmax에서는 해당 설정을 통한 fail-back을 보장하지 않으며, fail-back이 필요한 경우 재기동을 권고함
2) RAC 설정의 primary를 크로스가 되도록 구성
AP1 - DB1 , AP2 - DB2
'IT > MiddleWare(WEB WAS)' 카테고리의 다른 글
[WEBTOB]크로스도메인 설정 (0) | 2019.07.24 |
---|---|
[JEUS7/WEBTOB]JEUS로그에서 WEBTOB 연결에 대한 Timeout 발생 (0) | 2019.04.08 |
[WEBTOB]큐잉 시 서비스 처리 (0) | 2018.12.19 |
[WEBTOB]BRUN 발생 시 체크사항 (0) | 2018.12.18 |
[JEUS]기동 시 TM로그 관련 Exception (0) | 2018.12.17 |