Table of Contents
This chapter describes the basic structure, fundamentals, key features, admin tools, and environment variables of WebtoB.
WebtoB is structurally different from conventional web servers. Conventional web servers, such as Apache, have NCSA’s httpd structure. The httpd structure was designed to support only a moderate number of clients. The httpd structure lacks the flexibility to support a large growth in the number of clients.
Coping with a large increase in the number of users was considered a priority in designing WebtoB.
Conventional web servers generate a process for each request from a client. As the number of clients increases, the number of server processes or threads must also increases. The server can quickly overload from the number of clients.
Overload is not a new problem. Traditionally, it was solved with additional memory and CPUs. Rather than purchasing additional hardware to handle this growth, a better and more cost effective solution is required. The server must be flexible enough to support the increase in clients without interrupting its service in order to survive in the ever growing Web environment.
For WebtoB, the first priority in design was providing scalability to support growth in the number of clients. Comparing the structure of conventional web servers with WebtoB, one can understand why WebtoB is the solution for solving scalability problems.
The structure of Apache was inherited from httpd. httpd is the oldest web server and has a Process per Request type structure. This mechanism generates a process whenever a user request is received. As the number of users increases, the number of processes also increases. Once the number of users grows beyond the server's capability, the server overloads. The server overloads because of the limited number of processes that are available in each system and the increase in memory usage.
These shortcomings led to the development of commercial web servers with scalability for supporting the rapidly expanding web environment. The most commonly used technology is Multi-Threading. The Multi-Threading technology uses a thread, which has far less overhead than a process, to service a user request. Threading shows far superior performance than a process. Moreover, multiple threads can be allocated in a process, which leads to less overhead and requires less memory than process-based structures.
Nonetheless, multi-threading has problems of its own. Even though multi-threading is the superior technology, competing threads often result in deadlocks, affecting the stability of service. If a deadlock occurs in a thread structure, a thread cannot continue its service and may crash the entire system. This is a critical problem for a web server where performance and stability are vital.
The two previously described structures each have their strengths and weaknesses. They are polar opposites in relation to performance and stability. However, both performance and stability is essential to a web server because they directly affect the quality of service provided to the end user.
TmaxSoft has done extensive research in web server structures to satisfy both the performance and stability requirements when developing WebtoB. WebtoB employs the process-based structure for stability and the thread-based structure for performance. To improve performance, each process is designated to a specific task instead of creating independent processes, and task-specific threads are used for some specific processes. Each process is also provided with a secondary process for added stability.
The following are descriptions of WebtoB's major processes.
Also known as a client handler. It is a mediator between the client and the server's task-processing process. HTH communicates with the server process to control data flow. It takes a service request from the client and processes the request. Once the result is ready, HTH retrieves the result and relays it to the client. HTH uses a high performance thread model that minimizes locking. The role of each thread is as follows:
| Thread Type | Description |
|---|---|
| ACCESSLOG | Only one ACCESSLOG thread per HTH. Records accesslog after processing a HTTP(S) request. |
| WORKER | Processes HTML requests, SSL, Compression, etc. |
| SENDFILE | Sends a blocking HTML request to the client. |
The features of WebtoB are as follows.
Caching is a feature available in many web servers. Most web servers support disk caching, which retrieves data from external machines and saves the data to the local disk. When clients request this data, the data can be accessed from the local disk instead of the external machine. Known as Proxy, other web servers have this feature and it effectively boosts the performance of the web server.
WebtoB uses caching in a more effective manner. When user sends a request, WebtoB selects resources that are frequently accessed and allocates them in the memory.
Currently, many web service providers use high-end servers with multiple CPUs and gigabytes of memory. Since processing bottlenecks generally come from the CPU, memory is not fully utilized. In fact, only 70-80% of memory is utilized depending on the CPU’s processing power.
Memory Caching in WebtoB improves performance by utilizing the unused vacant memory to cache frequently used resources. Because the data transfer rate of memory is 40-60% faster than disk, memory caching can result in significant performance enhancement. Memory cache sizes can be adjusted based on available free memory.
In addition, research results show that most user requests target specific sets of resources. Thus, even small memory caching can result in a significant performance boost.
WBAPI is a set of multi-purpose internal functions provided by WebtoB
WBAPI can convert existing CGI applications. Although CGI application can be easily developed, it is architecturally inefficient. Because of performance issues, CGI application cannot service a large number of users. CGI application based sites experiencing a flood of user requests have problems with service continuity. The CGI application can be redeveloped using a different technology or the hardware can be upgraded to deal with continuity issues.
WebtoB provides a revolutionary WBAPI function that can convert a CGI application into a WebtoB service. The conversion improves CGI applications by providing performance levels similar to Servlets and other script languages. WBAPI can also be used inside WebtoB to call the TP-Monitor’s Service Routine.
When Tmax Service is called by a browser in WebtoB, a request must be in a specific format. This format is the same as a CGI request. However, WebtoB is required in order to configure the request to be recognized as a Tmax service.
For example, a Tmax Service is defined in the "/tmax" directory under WebtoB. Inside that directory, there is a service named service1. service1 can be requested from the browser as follows:
http://www.tmax.co.kr/tmax/service1
Most web servers define a default set of standardized Mime Types. Other data or applications must also be defined in the web server for proper transmission. If a user wants to define a new data type, a corresponding MIME Type must be also defined. WebtoB provides a manager to help define these data types. Also in the manager, data extensions can be modified and new extensions can be defined.
WebtoB provides management tools to manage engine and server processes as follows:
| Management Tool | Description |
|---|---|
| wsadmin | Manages the entire WebtoB system. It provides system information and performs administrative tasks. |
| wscfl | Compiles text-based configuration files to binary format. |
| wsuncfl | Converts compiled binary format files to text-based configuration files. |
| wsmkpw | Generates an authentication file consisting of encrypted user and password information. |
| wsmkppd | Creates a file that contains the passphrase password used to specify "file:<passphrase file path>" in the *SSL.PassPhraseDialog configuration. |
The following table describes the environment variables provided by WebtoB.
"${WEBTOBDIR}/lib" is the location of the WebtoB shared libraries. The path must be added to the following environment variables using the system library path.
The following describes the WebtoB Directory structure.
WebtoB |-- bin |-- lib |-- usrinc |-- ap |-- config |-- path |-- log |-- docs |-- license
Contains executable files (wsm, wscfl, wsracd, wsgst, wsboot, wsdown, etc.)
Contains library files.
Contains API header files.
Contains application files.
Contains WebtoB configuration files.
Where the named pipe for process internal communication in created.
Contains log files.
Contains the HTML documents registered by WebtoB by default.
Contains the WebtoB license file.
WebtoB provides the following functions according to the license type.
| License Type | Description |
|---|---|
| BASE | For use as embedded in JEUS. Only supports a single HTH. In a UNIX/Linux environment, JSVPort is not used since only named pipes can be used to connect to JEUS. |
| STANDARD | One or more HTHs are supported. Can connect to JEUS without limitations and supports most WebtoB functions. |
| ENTERPRISE | Supports the following functions in addition to the STANDARD version.
|