test

Sun Java System Web Server 6.1 SP9 Performance Tuning, Sizing, and Scaling Guide

Chapter 3 Miscellaneous Performance Topics

This chapter provides miscellaneous performance information and includes the following topics:

Miscellaneous magnus.conf Directives

The following topics discuss magnus.conf directives you can use to configure your server to function more effectively:

Buffer Size

You can specify the size of the send buffer (SndBufSize) and the receiving buffer (RcvBufSize) at the server’s sockets. For more information regarding these buffers, see your UNIX/Linux documentation.

Tuning

You can set the buffer size by:

Connection Timeout

You can specify the number of seconds the server waits for data to arrive from the client before closing the connection by using theAcceptTimeout directive. If data does not arrive before the timeout expires, the connection is closed. This is set to 30 seconds by default. Under most circumstances, you won’t need to change this setting. You can free up threads by setting this to less than the default, but you might also disconnect users with slower connections.

Tuning

You can set AcceptTimeout by:

CGIStub Processes (UNIX/Linux)

You can adjust the CGIStub parameters on UNIX/Linux systems. In Sun Java System Web Server, the CGI engine creates CGIStub processes as needed. On systems that serve a large load and rely heavily on CGI-generated content, it is possible for the CGIStub processes to consume all system resources. If this is happening on your server, the CGIStub processes can be tuned to restrict how many new CGIStub processes can be spawned, their timeout value, and the minimum number of CGIStub processes that will be running at any given moment.

Note –

If you have an init-cgi function in the magnus.conf file and you are running in multi-process mode, you must add LateInit = yes to the init-cgi line.

The four directives and their defaults that can be tuned to control Cgistub are:

Tuning

You can set the CGIStub processes by:

Miscellaneous obj.conf Parameters

You can use some obj.conf function parameters to improve your server’s performance, as discussed in the topics in this section:

find-pathinfo-forward

The parameter find-pathinfo-forward for the PathCheck function find-pathinfo and the NameTrans functions pfx2dir and assign-name can help you improve your performance. The find-pathinfo-forward parameter instructs the server to search forward for PATH_INFO in the path after ntrans-base, instead of backward from the end of path in the server function find-pathinfo.

Note –

The server ignores the find-pathinfo-forward parameter if the ntrans-base parameter is not set in rq-\>vars when the server function find-pathinfo is called. By default, ntrans-base is set.

Example 

NameTrans fn="pfx2dir" find-pathinfo-forward="" from="/cgi-bin" 
dir="/export/home/cgi-bin" name="cgi"

NameTrans fn="assign-name" from="/perf" find-pathinfo-forward="" 
name="perf"

This feature can improve performance for certain URLs by doing fewer stats in the server function find-pathinfo. On Windows, you can also use this feature to prevent the server from changing "\" to "/" when using the PathCheck server function find-pathinfo.

nostat

You can specify the parameter nostat in the NameTrans function assign-name to prevent the server from doing a stat on a specified URL whenever possible. Use the following syntax:

nostat=virtual-path

Example 

<Object name=default>NameTrans fn="assign-name" from="/nsfc"
nostat="/nsfc" name="nsfc"</Object>
<Object name=nsfc>Service fn=service-nsfc-dump</Object>

In the previous example, the server does not stat for path /ntrans-base/nsfc and /ntrans-base/nsfc/* if ntrans-base is set. If ntrans-base is not set, the server does not stat for URLs /nsfc and /nsfc/*. By default, ntrans-base is set. The example assumes the default PathCheck server functions are used.

When you use nostat= virtual-path in the assign-name NameTrans, the server assumes that stat on the specified virtual-path will fail. Therefore, use nostat only when the path of the virtual-path does not exist on the system, for example, in NSAPI plugin URLs. Using nostat on those URLs improves performance by avoiding unnecessary stats on those URLs.

Using Quality of Service

The quality of service features allow you to limit the amount of bandwidth and number of connections for a server instance, class of virtual servers, or an individual virtual server. You can set these performance limits, track them, and optionally enforce them.

For more information about using the quality of service features, see the Sun Java System Web Server 6.1 SP9 Administrator’s Guide.

Using Load Balancing

With load balancing, the amount of server traffic is divided between two or more computers so that more work gets done in the same amount of time and all online users will generally be served faster. Third-party plugins can be used to provide load balancing capabilities for Sun Java System Web Server. Contact load balancing plugin providers for information about solutions that work with Sun Java System Web Server.

Using libloadbal

You can use the load balancing plugin libloadbal to allow your server to execute a program when certain thread load conditions are met, so a load distribution product on the front-end can redistribute the load.

There are two methods that you can use to trigger the load balancer to increase or decrease load:

Library configuration

To enable the plugin, you must modify magnus.conf manually. This should look something like this:

Init fn="load-modules" funcs="init-resonate"
shlib="server_root/bin/https/lib/libloadbal.so"
Init fn="init-resonate" ThreadPool="sleep" 
EventExePath="/tools/ns/bin/perl5" LateInit="yes" 
CmdLow="/opt/SUNWwbsvr/plugins/loadbal/CmdLow.pl" 
CmdHigh="/opt/SUNWwbsvr/plugins/loadbal/CmdHigh.pl"

The init-resonate function can take the following parameters:

Table 3–1 init-resonate Parameters

Parameter  

Description  

ThreadPool

Name of the thread pool to monitor. 

Aggressive

If set to TRUE, this argument causes the plugin to use the pool thread count rather than the queue thread count.

PollTime

How frequently to check the thread status. The default is 2000 milliseconds. 

HighThreshold

Defines the queue size/# of threads where HighCmd is executed to increase load on the server. The default is 4096.

LowThreshold

Defines the queue size/# of threads where the LowCmd is executed to decrease load on the server. The default is 1.

EventExePath

Pointer to the script program you want to run (for instance, /usr/bin/perl or /bin/sh). Defaults to perl or perl.exe, depending on the platform.

CmdLow

Pointer to the script to be run when the LowThreshold is met.

ArgsLow

Arguments to send to CmdLow.

CmdHigh

Pointer to the script to be run when the HighThreshold is met.

ArgsHigh

Arguments to send to CmdHigh.

Note –

You must specify LateInit="yes" when loading this module. The module creates a monitoring thread, and this monitoring thread must start after ns-httpd has started.

If you set LogVerbose on in magnus.conf, the error log contains information on how the plugin is configured and when it is invoked.

A sample of the information in the error log is shown below:

[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin watching 
thread pool sleep
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin 
aggressive setting is FALSE
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin poll time 
set to 2000
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin 
HighThreshold set to 5
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin 
LowThreshold set to 1
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin event 
executable path set to /tools/ns/bin/perl5
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin low 
command set to /opt/SUNWwbsvr/plugins/loadbal/CmdLow.pl
[12/Jun/2003:09:36:35] verbose (20685): Resonate plugin high 
command set to /opt/SUNWwbsvr/plugins/loadbal/CmdHigh.pl

This is what the log entries will look like when LogVerbose on is set and the plugin is activated:

[12/Jun/2003:09:40:12] verbose (20699): Resonate plugin reducing load.
 [12/Jun/2003:09:40:14] verbose (20699): Resonate plugin reducing load.
 [12/Jun/2003:09:40:16] verbose (20699): Resonate plugin reducing load.
 [12/Jun/2003:09:40:18] verbose (20699): Resonate plugin reducing load.
 [12/Jun/2003:09:40:20] verbose (20699): Resonate plugin reducing load.
 [12/Jun/2003:09:40:30] verbose (20699): Resonate plugin increasing load.

Testing

To test the load balancer, you can create an NSAPI plugin that prints an HTML page and then calls sleep() for a period to simulate execution time. This way you can build up a simulated load on the server and ensure that the load balancer commands are working properly.

ProcedureTo configure the sample program

  1. Add a new mime.type so this isn't run for every request by modifying config/mime.types and adding:

    type=magnus-internal/sleep exts=sleep

  2. Create a file in your document root directory with the extension of .sleep.

    It does not matter if anything is in this file; it is used only as a placeholder.

  3. Load the module into the server by editing magnus.conf.

    Init fn="load-modules" funcs="dosleep" shlib="/opt/SUNWwbsvr/plugins/nsapi/examples/dosleep.so" pool="sleep"

    In the example above, you are changing shlib to the location of the library, and setting pool to the name of the thread pool you defined earlier.

  4. Add this Service line where the others are found (note that order is not important):

    Service method="(GET|HEAD)" fn="dosleep" duration="10" type="magnus-internal/sleep"

    The argument duration tells the server how long to sleep for each request in seconds.

  5. Restart your server.

    You should now be ready to test the load balancer plugin. The NSAPI plugin will keep the threads busy long enough to simulate your desired load. The load balancing plugin is tested by retrieving the .sleep file you created earlier.

Sample

Below is a sample dosleep.c:

#ifdef XP_WIN32
#define NSAPI_PUBLIC __declspec(dllexport)
#else /* !XP_WIN32 */
#define NSAPI_PUBLIC
#endif /* !XP_WIN32 */

#include "nsapi.h"

#define BUFFER_SIZE 1024

#ifdef __cplusplus
extern "C"
#endif
NSAPI_PUBLIC int dosleep(pblock *pb, Session *sn, Request *rq)
{
    char buf[BUFFER_SIZE];
    int length, duration;
    char *dur = pblock_findval("duration", pb);

    if (!dur) {
        log_error(LOG_WARN, "dosleep", sn, rq, "Value for duration 
                  is not set.");

        return REQ_ABORTED;
    }

    duration = atoi(dur);

    /* We need to get rid of the internal content type. */
    param_free(pblock_remove("content-type", rq->srvhdrs));
    pblock_nvinsert("content-type", "text/html", rq>srvhdrs);

    protocol_status(sn, rq, PROTOCOL_OK, NULL);

    /* get ready to send page */
    protocol_start_response(sn, rq);

    /* fill the buffer with our message */
    length = util_snprintf(buf, BUFFER_SIZE, 
"<title>%s</title><h1>%s</h1>\n", "Sleeping", "Sleeping");
    length += util_snprintf(&buf[length], BUFFER_SIZE - length, 
"Sample NSAPI that is sleeping for %d seconds...\n", duration);

    /* write the message to the client */
    if (net_write(sn->csd, buf, length) == IO_ERROR)
    {
        return REQ_EXIT;
    }
    sleep(duration);
    return REQ_PROCEED;
}