Table of Contents
WebtoB is a commercial web server that targets large-scale professional web services. WebtoB is an enterprise web server that supports a wide range of client needs. WebtoB provides fine tuning functions to optimize the server for any given environment. A well-tuned web server has significant advantages in both efficiency and performance.
This chapter describes the WebtoB tuning items for various environments and those that are important for administrators.
As described earlier, WebtoB has a dedicated process that manages connections with client browsers. This architecture is highly efficient in that a single process, HTH process, manages all task processing, but the process's stability can adversely affect the system performance. An HTH process uses multiple threads and their management can have significant effect on the system performance. Hence, it is important to configure them with care.
In WebtoB, all user connections are managed by and come through the HTH process. The optimal number of connections managed by a single HTH process depends on the operating system. Each operating system has a different limit on the number of connections that a single process can open.
If a large amount of work is assigned to a process, the CPU usage by the process increases and the process itself may overload. Thus, if many simultaneous connections exist, more processes should be used to distribute the workload. Generally, a single HTH process can process 1000 ~ 2000 concurrent users. To process more concurrent users, increase the connection limit (maximum 16384) that a single process can open or increase the HTH item value (max 100) in the NODE section.
When the WebtoB environment file is compiled, WebtoB queries the operating system for the maximum connection per process value. The administrator should use this information and predict simultaneous connections to determine the number of HTH processes to use.
In WebtoB, the HTH process manages a majority of request processing. If WebtoB is used as a standalone, set HTH to the number of server CPU cores for efficiency and also consider the thread configuration options. Note that if HTH is set to a value greater than the number of CPU cores, overload may occur due to context-switching.
If the number of HTHs increases, managing the HTHs becomes a burden and HTH caching may be distributed. Therefore, if the number of concurrent users is not large, using the default value for the HTH item (1) of NODE section is recommended.
Unlike other processes, an HTH process uses multiple threads. The threads must be adjusted carefully to minimize their effect on the system performance.
An HTH process is composed of a selector thread that manages thread communication, and other worker threads.
The following describes each worker thread types.
A worker thread handles most of the tasks related to request processing. It is used mostly to read in request file content for HTML requests. If using SSL, it handles SSL handshake, encryption, decryption, and related tasks. It also performs compression as needed, and other tasks including HTTP authentication. It is best to configure the number of worker threads according to the number of CPU cores instead of using a large value. A worker thread does not block on a request since it is not designated to a request but returns the processing to the selector thread after performing its assigned task (file read, etc.).
A sendfile thread is used to process the sendfile function supported in some OSs. It is usually used to process large request files in the blocking mode. This must be set and used selectively only for large files.
An accesslog thread is used to record logs after HTH processes an HTTP request. If this thread is not used, the selector thread must send a request to WSM to write logs to the AccessLog. It is recommended to use the default setting.
Since thread management overhead incurs when the number of threads increases, it is recommended to use the default setting when the number of concurrent users is not excessive to prevent context-switching between threads. Note that since worker threads are created for an HTH process, care must be taken to keep the total number of worker threads at a tolerable level.
As the number of SSL processing increases, it is common to process most of the requests in SSL. Since SSL processing requires high CPU usage, it is important to use CPU efficiently. WebtoB supports process and thread configuration according to the CPU environment as shown in the following example.
For example, it is assumed that the number of SSL processing is high in the following server environment.
Server OS: IBM AIX
Number of physical CPUs: 8
Number of SMT-THREADING threads per physical CPU: 4
Number of virtual CPUs: 32
For the optimal setting in the previous environment, the administrator can set the HTH process count according to the number of physical CPUs and worker thread count according to the SMT-THREADING thread count per physical CPU.
The number of HTH processes and their threads can be specified in the WebtoB environment file as follows:
*DOMAIN
webtob1
*NODE
webmain
WebtoBDir = "$WEBTOBDIR",
SHMKEY = 69000,
Docroot = "docs/",
AppDir = "ap/",
Port = "5469",
HTH = 8,
IndexName = "index.html",
Logging = "accesslog",
ErrorLog = "errorlog"
*HTH_THREAD
hworker
WorkerThreads = 4
Using the example configuration, WebtoB starts with 8 HTH processes. Each HTH process uses 4 worker threads and the total number of threads is 32. For efficiency and high performance, it is recommended to configure the process and thread counts according to the physical CPU and virtual CPU of the server.
Since each HTH process distributes the tasks according to each process' load, overload does not occur on a single HTH process.
Other web servers include all service routines, such as HTML, CGI, and SSI, in a single process. Thus, when a client connects to a server, a single process provides all requested services by a client. In this architecture, it is advantageous that a single process can handle all user requests. However, the process includes unnecessary functions resulting in overhead. To combat this overhead, WebtoB supports the division of the required services. The following is a simple example.
Assume that a shopping mall website has the following distribution of users.
60% HTML users
20% SERVLET users
10% CGI users
10% SSI users
Users are generally concentrated in one or two services.
For most web servers, the number of process set to service is 100. This number is required when 100 concurrent users access the website.
However, looking at the user distribution, 60% of the processes service HTML, 20% service SERVLET, and only 10% each service CGI and SSI. Since other web server processes contain service routines for all available services, most of the service routines are wasting memory. The inefficiency becomes more apparent when users repeatedly request HTML services.
WebtoB handles this issue in the following way.
WebtoB separates each service and enables to set the number of processes per service. HTML, the most common service, is handled by an HTH worker thread while other services, such as CGI and SSI, are each assigned to an independent process. Instead of using a single process, each service type is processed separately to allow adjusting the process count for each type.
In the previous example, if it is assessed that there are many CGI application users, the administrator can increase the process count for CGI and reduce those for other processes to prevent resource waste. In this case, WebtoB can be configured with 6 HTH worker threads, 2 SERVLET processes, 1 CGI process, and 1 SSI process.
These settings can be configured in the SERVER Section's MinProc and MaxProc items in the WebtoB configuration file. Refer to "3.7. SERVER Section" for more information.
The following is an example of the SERVER section configuration.
*SERVER jsv1 SvgName = jsvg, MinProc = 2, MaxProc = 10 cgi SvgName = cgig, MinProc = 1, MaxProc = 10 ssi SvgName = ssig, MinProc = 1, MaxProc = 2
| Item | Description |
|---|---|
| MinProc | The number of processes created when WebtoB starts. Specify the initial values in the above cases as follows:
|
| MaxProc | Specifies the maximum number of processes. MaxProc allows for dynamic modification of WebtoB. |
Once WebtoB is initialized, the number of processes can be adjusted in the range between MinProc and MaxProc. MinProc cannot have a value greater than MaxProc. Configure in the wsadmin management tool.
Server process information can be checked by executing the
st-p command in the wsadmin environment as follows.
$ wsadmin> st -p information HTH 0(12689): RDY --------------------------------------------------------------------------- svr_name svgname spr_no(pid) status count avg(rt) clid svc --------------------------------------------------------------------------- html htmlg 0( 12690) BRUN 0 0.0000( 6) 0 htm
The previous example shows a BRUN status. The BRUN (Blocked Run) status indicates that the server process has not responded to HTH and has momentarily stopped. A server process usually goes into the BRUN state when a client's response speed is slow, when processing a large response, or if the network is slow.
Although a user may determine that the service failed because the server process is in the BRUN status, BRUN does not mean the service failed. If BRUN occurs frequently, it is likely that other requests are being queued.
The tuning points for BRUN, which can be called a type of service delay, are HttpOutBufSize and FlowControl. Through these two settings, BRUN occurrences can be reduced.
BRUN does not occur during HTML processing. For HTML processing, the worker thread reads in ReadBufSize units, sends the data to the selector thread, and the selector thread initiates a flow control to send the response. Hence, the worker thread does not block.
The following is an example of HttpOutBufSize and FlowControl configurations set to reduce BRUN occurrences.
*SERVER
cgis SvgName = cgig, MinProc = 5, MaxProc = 10,
HttpOutbufSize = 4096, FlowControl = 50
HttpOutBufSize (default value: 8192 bytes) is the buffer size used when a server process creates a response and sends it to HTH.
For example, when CGIS processes a 1024KB response, the response is divided into 256 (1024KB / 4KB) pieces of HttpOutBufSize (4KB) size and are sent to HTH. Instead of processing the entire response at once, each piece is sent in a 4KB buffer one at a time.
Therefore, the HttpOutBufSize configuration includes the size of the response sent to HTH as well as the number of data pieces to send if the response size exceeds HttpOutBufSize.
Note that for JSV servers, response transmission must be configured on the server and HTH only uses the setting for creating a FlowControl buffer.
HTH receives a response from the server process into the FlowControl buffer, whose size is (HttpOutBufSize * FlowControl), and sends it to the client. Hence, the FlowControl must be configured by adjusting the HttpOutBufSize value and FlowControl size (default value: 50).
If the client is slow to receive the response, the FlowControl buffer may become full and HTH stops reading data from HTMLS since it can no longer receive response from the server process. As a result, BRUN occurs and processing is temporarily suspended until the client receives the response data and the FlowControl buffer becomes half empty at which point HTH resumes reading data from HTMLS.
Increasing the HTH FlowControl buffer size also increases the memory usage by HTH. For example, HTH can use as much data as the FlowControl buffer size (default 200KB = 4k * 50) per request, and the memory usage increases proportionally to the number of requests.
To reduce the number of BRUN occurrences, adjust the FlowControl buffer size with the FlowControl and HttpOutBufSize settings.
The following is an example of changing the HttpOutBufSize and FlowControl settings when processing many 1MB files.
*SERVER
cgis SvgName = cgig, MinProc = 5, MaxProc = 10,
HttpOutbufSize = 8192, FlowControl = 100
Note that as HttpOutBufSize and FlowControl increase, the maximum amount of memory used by HTH can also increase.
Before version 4.1.5, the HttpOutBufSize configuration set the file size that HTH cached. If HttpOutBufSize is set to a larger value, the amount of memory that HTH uses as cache also increases.