Gary Jones's Blog

Gary Jones's Homepage

Gary Jones joined BEA professional services from Fujitsu-ICL in 1997. After graduating from University, Gary worked on the design of distributed control systems for the Process Control industry. At ICL Gary was a member of the mainframe transaction manager, TPMS, development team. Subsequently moving over to UNIX based development and porting of ICL's Tuxedo based TP Manager. Gary designed ICL's VB toolkit for Tuxedo Workstation and OSI connectivity for Tuxedo.

Since joining BEA, Gary has worked on many projects with Customers from the Government, Telco, Financial and Utility sectors using both Tuxedo and WebLogic products.

Parsing arguments passed to tpsvrinit()

The servopts(5) entry in the Tuxedo reference documentation describes the arguments passed to a server during startup.  Application-specific options can be passed in to a server and processed in tpsvrinit(). Internally Tuxedo uses getopt() to process the arguments. Associated with getopt() are optarg and optind. optarg is used to access the current argument parameter, whilst optind is the current index.

Because Tuxedo has already parsed its arguments prior to calling tpsvrinit(), optind and optarg can be used to correctly access the user defined arguments during successive calls to getopt().

For example, suppose we have a Tuxedo server that has user defined arguments A, T and W and T has a string parameter whilst W has a long parameter. The correct way to process these in tpsvrinit() is as follows:

#if defined(__STDC__) || defined(__cplusplus)
tpsvrinit(int argc, char *argv[])
#else
tpsvrinit(argc, argv)
int argc;
char **argv;
#endif
{
    int c;

    int a_flag;

    int t_flag;

    int w_flag;

    char sval[32];

    long lval;

    a_flag = t_flag = w_flag = 0;

    while ((c = getopt(argc, argv, "AT:W:")) != EOF) {
            switch ((char)c) {

            case 'A':
                a_flag++;

                userlog("A argument: optind = %d", optind);

                break;
            case 'T':
                t_flag++;

                userlog("T argument: optind = %d, optarg = %s", optind, optarg);

                strcpy(sval, optarg);

                break;

            case 'W':
                w_flag++;

                userlog("W argument: optind = %d, optarg = %s", optind, optarg);

                lval = atol(optarg);

                break;            
            default:
                    return(-1);
            }
        }

    /*

    * Do some processing based on arguments and parameters...

    */

    return(0);
}

The purpose of the userlog() statements in the sample code is to show how optind and optarg change as the arguments are processed by getopt().

Also note how we can successfully use an argument letter that is also used by Tuxedo (for example 'A').

Often the reason stated for processing arguments in some other way is that the user wants to also access the Tuxedo arguments, for example to find what the group is. Because there is no guarantee that Tuxedo arguments wont change between releases, this type of information should be retrieved by accessing the MIB. This will be the topic of a future entry.

Using Tuxedo message compression - part 2

The Tests

A simple application consisting of a client and server was set up. Four various sized VIEW32 buffers were created and used. I chose VIEW32 because I wanted to include both string and non-string data and because the size of the buffer is fixed.

Three sets of tests were performed for each of the VIEW32 buffers:

1. Set the server so that it delays for 20 seconds prior to returning the received buffer.

Run two clients.

Whilst the first clients request is being processed the buffer from the second will be observable on the servers message queue.

2. Set the server so that it returns the received buffer immediately.

Run a single client which makes 1000 service calls and time the client using the time command.

3. Set the server so that it returns the received buffer immediately.

Run a single client which makes 10000 service calls and collect full sar(1) statistics during the run.

The tests were repeated for each possible setting of TMCMPLIMIT and TMCMPPRFM as in the following table:

The Results

Here we can see that the average number of bytes placed on the server's message queue decreases for higher compression ratios.

Here we can see that the average time taken to compress a buffer increases as the size of buffer increases and more importantly as the setting for TMCMPPRFM increases. It is also evident that the best results are obtained by simply switching compression on.

During the third series of tests, full sar(1) statistics were gathered.

Subsets of information for the following were extracted from the gathered data:

pswch/s

msg/s

scall/s

These subsets were then analysed and the number of time intervals noted.

The following picture shows the resource usage for VIEW3. The other VIEWs had similar looking results.

Here we can see that the average resource usage decreases as the number of time intervals increases.

We can see that the resource usage increases slightly for the first few compression settings and then reduces. The reason the average resource usage reduces is because the number of time intervals to achieve the desired compression, as specified by TMCMPPRFM, increases.

Conclusions

The best results seem to be obtained by simply switching compression on. In addition, it can also be seen that if it is desirable to select a compression setting using TMCMPPRFM then a setting of 5 is the maximum that should be selected before the number of time intervals becomes too costly.

Using Tuxedo message compression - part 1

Tuxedo provides a transparent compression mechanism which can significantly reduce the size of messages.

In this entry I show how to enable compression whilst in subsequent entries I'll show some interesting results from various tests I've performed.

Selecting Compression for local and remote (via bridge) messages

There are two methods for selecting Compression, either via the application Configuration File ubbconfig(5) or via Environment Variables.

1. Selecting Compression via the Configuration File 

Compression may be selected at the Machine Level by specifying the optional keyword CMPLIMIT as part of the configuration data for each machine in the *MACHINES section. This keyword takes the following form:

CMPLIMIT = string_value1[,string_value2]

Where:

string_value1

Specifies the remote process message threshold at which automatic data compression will take place.

string_value2

Specifies the local process message threshold at which automatic data compression will take place.

Both values must be either a non-negative numeric value or the string "MAXLONG". If CMPLIMIT is not specified in the *MACHINES section it defaults to “MAXLONG,MAXLONG” which means that no message will be compressed whether it is being sent remote or locally. To compress all remote and local messages, regardless of size, CMPLIMIT can be set to “0,0”.

2. Selecting Compression via the Environment

Compression may be selected by setting the Environment variable TMCMPLIMIT. This Environment variable takes the following form:

TMCMPLIMIT = string_value1[,string_value2]

The parameters string_value1 and string_value2 have the same meaning as for CMPLIMIT.

Selecting Compression for Domains 

Compression between domains is enabled via the configuration parameter CMPLIMIT in the *DM_TDOMAIN section of the dmconfig(5) file. The format of this is as follows:

CMPLIMIT = value

where:

value specifies the threshold at which compression starts.

Selecting compression for Workstations

Compression for Workstations is enabled via the -c CLOPT option for the WSL in the ubbconfig(5) file. This takes the following form:

-c value

where:

value specifies the threshold at which compression starts.

Note that for all the various compression options the threshold values are in bytes. The default, in each case, being MAXLONG which means no compression.

Specifying the Compression Factor

As well as specifying the threshold values at which compression takes place, individual compression levels may be specified by setting the Environment variable TMCMPPRFM. This variable takes the following form:

TMCMPPRFM = n

where:

n is an integer in the range 1 to 9.

Higher values result in higher compression but take longer.

An informational ULOG message is written when a process reads TMCMPPRFM.

March 2008

Search this blog:

Archives

March 2008

Categories

Recent Entries

Parsing arguments passed to tpsvrinit()

Using Tuxedo message compression - part 2

Using Tuxedo message compression - part 1