WebtoB는 특정 프로세스에서 일반 브라우저에 관련된 연결을 모두 관리한다. 이러한 구조는 하나의 프로세스에서 모든 처리를 관리하므로 빠른 작업을 할 수 있는 장점이 있으나 프로세스의 안정성에 의해 시스템의 성능이 크게 좌우되므로 주의해야 할 필요가 있다. HTH라는 프로세스가 바로 이런 역할을 한다. 단, 이 프로세스의 관리가 성능에 영향을 줄 수 있으므로 이를 적당히 조절할 필요가 있다.

WebtoB에서는 HTH 프로세스를 통해서 사용자의 연결을 관리하고 HTH 프로세스에 모든 사용자의 연결이 맺어진다. HTH 프로세스 하나에 몇 개의 연결을 맺는 것이 좋은가는 사용하는 운영체제마다 다르다. 이는 각 운영체제마다 프로세스 하나가 열 수 있는 연결의 수를 제한하고 있기 때문이다.

또한, 하나의 프로세스에서 너무 많은 처리를 하면 많은 CPU 점유를 차지하게 되고, 또 프로세스의 동작에 무리를 줄 수 있기 때문에 동시 사용자가 많은 경우 가급적 적당한 정도로 분리하여 실제 사이트에서 운영한다. 보통 하나의 HTH 프로세스로 1000 ~ 2000의 동시 사용자를 처리하도록 한다. 더 많은 동시 사용자를 처리하고자 하는 경우 프로세스 하나가 열 수 있는 연결 제한(최대 8192)을 더 크게 하거나, NODE 절의 HTH 항목의 설정(최대 20)을 늘려서 사용할 수 있다.

이러한 정보는 WebtoB 환경 파일을 컴파일하면, 화면에 WebtoB가 자체적으로 운영체제에 문의하여 자신이 받아 들일 수 있는 최대의 동시 사용자수를 출력해 준다. 따라서 운영자는 동시 사용자 수의 예측과 이 정보를 바탕으로 HTH 프로세스의 적당한 수를 예측해야 한다.

WebtoB는 HTH 프로세스가 요청 처리의 많은 부분을 관리하기 때문에 운영장비에 WebtoB만 단독으로 사용할 경우 운영장비의 CPU 수만큼 HTH를 설정하는 것이 장비를 최대한 효율적으로 사용할 수 있는 방법이다. CPU 수보다 작게 설정하면 CPU를 최대한 활용하지 못할 것이고, CPU 수보다 크게 설정했을 경우에는 context-switch로 인한 부하가 발생할 수 있기 때문이다.

WebtoB 설정 파일에서 HTH 프로세스의 수를 설정하는 방법은 다음과 같다.

*DOMAIN
webtob1

*NODE
webmain
    WebtoBDir = "$WEBTOBDIR",
    SHMKEY = 69000,
    Docroot = "docs/",
    AppDir = "ap/",
    Port = "5469",
    HTH = 2,
    IndexName = "index.html",
    Logging = "accesslog",
    ErrorLog = "errorlog"

위와 같이 설정하면 WebtoB가 2개의 HTH 프로세스를 기동하게 된다. 따라서 각각의 HTH 프로세스를 이용하여 사용자의 접속을 처리하게 된다. 각각의 HTH 프로세스는 각 프로세스에 걸리는 로드에 따라서 적당히 사용자의 요구를 분배하기 때문에 하나의 HTH 프로세스가 특별히 일을 많이 하는 등의 문제는 발생하지 않는다.

타 웹 서버의 경우 하나의 프로세스에 HTML, CGI, SSI 등의 모든 서비스 처리 루틴이 포함되어 있다. 따라서 사용자가 접속하는 경우 하나의 프로세스에서 모든 처리가 끝난다. 사용자당 담당 프로세스가 연결되는 구조에서는 각 사용자의 요구 순간마다 프로세스가 접속을 연결받아 처리한다. 이런 구조에서는 하나의 프로세스에서 모든 사용자의 Request를 처리할 수 있다는 장점은 있으나, 사용자가 사용하지도 않는 기능들이 의미없이 설정되어 있을 수도 있다. WebtoB는 이에 대해 필요한 서비스들을 분리시켜 제공한다. 다음은 간단한 예이다.

*SERVER
html        SvgName = htmlg, MinProc = 6, MaxProc = 10
jsv1        SvgName = jsvg, MinProc = 2, MaxProc = 10
cgi         SvgName = cgig, MinProc = 1, MaxProc = 10
ssi         SvgName = ssig, MinProc = 1, MaxProc = 2

다음과 같이 wsadmin 환경에서 st -p 명령의 수행을 통해 서버 프로세스의 정보를 확인할 수 있다.

$ wsadmin> st -p 정보

HTH 0(12689): RDY
   --------------------------------------------------------------------------- 
   svr_name   svgname    spr_no(pid)  status     count    avg(rt)  clid svc v
   --------------------------------------------------------------------------- 
   html       htmlg         0( 12690)  BRUN         0   0.0000( 6)    0 htm 0 
 

위와 같이 조회된 정보 중 상태(status)가 'BRUN'인 경우가 있다. BRUN(Blocked Run) 상태는 서버 프로세스가 HTH에게 응답을 보내지 않고 잠시 멈춰있는 상태를 의미한다. 일반적으로 클라이언트가 응답을 받는 속도가 느린 경우에 발생한다. 용량이 큰 파일을 요청하는 경우 또는 모바일 환경과 같이 네트워크 속도가 느린 경우에 발생할 수 있다.

BRUN이 발생하면 서버 프로세스가 Block 상태이기 때문에 사용자는 서비스에 장애가 있다고 판단할 수 있지만, BRUN이 발생한 상황은 서비스의 장애가 아니다. 또한, BRUN이 자주 발생하면 다른 요청에 대한 큐잉(Queuing) 현상이 발생할 가능성이 높아진다.

일종의 서비스 지연 현상이라고 할 수 있는 BRUN 발생에 대한 튜닝 포인트는 HttpOutBufSize 및 FlowControl 설정이다. 이 2가지 설정을 통해 BRUN의 발생 빈도를 줄일 수 있다.

*SERVER
html        SvgName = htmlg, MinProc = 5, MaxProc = 10, 
            HttpOutbufSize = 4096, FlowControl = 50

*SERVER
html        SvgName = htmlg, MinProc = 5, MaxProc = 10, 
            HttpOutbufSize = 8192, FlowControl = 100