초기의 웹 서버는 httpd의 구조를 그대로 계승했기 때문에 가장 일반적인 Process per Request 형태를 취하고 있다. 즉, 사용자 Request마다 프로세스가 발생해서 처리하는 구조이다. 따라서 앞에서 언급한 대로 사용자가 증가하면 프로세스도 같이 비례하여 증가하게 되므로, 사용자 수가 일정 수 이상이 되면 서비스에 많은 무리가 생긴다. 이는 각 시스템마다 프로세스의 수가 한정되어 있고, 프로세스가 증가하면 너무 많은 메모리를 차지하는 등의 Overhead도 함께 증가하기 때문이다.

이로 인하여 새로운 상용 웹 서버들이 등장하면서 급속도로 확장하고 있는 웹 환경에 대처하기 위하여 새로운 구조를 채택하였다. 가장 일반적인 것이 Multi Thread 기술을 이용한 것이다. 이는 프로세스보다 Overhead가 적은 Thread를 사용하여 서비스하는 것으로 기존 프로세스 방식에 비해 월등히 좋은 성능을 나타냈다. Thread는 프로세스 내부에서 여러 개를 동시에 이용할 수 있기 때문에 Overhead도 적고, 차지하는 메모리도 프로세스 방식에 비하여 상당히 적기 때문이다.

그러나 이러한 방식도 문제를 가지고 있다. Thread 기술이 상당히 우수한 기술임에는 틀림없지만 내부에서 자신들 간의 영역 다툼으로 인하여 DeadLock 등의 문제가 빈번하게 발생하기 때문이다. 이것은 특히 안정성에 있어 치명적이다. Thread 구조에서 DeadLock이 발생하면 자체 Thread가 서비스를 수행하지 못함은 물론, 자칫하면 전체 시스템이 다운되어 서비스 불능 상태가 될 수 있다. 이는 성능뿐 아니라 안정성도 중요한 요소가 되는 웹 서버에 치명적인 결함이 될 수 있다.

위에서 언급한 2가지 방식은 서로 장단점이 있다. 성능과 안정성 면에서 서로 양극단을 달리고 있다고 보면 될 정도로 차이가 있다. 하지만, 성능과 안정성 모두 웹 서버에게 있어서는 놓쳐서는 안될 아주 중요한 고려 사항이다. 둘 중의 하나만 충족되지 않아도 원만한 서비스가 되지 않기 때문이다.

TmaxSoft에서는 WebtoB를 개발하면서 성능과 안정성을 모두 충족시키기 위하여 많은 구조를 검토하고 연구하였다. WebtoB에서는 안정성을 위하여 프로세스 구조를 채택함과 동시에 성능을 위해 스레드 구조를 접목하였다. 안정 및 성능을 위해 각 프로세스를 독립적으로 만들지 않고 각각의 특별한 기능을 하는 프로세스를 두어 역할을 분담하고, 특정 프로세스의 경우 특별한 기능을 하는 스레드를 두어 역할 을 분담하였다. 또한 각 프로세스마다 만약의 경우를 대비하여 여분의 보조 프로세스를 두는 것을 가능하게 하여 안정성에 치중하였다.

다음은 WebtoB의 주요 프로세스와 스레드에 대한 설명이다.

일반적으로 많은 웹 서버들이 캐싱 기능을 제공하고 있다. 그러나 이들은 대부분 디스크에 대한 캐싱으로서 필요한 데이터들을 다른 머신에서 자신의 머신으로 가져와서 디스크에 저장해 두고, 사용자가 Request를 하면 이를 보내 주는 방법이다. 주로 Proxy라는 개념으로 많이 이용되는 다른 웹 서버도 역시 이 기능을 가지고 있으며, 이는 성능 향상에 많은 도움을 준다.

WebtoB에서의 캐싱은 사용자가 Request를 보내면 WebtoB가 자주 이용되는 리소스들을 선별하여 이를 메모리에 상주시켜 놓는 시스템이다.

현재 웹 서비스를 하고 있는 많은 회사들은 상당히 고가의 장비를 이용한다. 이들은 대부분 막강한 능력의 CPU를 여러 개 탑재하고 있으며, 또한 수십 GB에 이르는 엄청난 양의 메모리를 가지고 있다. 그러나 실제 서비스를 시행하게 되면 CPU의 처리 능력에 의해 성능의 제약이 오고, 메모리를 효율적으로 이용하지 못하는 경우가 많게 된다. 즉, 대부분의 경우 메모리의 모든 영역을 쓰지는 못하고, CPU의 처리 능력에 의해서 메모리의 70~80% 정도만 이용하는 실정이다.

이에 WebtoB에서 제공하는 메모리 캐싱 기능은 이 여분의 메모리에 자주 이용되는 리소스들을 미리 상주시켜 두어 성능 향상을 돕는다. 보통 디스크에 비해서 메모리가 약 수십 배 가량 처리 속도가 빠르기 때문에 이것을 적절히 활용하면 대단히 큰 성능 향상을 가져온다. 또한 저장 용량을 임의로 조정할 수 있어 메모리가 부족한 경우 이를 줄일 수 있으며, 만약 여분의 메모리가 충분하다면 이 크기를 더 늘일 수 있다.

실제 연구 결과를 보면 사용자 Request의 대부분이 특정한 리소스에 몰려 있게 된다. 따라서 작은 용량의 메모리 캐싱이라 할지라도 이들을 이용하게 되면 엄청난 성능 향상을 보일 수 있게 된다.

WebtoB는 WBAPI라는 내부 함수를 제공한다. 이는 WebtoB에서만 제공하는 것으로 다양한 용도로 적용될 수 있다. 우선 기존 CGI 프로그램들을 변환하는 데 이용할 수 있다. 기존 CGI 프로그램은 상당히 비효율적으로 설계되어 있고 구현은 간단하지만 성능 면에서 워낙 문제가 많기 때문에 사용자가 많은 곳에 적용하기는 힘들었다. 기존 사이트 중 CGI 프로그램으로 애플리케이션을 개발하고 서비스를 하는 중 갑자기 사용자가 늘어나는 경우에는 본래 이용하던 CGI 프로그램으로는 감당하기 힘들게 되는 경우가 많이 있다. 이 경우 현재까지의 해결 방법은 CGI 프로그램과 같은 기능을 하는 다른 애플리케이션을 완전히 새로 개발하거나 하드웨어를 무한정 늘리는 것 외에는 다른 방법이 없었다.

WebtoB에서는 WBAPI를 제공하여 기존 CGI 프로그램을 WebtoB의 서비스 형태로 변환하는 것을 가능하게 한다. 이는 기존 CGI 프로그램의 단점을 모두 개선한 형태로 현재 많이 이용되는 Servlet이나 기타 다른 스크립트 언어 등과 같은 성능을 제공한다. 이는 또한 WebtoB에서 TP-Monitor의 서비스 루틴을 호출하는 데 이용되기도 한다.

브라우저에서 WebtoB로 Tmax 서비스를 호출하게 되면 WebtoB에서 정해진 형태의 Request를 보내게 되는데, 일반적인 형태는 CGI Request와 거의 같다고 보면 된다. 다만 사전에 WebtoB 내에서 특정 Request가 들어오면 Tmax 서비스로 인식한다는 설정만 하면 된다.

예를 들면 WebtoB 내의 "/tmax" 디렉터리에 Tmax 서비스가 존재한다고 가정하고 여기에 service1이라는 서비스가 존재한다면 브라우저에서는 다음과 같은 형태의 Request를 보내면 된다.

http://www.tmax.co.kr/tmax/service1

일반적으로 웹 서버가 기본적으로 제공하는 MIME-Type은 정해져 있다. 이들은 거의 표준화되어서 특정 데이터나 프로그램들이 전송되어져야 할 필요가 있을 때 이에 대한 정의가 웹 서버 내에서 이루어져야 한다. 따라서 사용자가 새로운 형태의 데이터형을 생성해서 사용하고 싶다면 새로운 MIME-Type을 만들어야 한다. WebtoB에서는 이러한 데이터형을 관리자가 정의하여 제공할 수 있다.

또한 자신이 원하는 데이터의 Extension(확장자)를 임의로 설정이 가능하여 사용자 자신만의 Extension을 생성할 수 있다.

다른 웹 서버에서 제공하는 대부분의 Log Format을 만들 수 있다. 또한 사용자가 원하는 형식으로 조정이 가능하다.