Tuxedo 서비스를 서버 프로세스로 Grouping하는 방안

장점 : - 서버 프로세스당 Memory는 서비스가 많건 적건 일정
       - 프로세스의 수가 적을수록 성능에 영향 
 
1. Grouping 기준
 
1) 한 서버 프로세스내에서 tpcall() 사용 금지
   -> 서비스 형태 대신 “C 함수” 호출은 사용 가능   
 
2) 비슷한 Response Time을 갖는 서비스들은 Grouping
   - 1초 이내는 Grouping하고
   - 5초 이상은 분리
 
3) 시간이 오래 걸리는 서비스와 Batch성 작업을 하는 서비스는 분리
 
4) DB 변경 서비스와 조회 서비스는 분리
   - XA를 사용할 경우, 미사용시 보다 10 ~ 25% Overhead 발생
   - 조회성 업무는 NON-XA 사용이 바람직 함 !
 
5) TUXEDO 구성화일의 *GROUP 섹션에서 Group이 분리되는 서비스는 분리
   - DB를 Access하는 서비스와 Access 하지않는 서비스는 분리
   - ORACLE의 경우 DB User가 다른 경우에는 서비스를 분리
   - 동일한 RM (DBMS)을 접근하는 서비스끼리는 Grouping
 
6) 매우 자주 Call하는 서비스는 분리
  “$ txrpt  <  stderr” 수행결과에서
   - 평균수행시간이 1초 이상되면 SQL문장 Tuning
   - 발생건수 * 평균수행시간 >= 1800 이면 매우 자주 Call하는 서비스
 
 
2. 사전작업과 그에따른 분석
 
1) 서비스와 서버 프로세스의 수행빈도를 Check.

2) 전체 업무를 단계별로 나누어 최소 업무단위까지 전개한다.
   최소 업무단위 즉, 서비스들이 하는 작업과 예상 빈도수를 Check한다.
 
3) 관련된 업무와 빈도수를 기준으로 빈번하다고 생각되는 서비스들은 3~4개 정도를 하나의 서버 프로세스로 묶고 나머지 것들은 10~20개 정도를 하나로 묶는다.
   - 3~4개의 서비스를 하나의 서버 프로세스로 묶고 몇개의 프로세스로 복제.
     -> 이 서버 프로세스들은 빠른 응답시간, 부하조절을 위하여 MSSQ를 사용
   - 빈도수에 따라 하나의 서비스를 하나의 서버 프로세스로 생성
 
4) 일정 시간을 두고 많은 클라이언트를 접속시켜 각각의 서비스들을 수행시켜 본다.
 
5) Test 후의 분석은 다음의 요령을 따른다.
   - “tmadmin”의 “psr” 명령 수행결과 
    a.out Name     Queue Name  Grp Name   ID      RqDone   Load Done     Current Service
    ----------     ----------  --------   --      ------   ---------     ---------------
    BBL            214578      SITE1      0       8        400           ( IDLE )
    TMS_ORACLE7    EMP1_TMS    EMP1       30001   0        0             ( IDLE )
    TMS_ORACLE7    EMP1_TMS    EMP1       30002   3        150           ( IDLE )
    WSL            00101.00020 WSGRP      20      0        0             ( IDLE )
    empmul         00001.00021 EMP1       21      3        150           ( IDLE )
 
   - 여기서 “RqDone”은 서버 프로세스가 수행된 횟수를 나타내는 것으로, 1시간 동안의 수행횟수가 7200번 이상이 되는 것은 빈번하다고 판단되므로 이 경우에는 서버 프로세스를 재구성하거나 여러개를 Booting시켜야 함.
   - 서버 프로세스를 재구성을 할 경우는 “txrpt”의 수행결과 Check.
     SVCNAME                11a-12n         TOTALS
                            Num/Avg         Num/Avg
     ---------------        --------        -------
     SEL                    9/0.09          9/0.09
     ---------------        -------         -------
     TOTALS                 9/0.09          9/0.09
   - 이 화면은 11시에서 12시 사이에 “SEL”이라는 tjqltm가 9번 수행되었고 평균 수행시간이 0.09 라는 것을 나타낸다.
   - 여기서, 발생건수 * 평균수행시간 >= 1800 이면 매우 자주 Call하는 서비스
 
6) 수행시간이 오래 걸리는 것과 그렇지 않은 것을 Check.
   - 첫번째로 하여야 할 작업은 각 서비스의 수행 시간을 “txrpt”로 Check.
   - 평균 수행시간이 1초가 넘는 서비스들은 일단 오래 걸리는 것으로 간주하고 각 서비스의 Source에서 SQL문장만을 떼어내어 이것의 시간을 Check해 본다.
     이것으로도 비슷한 시간이 나온다면 SQL문장을 Tuning을 해보고, 아니라면 Logic상에서 시간 단축 방법을 생각해 본다.
   - 실제로 시간이 오래 걸릴 수 밖에 없는 서비스도 있을 수 있으므로 이런 것들은 다른 on-Line 작업에 방해가 되지 않도록 분리한다.
 
7) WSL 서버의 CLOPT Parameter 조정
   - PC를 켜면 Default로 TUXEDO에 접속하도록 되어 있다면 중간중간 WSH가 기동되는 부하를 줄이기 위해 WSH의 Minimum을 Client 수에 맞춘다 ( “- m” Option ).
     그렇지 않다면 실제 Client수의 50 % 정도로 맞춘다.
   - 하나의 Call을 발생시킨 후 다음 Call이 발생되는 것이 짧다면 “-x” Option을 10 정도로 하고, 그렇지 않다면 20 정도로 한다.
   - Call 다음에 Call이 발생될 최장시간 (접속후 TUXEDO 서비스를 사용하지 않을 시간)을 잡아 “-T” Option으로 접속에 대한 Time-out을 준다.