|
Server Grouping 개요
TUXEDO의 Application Server는 실제 Node의 Process가 되며, 이 Application Server안에서 실제 클라이언트의 요청을 수행하는 단위인 1개 이상의 서비스가 동작하게 된다.
이러한 Application Server의 구성은 Tuxedo System Tuning의 중요한 부분을 차지하게 되며, 실제 사용자가 느끼는 서비스 퍼포먼스를 결정하는 중요 요인이 되기도 한다. 즉, 실제 서비스 수행시간 이외의 서비스 대기시간을 최대한 줄임으로 부차적인 서비스 지연을 줄일 수 있다.
또한 TUXEDO Application Server의 효과적 Grouping은 시스템 자원의 효율적 사용과 전체 응용 프로세스의 효율을 최대화 할 수 있다. 즉 프로세스가 사용하는 메모리 리소스의 감소 및 DBMS의 Session감소에 따른 DBMS Load의 감소를 가져온다.
Application Server Grouping 기준
Application Server Grouping의 기준은 절대적일 수는 없다. 각 시스템의 환경 및 상황에 따라 아래의 Guide를 참조하여 반영하여야 한다.
| ▶ |
한 서버 프로세스내에서의 서비스간 호출 금지 (Recursive Call 배제)
- 필요시 서비스 형태 대신 "C 함수" 형태 사용
|
| ▶ |
비슷한 Response Time을 갖는 서비스들을 Grouping
예)
- 1초 이내는 Grouping
- 5초 이상은 다른 서버로 분리
|
| ▶ |
시간이 오래 걸리는 서비스와 Batch성 작업을 하는 서비스는 분리
|
| ▶ |
DB 변경 서비스와 조회 서비스는 분리
- XA를 사용할 경우, 미 사용시 보다 10 ~ 25% Overhead 발생
- 조회성 업무는 Non-XA 사용이 바람직함
|
| ▶ |
TUXEDO 구성 파일의 *GROUP 섹션에서 Group이 분리되는 서비스는 분리
- DB Access하는 서비스와 Access 하지 않는 서비스 분리
- Oracle의 경우 DB User가 다른 경우는 서비스 분리
- 동일한 RM (DBMS)을 접근하는 서비스끼리 동일 Group
|
| ▶ |
수행 빈도수가 극도로 높은 경우의 서비스는 분리
- "$ txrpt < stderr" 수행결과 참조
- 평균수행시간이 1초 이상 되면 SQL문장 Tuning
- (발생건수 * 평균수행시간) 대비 시스템 운영시간을 비교, 서비스별 분석 |
Tuxedo Application Server Grouping 사전 작업 및 분석
| ▶ |
서비스와 서버 프로세스의 수행빈도를 Check.
① 전체 업무를 단계별로 나누어 최소 업무단위까지 전개한다.
최소 업무단위 즉, 서비스들이 하는 작업과 예상 빈도수를 Check한다.
② 관련된 업무와 빈도수를 기준으로 빈번하다고 생각되는 서비스들은 5-10개 정도를 하나의 서버 프로세스로 묶고 나머지 것들은 10~30개 정도를 하나로 묶는다.
- 5~10개의 서비스를 하나의 서버 프로세스로 묶고 몇 개의 프로세스로 복제. (MSSQ 적용 검토)
- 빈도수에 따라 하나의 서비스를 하나의 서버 프로세스로 서비스 수행시간의 길이에 따라서도 평균 수행시간이 짧으면 좀더 여러 개를 하나의 서버로 묶을 수 도 있다.
③ 일정 시간을 두고 많은 클라이언트를 접속시켜 각각의 서비스들을 수행을 시켜 본다.
|
| ▶ |
Test 후의 분석은 아래의 예를 참조
| 서버명 |
서비스명 |
일자 |
수행횟수 |
수행시간 |
| SER2Z0001 |
Z0001103S |
2001-01-28 |
23 |
0.28 |
| SER2Z0001 |
Z0001101S |
2001-01-28 |
4625 |
0.04 |
| SER2Z0001 |
Z0001102S |
2001-01-28 |
10043 |
0.02 |
| SER2Z0001 합계 |
|
|
14691 |
0 |
| SER2Z0002 |
Z0000302S |
2001-01-28 |
14197 |
0.03 |
| SER2Z0002 |
Z0000201A |
2001-01-28 |
44563 |
0 |
| SER2Z0002 합계 |
|
|
58760 |
0 |
| SER2Z0003 |
Z0000103A |
2001-01-28 |
5080 |
0.05 |
| SER2Z0003 |
Z0000101A |
2001-01-28 |
2173 |
0.01 |
| SER2Z0003 |
Z0000102A |
2001-01-28 |
153 |
0.01 |
| SER2Z0003 합계 |
|
|
7406 |
0 |
| SER2ZA001 |
ZA000106A |
2001-01-28 |
36 |
0.08 |
| SER2ZA001 |
ZA000104AS |
2001-01-28 |
1287 |
0.02 |
- 위와 같이 4개의 서버가 10개의 서비스를 수행하는 경우 실제 호출 횟수와 수행시간으로 보면은 1개의 서버로 통합하여 처리하여도 충분히 업무를 처리할 수 있으며, 필요하다면 하나의 Instance를 더 Booting하면 된다.
- 이러한 App Server의 통합과 분리 및 Instance의 조정을 통해 시스템의 자원을 충분히 그리고 효율적으로 사용하도록 구성한다.
|
| ▶ |
수행시간이 오래 걸리는 것과 그렇지 않은 것을 Check
① 먼저 각 서비스의 수행 시간을 "txrpt"로 Check.
② 평균 수행시간이 1초가 넘는 서비스들은 일단 오래 걸리는 것으로 간주하고 각 서비스의 Source에서 SQL문장만을 떼어내어 이것의 시간을 Check해 본다.
이것으로도 비슷한 시간이 나온다면 SQL문장을 Tuning을 해보고, 아니라면 Logic상에서 시간 단축 방법 모색한다.
③ 실제 시간이 오래 걸릴 수 밖에 없는 서비스의 경우는 다른 On-Line 작업에 방해가 되지 않도록 분리한다.
|
| ▶ |
Service Priority로 수행속도 차에 의한 서비스 지연현상을 최소화한다.
|
| ▶ |
WSL 서버의 CLOPT Parameter 조정
① 하나의 Call을 발생시킨 후 다음 Call이 발생되는 것이 짧다면 "-x" Option을 Default 10 이하로 조정하고, 그렇지 않다면 Default 10 이상 으로 한다. (10을 권장)
② Call 다음에 Call이 발생될 최장시간 (접속 후 TUXEDO 서비스를 사용하지 않을 시간)을 잡아 "-T" Option 으로 접속에 대한 Time-out을 준다.
|
|
Tuxedo Application Server Grouping시의 주의사항
|
| ▶ |
Global variable을 각각의 Service에 선언하여 사용하는 경우, 이 변수는 한 Server 내에서 값을 공유하여 사용하게 되므로 이를 주의하여야 한다.
|
| ▶ |
non-XA Service와 XA 사용 Service가 하나의 Server안에 있어서는 안 된다. ( tpsvrinit( ) 과 tpsvrdone( ) 함수를 같이 사용하기 때문 )
|
| ▶ |
어떤 Service내에서 다른 서비스를 호출하는 경우, 그 Service가 같은 Server 내에 묶여서는 안 된다.
|
| ▶ |
서버 Grouping 작업은 시스템 오픈 전 충분한 검증을 거쳐 반영하여야 하며, 시스템 운영 중에도 수시로 분석, 조사하여 지속적으로 재구성 작업을 하여야 한다. | |
