|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
|
|
Users Guide | Patterns Reference | WebsydianExpress | Search |
Description Library Installing Operation
This page gives some advice and guidelines of how to operate an installed Websydian application on an iSeries server.
In order to optimize the operation and performance of the Websydian application, it must be carefully monitored, and some key statistics must be gathered. Most important, the average CPU time and average clock time for web user requests must be measured on the iSeries server under realistic load stress. Start by configuring the number of data queues to 1 (one).
The Websydian application driver program can e.g. be monitored with the DSPJOB command, option 3. The average CPU time can be found by dividing the total CPU time with the number of requests fired.
The average clock time can be found by response time stopwatch measurement of a series of requests in a web browser. The desktop computer executing the web browser software must be connected to the iSeries web server through a high-bandwidth network in order to minimize network latency to a minimum.
This response time metric will show more than the elapsed processing clock time on the iSeries server since other kinds of processing is done on the desktop computer and the network. For simplicity, this can be ignored in the following calculations.
If execution metrics is not available, some amount of qualified guessing most be done.
Based on these two execution metrics, an appropriate number of data queues can be determined for a Websydian application. It is important to note, that these metrics are highly dependent on the supported functionality of the Websydian application and the usage patterns, so if any one of these changes, the number of data queues might be changed as well.
For a given iSeries server and Websydian application, the approximate maximum number of processed web requests per hour can roughly be calculated by:
Max requests/hour = 3600 seconds/hour Average CPU seconds for request
If the avg. CPU time e.g. is measured to 0.2 seconds, the maximum requests per hour is calculated as 18,000 requests.
The actual maximum number of requests will be somewhat lower than what can be calculated from the above formula since the iSeries need to do other kinds of processing.
The recommended number of queues can roughly be calculated by:
Rec. number of queues = Average clock time for request Average CPU time for request
If the avg. CPU time e.g. is measured to 0.2 seconds and the avg. clock time is measured to 0.8 seconds, the recommended number of queues is 4.
The overhead of excess data queues with associated Websydian dispatcher programs is mostly in terms of occupied disk space, since non-used working storage for non-used processes are simply paged out, if physical memory is reclaimed by other processes on the iSeries server. For this reason it is recommended not to set the number of data queues lower than what can be calculated from the execution metrics, but rather somewhat higher.
This recommendation applies to the iSeries Internet Connection Server.
The configured iSeries web server prestart job parameter should be equal to or higher than the total number of input queues for Websydian applications. If there e.g. simultaneously are a Sales Order application with 5 queues and a Information Request application with 10 queues on the same iSeries server, the prestart job parameter should be set to at least 15.
It is recommended to periodically delete and recreate the Websydian data queues. It is a recommendation that follows an IBM queue management recommendation.
This periodically recreation could e.g. be done once a day along with other daily routines, e.g. backup to tape storage. Consider using the iSeries job scheduler. Refer to the section "PC to iSeries communication software" in chapter 6 of the AllFusion Plex installation guide for an example of how to configure the job scheduler.
The command WSYDDLTQ is used to delete data queues used by Websydian in a specified library. This command should only be used if the data queues are obsolete or the number of data queues are changed.
Otherwise the WSYDCRTQ and WSYDCRTRQ command should be used since these commands will delete the exiting data queues before they are recreated.
The syntax is for the WSYDDLTQ command is:
Delete Websydian dataqueues (WSYDDLTQ) |
|
|---|---|
| Library to find data queues | The name of the library where the queue objects to be removed is stored. |
The command will delete all data queues in the specified library with the name VACANT, all queues prefixed INI and all queues prefixed OUT.
If the data queues are in use by any Websydian Application program, these programs will send a message to the QSYSOPR's message queue and then terminate normally.
Example:
All Websydian data queue objects in the library WEBDTAQ are deleted.
If an instance of the Websydian application program crashes, e.g. during testing and debugging, the data queue will remain occupied by the crashed program. The data queue will not be released, so future requests will be routed to other data queues. If no other data queues are available either because all are blocked or only one exists, the entire web application will be down.
For this reason it is good practice to recreate the data queues if an instance crashes. The WSYDCRTQ and WSYDCRTRQ commands should be used for this purpose since these commands will delete the exiting data queues before they are recreated.
Online documentation - Websydian v6.0