Table of contents Change history ............................................................................................................................2 Executive Summary ....................................................................................................................3 Performance Management for JD Edwards EnterpriseOne ....................................................3 General System i Performance ..................................................................................................4 IBM HTTP Server Performance ..................................................................................................5
Measure and Analyze .............................................................................................................................. 6 Adjust ....................................................................................................................................................... 7
1) Minimize the logging in the production environment..................................................... 8 2) Allow unlimited requests per connection..................................................................... 10 3) Set the number of threads for each job....................................................................... 12 4) Enable compression.................................................................................................... 13
WebSphere Application Server Tuning...................................................................................16 Measure and Analyze ............................................................................................................................ 17 Adjust ..................................................................................................................................................... 17
1) Adjust the heap size for the JVM ................................................................................ 18 2) Adjust the number of threads running in the JVM....................................................... 21 3) Adjust WebSphere subsystem settings in i5/OS......................................................... 22
1) Single-threaded kernels in JDE.INI - number of call object kernels............................ 30 2) Multi-threaded kernels in JDE.INI - thread settings and call object kernels ............... 32 3) Maximum users for the JAS server in JAS.INI............................................................ 38 4) JDENET connections for the JAS server in JAS.INI ................................................... 39
DB2 for i5/OS Tuning ................................................................................................................40 Measure and Analyze ............................................................................................................................ 41 Adjust ..................................................................................................................................................... 42
1) Improve database access performance by creating additional indexes ..................... 43 2) Tune the number of database connections for the system......................................... 44 3) Tune the number of database connections for the web client environment ............... 47 4) Optimize the use of SQL Packages ............................................................................ 50 5) Apply any recommended SQL settings....................................................................... 54 6) SQL Server Mode Considerations .............................................................................. 55
TCP/IP Settings .........................................................................................................................56 Appendix A – Software and Hardware Levels ........................................................................57 Appendix B – Configuration Files............................................................................................58 Appendix C – Advanced Performance Tuning .......................................................................74
IBM’s iDoctor for iSeries ........................................................................................................................ 74 Oracle’s Performance Workbench......................................................................................................... 74
Appendix D – Additional Information......................................................................................75
Table of figures Figure 1 - Starting IBM HTTP Server administration for i5/OS from iSeries Navigator .................6 Figure 2 - Real Time Server Statistics show current activity on the HTTP server instance ..........7 Figure 3 - Select the HTTP server instance ..................................................................................8 Figure 4 - Change the error log settings in HTTP server instance................................................9 Figure 5 - Eliminate access logging for the HTTP server instance .............................................10 Figure 6 - Allow unlimited requests per connection for the HTTP server instance......................11 Figure 7 - Set the number of threads to handle requests in the HTTP server instance ..............12 Figure 8 - Enable compression for the HTTP server instance ....................................................14 Figure 9 - Set the output filter for text in the JAS directories.......................................................15 Figure 10 - Set the initial and maximum heap size for the JVM in WebSphere 6.0 ....................19 Figure 11 - Set the initial and maximum heap size for the JVM in WebSphere 6.1 ....................20 Figure 12 - Set the number of threads for the JVM in WebSphere 6.0 .......................................21 Figure 13 - Set the number of threads for the JVM in WebSphere 6.1 .......................................22 Figure 14 - EnterpriseOne JAS SAW system summary screen..................................................25 Figure 15 - EnterpriseOne Enterprise SAW system summary screen ........................................27 Figure 16 - EnterpriseOne green screen Work with Server Processes screen...........................28 Figure 17 - Server Manager Java environment information........................................................29 Figure 18 - Server Manager general kernel definitions ...............................................................31 Figure 19 - Server Manager call object kernel settings...............................................................32 Figure 20 - Server Manager security kernel settings...................................................................32 Figure 21 - Server Manager network kernel settings ..................................................................32 Figure 22 - EnterpriseOne JAS SAW CallObject Info screen......................................................34 Figure 23 - Using the iSeries Navigator to monitor thread usage in call object kernels ..............35 Figure 24 - WRKACTJOB and F11 twice to monitor thread usage in call object kernels............36 Figure 25 - EnterpriseOne Enterprise SAW to monitor thread usage in call object kernels........37 Figure 26 – Server Manager multithreaded call object kernel settings .......................................38 Figure 27 – Server Manager Max Users settings........................................................................39 Figure 28 – Server Manager Pool Size settings..........................................................................40 Figure 29 - System i database connection types ........................................................................41 Figure 30 - Starting the SQL performance monitor through iSeries Navigator............................42 Figure 31 - Sample Index Advisor display...................................................................................43 Figure 32 - Use the DSPACTPJ command for the average and peak number of jobs ...............45 Figure 33 - Use the CHGPJE command to set new values ........................................................46 Figure 34 - F10 and page down for additional values in CHGPJE command.............................47 Figure 35 - JDBj connection pool settings for proxy users ..........................................................49 Figure 36 - JDBj connection pool settings when not using proxy users ......................................49 Figure 37 - Result set timeout settings for Server Manager........................................................50 Figure 38 - SQL Package Library setting with Server Manager ..................................................52 Figure 39 - AS400 Package Library setting with Server Manager ..............................................53 Figure 40 - All in One (AIO) configuration ...................................................................................57 Figure 41 - Virtual Three Tier (V3T) configuration ......................................................................57
Executive Summary The majority of Oracle’s JD Edwards EnterpriseOne customer environments now include web clients implemented using JD Edwards Technology Foundation software. A key component to JD Edwards Technology Foundation is IBM WebSphere® Application Server (WAS). Because there are many options and parameters associated with a JD Edwards EnterpriseOne and WebSphere implementation, IBM and Oracle have worked together to create this document for the JD Edwards and System i™ customers. This document outlines key WebSphere and JD Edwards EnterpriseOne parameters and settings for optimal web client performance and is based on lab tests and customer feedback.
This white paper provides tuning techniques to optimize the performance of JD Edwards EnterpriseOne 8.12 with WebSphere 6.0 on System i. JD Edwards EnterpriseOne is a comprehensive software package that provides Enterprise Resource Planning (ERP), Supply Chain Management (SCM), and Customer Relationship Management (CRM) capabilities using HTML-based user interfaces in a J2EE web server architecture. This updated version of the document includes information on WebSphere 6.1 and considerations for WebSphere Application Server 6.1, the use of SQL Server Mode by Oracle’s JD Edwards EnterpriseOne, and JD Edwards EnterpriseOne Tools 8.97.
The tuning recommendations covered in this document include support for the new enhanced features of multi-threaded call object kernels and XML metadata kernels, general System i performance, HTTP server performance, the WebSphere application server, and the JD Edwards EnterpriseOne application. All components discussed are running on one or more i5/OS partitions.
Note: For JD Edwards EnterpriseOne 8.10, 8.11, and WebSphere 5.0 on System i, see the earlier tuning document. For all platforms other than System i, please refer to “Performance Tuning EnterpriseOne and WebSphere 5.0.2”. Both documents are listed in Appendix D.
Performance Management for JD Edwards EnterpriseOne One crucial factor in achieving optimal system performance is sufficient system resources implemented in a balanced configuration. An optimal system has sufficient processor, memory, disk, and network capacity—individually and in balance with one another—to handle the application workload so that none of these factors is a performance bottleneck. The process of performance management which addresses allocation and balancing of resources is an ongoing, dynamic process. It consists of three key steps:
1. Measure and analyze 2. Adjust 3. Re-measure
For best system performance, these steps should be viewed as a process that is repeated on a regular basis. The results are used to resolve specific performance problems as well as to predict and schedule required system upgrades. Before tuning begins, an environment needs to meet Oracle’s Minimum Technical Requirements (MTRs). The MTR website is listed in Appendix D.
The following sections focus on examining and optimizing the performance of the web server environment on System i running JD Edwards EnterpriseOne 8.12 with IBM WebSphere Application Server 6.0 or 6.1. The information contained in this document originates from lab configurations and test scenarios
executed by a joint team of IBM’s and Oracle’s JD Edwards development and technical professionals. Appendix A lists the specific software levels and hardware used in these tests. The document also contains guidance based on customer feedback received by Oracle and IBM through a variety of channels. Use these recommendations as a starting point and adjust as necessary because every environment is different and actual results will vary. Since the testing environment did not include batch, this document does not specifically address Universal Batch Engine (UBE) performance.
Even an impeccably tuned and sized system can still yield unacceptable performance. The internal design of customized application software may contain flaws which cannot be resolved via system tuning alone. Such code must be analyzed, profiled, and possibly fixed via refactoring or recoding. Note that no amount of hardware or system tuning will fix software which does not scale.
For optimal performance of the JD Edwards EnterpriseOne web server environment on the IBM System i platform, these areas are covered:
General System Performance HTTP Server WebSphere Application Server JD Edwards EnterpriseOne software package DB2® for i5/OS® TCP/IP Settings
General System i Performance General system performance can be managed using just a few i5/OS commands and interfaces. The first is the Work with System Status (WRKSYSSTS) command which provides an effective method of monitoring and managing system resource utilization and job activity. The WRKSYSSTS screen provides high level feedback on the CPU utilization of the i5/OS partition. A low CPU utilization indicates either that the system is not CPU constrained or that some other system or tuning limit is preventing the processor from being fully utilized. A high utilization is not necessarily a concern because most environments include low priority work which will use any processor resources that remain available after higher priority work is satisfied.
For each memory pool, the WRKSYSSTS screen shows the faulting rate for database and non-database objects. Faulting occurs when a program references an object not currently in memory. It does not include planned I/O operations when a program explicitly requests a disk I/O. For example, DB2 support may pre-fetch database data into memory. This is counted as an I/O operation by other tools but it is not counted as a fault. Acceptable faulting rates depend on the workload, the number of disks, the disk adapters being used, etc. Definitive faulting guidelines are beyond the scope of this document but some useful links are included in Appendix D. The general guideline is that faulting rates should be low and memory should be added to pools with high faulting rates by shifting memory from pools with low faulting rates.
WRKSYSSTS also provides data at the system level including total auxiliary storage (disk) used, the total number of jobs in the system, and both the current and maximum amount of unprotected storage in use. These last two values are often the source of confusion. Unprotected in this context corresponds to temporary storage which is “unprotected” in that it is not necessarily protected if the system fails. Because of Single Level Store support provided by i5/OS, the amount of temporary storage may exceed
the total size of system memory. On most operating systems, this would be a source of grave concern while for i5/OS this may be perfectly normal. Although it is recommended that these values be monitored, they do not provide useful data on memory usage.
The WRKSYSSTS display also shows activity levels and job transition statistics. (Depending on the assistance level being used for the command, press the F11 key to see job transition data.) The activity level (Max Active) indicates the maximum number of processes or threads that may be active in the memory pool at the same time. A low activity level value may result in additional delays when a process or thread is required to wait for a free activity level. This is indicated by job transitions from Wait to Ineligible or Active to Ineligible. A general rule of thumb is to increase the activity level value to avoid these transitions to ineligible.
The QPFRADJ system value can be used to enable i5/OS to automatically monitor and optimize memory pool sizes and activity levels. It can be enabled to optimize these values at IPL time, during normal run time, or both. It will move memory from one pool to another to reduce faulting rates in the most active pools. It will also increase the activity level to reduce or avoid job transitions to ineligible. The Work with Shared Pools (WRKSHRPOOL) command can be used to provide the system with additional guidance on this automatic tuning; for example, minimum and maximum sizes for memory pool sizes can be specified. The display also includes the Paging Option for each pool which can be set to *FIXED or *CALC. *FIXED is the default and indicates that the system will not dynamically adjust the paging characteristics of the storage pool for optimum performance. The value *CALC enables dynamic adjustment of the paging characteristics and may be recommended in specific cases, some of which are described in this document.
The Work with Disk Status (WRKDSKSTS) command can be used to monitor disk I/O activity including disk usage (percent full), disk utilization (percent busy), and detailed information on the number, size, and type of disk I/O operations. Performance can be strongly affected by disk utilization; the general guideline is not to exceed 40% busy.
iSeries Navigator Collection Services provide another way to gather performance data on the system and facilitate analysis and comparisons. It gathers all the data described above plus extensive information on jobs, resource utilization, seize and lock contention, journal performance, and so on.
All the commands, interfaces, and system values referenced in this section on general tuning are described in iSeries Information Center. The URL is listed in Appendix D.
IBM HTTP Server Performance The IBM HTTP Server for iSeries™ (powered by Apache) is the product that renders web pages to WebSphere 6.0 and WebSphere 6.1 running the JD Edwards EnterpriseOne 8.12 web client solution. The HTTP Server can be started, analyzed, and tuned through a browser interface, the IBM Web Administration for i5/OS, or by using System i system commands. The browser interface offers ease-of-use features such as selecting options from lists rather than typing in entries to the configuration file. It also offers extensive help text and is the recommended user interface. To start the browser, open iSeries Navigator and click on network, then servers, then TCP/IP, and in the right pane right click on HTTP administration and click on Start. See Figure 1. The i5/OS equivalent command is STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN). Both methods also start the subsystem QHTTPSVR if necessary.
Figure 1 - Starting IBM HTTP Server administration for i5/OS from iSeries Navigator
To access the browser interface, start a Web browser, such as Microsoft® Internet Explorer, and enter the URL http://<server-name>:2001 where <server-name> is the name of the System i server. When prompted to sign on to the server, enter a valid System i user profile and password.
Configuration changes can be made through the IBM Web Administration for i5/OS interface or by directly editing the HTTP configuration file (using the edtf command). There is a configuration file for each HTTP server instance located in the IFS directory /www/<http-server-name>/conf, where <http-server-name> is the name of the HTTP server instance. This directory contains a file, httpd.conf, which holds all of the configuration information for that instance. An example is listed in Appendix B. The information below describes how to make changes to the configuration through the browser interface and also lists the HTTP configuration keywords and values that can be directly entered into the httpd.conf file.
Measure and Analyze
To measure the performance of the HTTP server instance, use System i performance tools such as Performance Monitor and Performance Explorer (PEX). To review what is happening in the HTTP server instance, examine the access log which is enabled by default. Because the access log impacts performance, one of the recommendations below is to disable this logging function during normal operations; access logging can always be re-enabled if there is a need to monitor the log or debug
problems. The access log is located in the IFS directory /www/<http-server-name>/logs where <http-server-name> is the name of the HTTP server instance.
To more closely examine what is happening while the HTTP server instance is active, the IBM Web Administration for i5/OS provides real time statistics for the HTTP Server on System i. To view these statistics, click on the “Real Time Server Statistics” link on the left hand pane, as shown in Figure 2.
Figure 2 - Real Time Server Statistics show current activity on the HTTP server instance
The server statistics screen shows information about the number of connections in use and the number of requests and responses. Monitor the number of active and idle threads during the time that the system is running its peak load. Adjust the number of threads accordingly, as described in the section below “Set the number of threads for each job.” Additional information such as the byte counts sent and received is available on the “Absolute” and “Delta” tabs. Use this information to look at the communications workload running on the system during peak time periods.
Adjust
The HTTP server instance has several settings that can impact the performance of the JD Edwards EnterpriseOne web client solution. Enable these settings one at a time to ensure that each recommended change provides a benefit. Changes can be made to the HTTP configuration in two ways:
By selecting the HTTP server instance, through the IBM Web Administration for i5/OS interface
By directly editing the configuration file, httpd.conf, located in the IFS (using the edtf command)
To make the changes through the Web interface, select the HTTP server instance from the list as shown in Figure 3. In this example, select WASHTTPSVR from the list and make changes to the settings associated with this instance. (Note that this document uses the default names for Oracle installation. The name of the HTTP server instance(s) is dependent on the installation.)
Figure 3 - Select the HTTP server instance
1) Minimize the logging in the production environment
As discussed earlier, logging is useful during the initial startup of the web client environment as well as for debugging problems. When the production environment is running and stable, however, extraneous logging should be disabled as it consumes a large amount of processing power.
The HTTP Server provides two different types of logging: error logging and access logging. The error log can be configured to capture various types of errors. By default it will capture all warnings, errors, and critical conditions. The recommendation is to change this setting so that only errors and critical conditions are captured in the error log. Also, since a separate error log will be created for each day that the HTTP server instance is running, change the configuration to have logs automatically removed after one week, as this reduces the disk requirements for the HTTP server instance.
One way to change the log settings is to select “Logging” from the left pane on the IBM Web Administration for i5/OS, then select “Error Logs.” As seen in Figure 4 change the “Expiration” value to “1” week on the error logs page, then select the “Logging Level” pull-down list and select “Error” instead of “Warning.” Click the Apply button after making the changes; otherwise the changes are not saved.
Figure 4 - Change the error log settings in HTTP server instance
Alternatively, change the configuration file by editing it to add the following two lines:
LogLevel Error
LogMaint logs/error_log 7 0
The access log, as the name indicates, captures all HTTP accesses to the system. Each browser that accesses the system via a URL will be noted by an entry in the access log. Depending on the number of users connected to the system, this log can become very large. As a result, the performance recommendation is to disable all HTTP access logging. Since the access log tracks all access to the system, however, it can be used to determine the location of a Web attack. Security considerations need to be balanced with the performance impact of access logging.
One way to disable the access log is to click on the “Custom Formats” tab on the “Logging” page. As seen in Figure 5, click the radio button on each of the log formats and then click the Remove button. After all of the log formats are removed, click the Apply button. Then click on the “Custom Logs” tab, select the entry for “logs/access_log”, click the Remove button, and then click the Apply button.
Figure 5 - Eliminate access logging for the HTTP server instance
An alternate way to disable the access log is to change the httpd.conf file for this instance. Comment out the following lines in the file by putting a number sign (#) in front of each line:
If the system has been running with access logging enabled, deleting the existing logs will clean up system storage. The logs are located in the directory /www/<http-server-name>/logs. Delete all of the files in this directory; the HTTP Server automatically creates new files as needed for the instance.
2) Allow unlimited requests per connection
When a browser on a client machine makes a connection to the HTTP server instance, the server maintains (or keeps alive) the connection and allows multiple requests from many browsers to be made on the same connection. It is more efficient to keep the same TCP connection for as many requests as
possible. By default, the HTTP server instance will use the same TCP connection for 100 requests. Other platforms sometimes recommend using this limit on the number of requests per connection based on memory concerns but this is not a significant concern for System i. The recommendation is to change the setting so that an unlimited number of requests can be sent on the same connection.
Note: This guideline is different on other platforms. Please use caution to ensure that the correct tuning is applied in an environment which utilizes multiple platforms. For all platforms other than System i, refer to “Performance Tuning EnterpriseOne and WebSphere 5.0.2” listed in Appendix D.
One method of changing this setting is to select “System Resources” from the left pane of the IBM Web Administration for i5/OS and select the “HTTP Connections” tab as shown in Figure 6. Set the number in the field, “Maximum requests per connection” to 0. Although this may seem counter-intuitive, “0” indicates that the server will allow an unlimited number of requests.
Figure 6 - Allow unlimited requests per connection for the HTTP server instance
Another way to change this setting is to edit the httpd.conf configuration file by adding the following lines:
The HTTP server job maintains a pool of threads. The number of threads is determined by a configuration setting. The thread pool is used to service all the web browsers that connect to the server job. If all threads within the HTTP server job are in use and a new request arrives, an additional job will be started—with the same number of threads in its pool. The recommendation is to keep the proper number of threads available to avoid the extra overhead of starting another HTTP server job.
Adjust the number of threads that run in each of these HTTP server jobs by selecting “General Server Configuration” from the navigation pane on the left-hand side and then selecting the “General Settings” tab. Change the field for “Number of threads to process requests” and then click the Apply button. The default is 40, and lab tests have found that this number of threads is sufficient to adequately handle 400 users doing typical workloads through browser connections. If the system is running more users than this, change this setting accordingly. For example, if the system is being configured for more than 400 users, change the setting to 50 as shown in Figure 7.
Figure 7 - Set the number of threads to handle requests in the HTTP server instance
Alternatively, adjust the number of threads running in each Web server job by editing the httpd.conf file to add the following line:
Note: This guideline is different on other platforms. Please use caution to ensure that the correct tuning is applied in an environment which utilizes multiple platforms. For all platforms other than System i, refer to “Performance Tuning EnterpriseOne and WebSphere 5.0.2” listed in Appendix D.
4) Enable compression
HTTP Server supports data compression of HTML files delivered to clients that support decompression. This compression of files to the client decreases the data volume sent over the network and improves response times. It is enabled via a DEFLATE filter, which can be configured to only compress files located in certain directories. Remote clients connected to the network over a wide area network (WAN) at slow speeds have the greatest potential for performance gains. Local clients connected at higher speeds will see smaller performance gains.
Compression must be supported by both the HTTP Server and the web client’s browser to take advantage of this feature. In V5R3 and V5R4, HTTP Server for i5/OS includes compression support in the base product. Likewise, Internet Explorer and Netscape Navigator both support this function when running at the versions recommended by the Oracle MTRs (Minimum Technical Requirements).
There are two steps to enable compression:
1. As shown in Figure 8, select “Compression” from the left pane, and then click on the “Output Filters” tab. In the “Set output filter” section, click “Add”, enter “Deflate” as the filter name, and click “Apply.”
Alternatively, edit the configuration file by adding the following lines:
Figure 8 - Enable compression for the HTTP server instance
2. Next, as shown in Figure 9, in the “Server area” section, select the directory path that ends with “webclient.war” that was added during the JD Edwards EnterpriseOne Java™ Application Server (JAS) configuration. Next select “Compression” from the left pane. Click the “Add” button in the “Add output filter by MIME type” section, then enter a MIME type of “text/html” or select it from the list. Finally, enter a filter name of “DEFLATE” and click the “Apply” button.
Figure 9 - Set the output filter for text in the JAS directories
Alternatively, change the directory directives to include the filter statement for text by adding the line shown in bold, below, to the httpd.conf file:
Note: Some implementations may contain a hardware compression device which may not be compatible with this software compression feature. For further information, contact the appropriate hardware service provider.
WebSphere Application Server Tuning The WebSphere Application Server product runs the JD Edwards EnterpriseOne 8.12 Java Application Server (JAS) code in a server instance, created at install time, which is named AS_JS_xx, where xx is the port number specified as part of the installation process. The WebSphere Application Server is a general-purpose J2EE environment capable of running many different types of Java-based applications with JD Edwards EnterpriseOne JAS code being only one of them. JAS is the application code which is a set of Java servlets and Java Server Pages (JSPs) that is used to serve as the JD Edwards EnterpriseOne application interface to web users. Each WebSphere Application Server instance runs in its own Java Virtual Machine (JVM). This document contains tuning considerations for both WebSphere Application Server 6.0 and 6.1.
WebSphere Application Server 6.0 (5733-W60) on System i is a 64-bit implementation. It has two versions that are supported for use with JAS: Base and Network Deployment (ND). (The System i also supports WebSphere Application Server 6.0 Express but JAS does not support this version of WebSphere.) The difference between Base and ND is that Network Deployment includes additional functionality for clustering, high availability, and load balancing. ND can be used to either configure multiple instances of the application server on the same system (“vertical clustering”) or multiple instances on multiple systems (“horizontal clustering”). Vertical clustering can help environments with high JVM memory requirements as it allows separate tuning and management for each JVM. Horizontal clustering is not generally used on System i because of the inherent scalability of i5/OS and ease of management. Both versions are full 64-bit implementations and provide very good scalability.
Oracle has recently announced support for WebSphere Application Server 6.1 (5733-W61) in environments which utilize V5R4 of i5/OS and either JD Edwards EnterpriseOne Tools 8.96.3 or JD Edwards EnterpriseOne Tools 8.97. It has Base and ND versions which provide the same functionality as WebSphere Application Server 6.0 but has two key differences. First, it uses a new Java implementation called “IBM Technology for Java” which is based on the same technology used by IBM on other system platforms. Secondly, it provides a 32-bit implementation which can offer significant performance improvements and reduces memory requirements for many applications.
For additional information on the Minimum Technical Requirements, please refer to the following Oracle website (user id and password required) or contact the appropriate service provider:
This document does not cover WebSphere Application Server 5.0; please refer to the earlier version of this document for specific tuning information, “IBM eServer iSeries Performance and Tuning Tips for Oracle’s JD Edwards EnterpriseOne 8.10 and 8.11 Web Server” listed in Appendix D. Customers using WebSphere Application Server 5.0 are encouraged to upgrade to WebSphere Application Server 6.0. IBM withdrew support for WebSphere Application Server 5.0.2 and WebSphere Portal 5.0.2 as of September 30, 2006. In order to assist customers during the transition, the JD Edwards EnterpriseOne Global Support Center may provide some limited support with a planned end date of June 30, 2007. For official information, refer to the following Oracle website (user id and password required) or contact the appropriate service provider: http://www4.peoplesoft.com/psdb.nsf/8a8a06594f72ee9888256bae00726172/e44fff5dfaabe9d388257194006bb05f?OpenDocument
WebSphere 6.0 and 6.1 require an additional step to apply service pack fixes. The instructions are shipped in a file such as “/QIBM/ProdData/WebSphere/AppServer/V6/Base/updateinstaller/Readme.txt”. For WebSphere 6.1, the file is “/QIBM/ProdData/WebSphere/UpdateInstaller/V61/UPDI/ReadmeV61.txt”. For detailed instructions, refer to the IBM Preventive Service Planning website which provides information on available fixes and instructions on how to apply them. The URL for this website is: http://www-912.ibm.com/s_dir/sline003.NSF/GroupPTFs?OpenView&Start=1&Count=30&Collapse=1#1. Also new is the capability of uninstalling the WebSphere service pack, if that ever becomes necessary.
After the PTFs and service packs are applied, use the Work PTF Group (WRKPTFGRP) command from the command line or iSeries Navigator to verify that the service pack was installed. If using iSeries Navigator click “Configuration and Service”, then “Fixes Inventory” to see the list of installed Fix Groups and PTFs.
Measure and Analyze
The WebSphere Application Server, in general, and the JAS server code, specifically, can be analyzed in a variety of ways. First, the traditional performance tools can be used to understand utilization of CPU, disk, memory, and other resources. These include Performance Monitor, Performance Explorer, and iSeries Navigator Collection Services. Secondly, i5/OS provides command interfaces such as Dump JVM (DMPJVM) and Analyze JVM (ANZJVM) which can be used to look at heap usage, garbage collection, thread stacks, and object statistics. Thirdly, JAS and WebSphere both have built-in tools to support performance analysis.
Prior to the availability of Server Manager for JD Edwards EnterpriseOne as described below, JAS includes the System Administration Workbench (SAW) which can be used to analyze JAS performance including response times and statistics for business functions. See the JD Edwards EnterpriseOne Application Tuning section for details. WebSphere Application Server 6.0 and 6.1 includes the Tivoli® Performance Viewer which can be used to analyze thread and heap resources for JAS using WebSphere ND with Deployment Manager. Additional tools are also described in Appendix C.
Oracle has recently announced the Server Manager for JD Edwards EnterpriseOne product which is used to install JD Edwards EnterpriseOne Tools 8.97 HTML Server. It also replaces SAW and provides new interfaces for configuration and administration. This document includes some examples of how it can be used to manage some settings. For more information, contact Oracle or the appropriate service provider.
Adjust
Changes to the WebSphere configuration are made through the WebSphere Administrative Console. For WebSphere 6.0 and 6.1, the Administrative Console uses a web interface. The default instance of WebSphere, server1, is accessed through the following URL:
http://<sys>:9060/ibm/console
where <sys> is the name of the System i server that is running WebSphere.
The administrative console presents a user id prompt, which is used to track the changes entered into the administrative console. It does not have to match a System i user profile.
In each of the following topics, the recommendations for WebSphere 6.0 are provided and are followed by the guidance for WebSphere 6.1.
On System i servers, Java performs memory management for applications running within the JVM. It allocates memory on behalf of the application in a single heap space and cleans up unused memory via the garbage collection process. WebSphere, as a Java application, has its memory managed by the JVM. When the application server running JAS is started through WebSphere, Java allocates memory and manages it on behalf of JAS. Setting the initial and maximum heap sizes for the JVM helps manage the amount of memory used by WebSphere. Because they use different algorithms for managing memory allocations, the tuning guidelines are different for WebSphere 6.0 and 6.1. The following considerations apply for WebSphere 6.0.
The JVM used by WebSphere 6.0 uses the initial heap size as the indicator for when to perform a garbage collection. Therefore, setting the initial heap size to an appropriate value for the workload is very important. Setting the heap size too small causes frequent garbage collections which consume CPU resources. Setting the heap size too large causes excessive memory usage, paging, and can result in a higher cache miss ratio because the heap is so large. The initial heap size setting for JAS is based on the number of active users. The guideline derived from lab tests is 1.5 megabytes of memory per active user. The active user count is defined as the number of concurrent users who are clicking OK or function keys two to three times per minute. The appropriate setting may vary depending on the type of applications being run as well as the number of users. For example, a larger initial heap size may provide better performance on a system with large amounts of memory. A minimum heap size of 256 MB is strongly recommended, even for a low user count.
The maximum heap size controls how large the JVM heap is allowed to grow. For WebSphere 6.0 the recommendation is to let the System i i5/OS control the maximum heap size. Blank out this field (which corresponds to the value “0”) to let the system manage the maximum heap size. In certain cases on memory-constrained systems, setting the maximum heap size to some multiple of the initial heap (but never equal to the initial heap) may help the overall system performance but the general recommendation is to leave it blank.
Note: This guideline is different on other platforms. Please use caution to ensure that the correct tuning is applied in an environment which utilizes multiple platforms. For all platforms other than System i, refer to “Performance Tuning EnterpriseOne and WebSphere 5.0.2” listed in Appendix D. This parameter is especially important as most platforms recommend setting a maximum heap size which can potentially hurt the performance of WebSphere on i5/OS.
To change the JVM settings for the application server, follow these steps: expand Servers > click Application Servers > click the desired Server Name > click Java and Process Management > click Process Definition> click Java Virtual Machine. The example of changing the JVM settings for a 200-user workload is shown in Figure 10 where the initial heap size is set to 300 megabytes (which equals 200 users times 1.5 megabytes each). The maximum heap size has been set to 0 as recommended above.
Figure 10 - Set the initial and maximum heap size for the JVM in WebSphere 6.0
For WebSphere 6.1, the recommended values for initial and maximum heap size are somewhat different and are influenced by three factors. First, the IBM Technology for Java implementation (IT4J) used by WebSphere 6.1 in V5R4 is a 32-bit Java implementation. Because 32-bit pointers are smaller than 64-bit pointers, most applications see a reduction in main storage requirements and improved performance and scaling. Secondly, because IT4J is a 32-bit Java implementation, it can address a maximum of 4 GB of memory. Some of this is reserved for use by the operating system and the JVM implementation. Many applications make use of additional heap memory which further affects how much can be allocated to the WebSphere JVM. IBM evaluations indicate that the effective maximum heap size value for JD Edwards EnterpriseOne is 1744 MB. Thirdly, the general guideline for WebSphere 6.1 is to specify a maximum heap size that is at least four times the initial heap size. This leads to the following recommendations:
• If the environment is not memory constrained, specify a maximum heap size of 1744 MB and an initial heap size of 436 MB (e.g. one fourth of the maximum heap size).
• If the environment is memory constrained, specify an initial heap size of 1.5 MB per user or 256 MB, whichever is larger. Specify a maximum heap size of four times the initial heap size.
• In any environment, do NOT run with the default heap size values which are shipped as part of WebSphere 6.1. These values are 32 MB for initial heap size and 768 MB for maximum heap size. This small initial heap size would lead to sub-optimal performance due to garbage collection. in a JD Edwards EnterpriseOne environment.
As always, the appropriate settings may depend on the type of applications being run and the system environment.
Although the path to change the settings remains the same for WebSphere 6.1, the user interfaces are slightly different. Figure 11 shows the values recommended above.
Figure 11 - Set the initial and maximum heap size for the JVM in WebSphere 6.1
Heap size and garbage collection information may be checked with the DMPJVM command. This command produces a spooled file that contains information on the current heap size, the number of garbage collections performed, and the duration of the last garbage collection. At times, it may be helpful to collect additional data about the garbage collector as it is running. This can be accomplished with verbose garbage collection which records several pieces of information into System.out each time the collector runs. This includes the current heap size, as well as the number and size of objects collected, number of objects in the heap, amount of time the collector ran and other information. For further information, please refer to the document “Tuning Garbage Collection for Java and WebSphere on iSeries” listed in Appendix D.
The number of users that can be supported by a single JVM is difficult to describe accurately. In controlled benchmark environments, JD Edwards EnterpriseOne has been run with up to 1600 users in a single JVM but that is not a realistic assumption for a production environment. In practice, feedback from customers using web-based clients indicates a maximum of 150 to 200 users.
2) Adjust the number of threads running in the JVM
WebSphere maintains a pool of threads that processes requests from web clients. Two things limit the pool: the minimum number of threads started and the maximum number of threads allowed in the pool. Set the minimum size to handle the average load on the system and set the maximum size to handle the peak load. A good place to start is to set the minimum number of threads to 10% of total expected users and the maximum to equal the total expected users. The pool settings limit the number of users that can be handled concurrently. Setting the minimum too high causes additional memory usage. Setting the maximum too low causes users to wait, increasing response times.
To navigate to the panel for thread settings when using WebSphere 6.0, use the following path: expand Servers > click Application Servers > click the desired Server Name > click Additional Properties > click Thread Pools> click WebContainer. Change the “Minimum Size” to the average workload and the “Maximum Size” to the peak workload plus one (necessary overhead for JAS). Check the “Allow thread allocation beyond maximum thread size” checkbox so that thread allocations are never restricted.
As an example, Figure 12 shows the recommended values for a maximum workload of 200 users. The minimum size is set to 10% of the total number of users (or 20 threads). The maximum is set to 200+1 (or 201 threads). The checkbox “Allow thread allocation beyond maximum size” is checked.
Figure 12 - Set the number of threads for the JVM in WebSphere 6.0
The guidance for thread settings for WebSphere 6.1 is the same as WebSphere 6.0 but the user interfaces are slightly different. Figure 13 shows the recommended settings for 200 users as they appear in WebSphere 6.1.
Figure 13 - Set the number of threads for the JVM in WebSphere 6.1
3) Adjust WebSphere subsystem settings in i5/OS
As shipped, the WebSphere subsystem runs in the *BASE memory pool on the system. For smaller systems or systems with limited memory, the system may run more efficiently using the *BASE memory pool. In many cases, however, it is helpful to divide workloads into separate memory pools. Putting WebSphere into a separate memory pool isolates it from other workloads and ensures it does not compete with other jobs for memory. This can be done either with a private pool belonging to the WebSphere subsystem or by using a shared memory pool which provides more flexibility as it can be managed using the combination of QPFRADJ and WRKSHRPOOL as discussed above. Using a shared memory pool is the recommended technique and is described below. For information on how to use the alternative technique using a private pool, please refer to the System i Information Center website listed in Appendix D. Note that these pool configuration changes can sometimes be implemented on an active environment but it is recommended that this be done while the environment is offline to minimize performance disruptions during movement of the memory resources.
The following are the steps to configure WebSphere to run in a separate pool:
1. Use the Display Subsystem Description (DSPSBSD) command to display the subsystem where WebSphere is running. For WebSphere 6.0, this is normally the subsystem description QWAS6 in library QWAS6. The command is: DSPSBSD SBSD(QWAS6/QWAS6). For WebSphere 6.1, the SBSD (subsystem description) value would be QWAS61/QWAS61.
2. Take option 2 – Pool Definitions to display the pool configuration for the subsystem. By default, one subsystem pool with *BASE in the Storage Size column is shown.
3. The remaining instructions assume a default configuration. If unable to verify which subsystem description is being used for WebSphere or if the pool configuration is different than described above, stop here. The instructions for this environment would need to be identified by a service provider or someone with appropriate i5/OS work management skills.
4. The next step is to identify the shared memory pool to be used via the WRKSHRPOOL command. If running a default configuration, *SHRPOOL1 is available. If it is in use, any available shared pool can be used in its place.
5. The next step is to determine the initial amount of storage and the activity level for this pool. For both WebSphere 6.0 and WebSphere 6.1, the recommendation is to allocate four times the initial heap size per JVM plus 1 to 1.5 GB for additional overhead. In the example environment for 200 production users described above, initial heap size was 300MB. Four times that value is 1.2GB plus approximately 1GB for additional WebSphere needs, which gives a total of 2.2GB. These values are additive and should reflect the needs of all JVMs in use. The activity level is the maximum number of processes or threads active in this memory pool at the same time. A good starting point for this value is 1.5 times the number of users. For this example, the recommended value for 200 users would be 300. This value is independent of which version of WebSphere is being used.
6. An additional recommendation is to set upper and lower bounds for the pool size using the WRKSHRPOOL command. This provides the automatic performance adjustment enabled by the QPFRADJ system value with boundaries to ensure that the pool does not get too small or too large based on system activity. The values will depend on the configuration; a reasonable starting point is to specify minimum and maximum sizes that are 20 percent smaller and larger than the value determined in the previous step. This is done because JVM Garbage Collection requires sufficient memory to perform its processing. Allowing the pool to become too small can potentially cause performance problems.
7. The following command can be used to define the shared pool: CHGSHRPOOL POOL(*SHRPOOLn) SIZE(x) ACTLVL(y) PAGING(*CALC) TEXT('WebSphere Pool') where n is the number of the shared pool, x is the amount of memory allocated, and y is the activity level determined in the previous steps. Note that this storage is not allocated until the pool is in use by an active subsystem. It will be taken from *BASE either when an active subsystem is changed to use it or when an inactive subsystem is started after being changed to use it. Note that both the size and the activity level can be adjusted automatically if the QPFRADJ system value is set to allow automatic adjustment or they can be set manually using WRKSYSSTS.
8. The WebSphere subsystem must be changed to make use of the shared memory pool. Note that each subsystem refers to its subsystem memory pools as 1, 2, etc. but this value does not correspond to the system pool numbers shown on WRKSYSSTS. The Work with Subsystems
(WRKSBS) display shows the relationship between subsystem pools and system pools. The CHGSBSD command is used to indicate which pools are to be used by the subsystem. Although it is not strictly required, it is recommended that subsystem pool 1 should remain *BASE. The following Change Subsystem Definition (CHGSBSD) command will update the subsystem to reflect the new memory pool: CHGSBSD SBSD(QWAS6/QWAS6) POOLS((1 *BASE) (2 *SHRPOOLn)) where *SHRPOOLn is the shared pool identified above. For WebSphere 6.1, the SBSD (subsystem description) value is QWAS61/QWAS61.
9. Next, each routing entry in the subsystem must be updated to reference the new memory pool. Again, enter DSPSBD to display the subsystem description. Take option 7 to Work with Routing Entries. For each routing entry, enter the following command: CHGRTGE SBSD(QWAS6/QWAS6) SEQNBR(9999) POOLID(2) For WebSphere 6.1, the SBSD (subsystem description) value would be QWAS61/QWAS61. On a default configuration, there is just one routing entry and this command will be all that is required.
After restarting the subsystem for these changes to take effect, use the command WRKSYSSTS to look at the new pool. Validate the activity level setting for the shared memory pool by using the WRKSYSSTS command, pressing the F11 key, and verifying that the “wait to ineligible” value (Wait->Inel) remains at zero. If this value is significantly greater than zero, the activity level needs to be increased further.
The same general procedure can be used to allocate a separate memory pool for JD Edwards EnterpriseOne’s UBE jobs. In any case, it is not recommended to run WebSphere and UBE work in the same memory pool. Like WebSphere, the subsystem running UBEs should be configured with a paging option to *CALC.
EnterpriseOne Application Tuning JD Edwards EnterpriseOne provides a complete suite of modular, integrated industry-specific business applications. JD Edwards EnterpriseOne is flexible, permitting the database, application logic, and user interface code to run entirely on one system or each of these can run on separate systems.
Measure and Analyze
Similar to the HTTP Server and WebSphere Application Server, JD Edwards EnterpriseOne has built-in tools for monitoring the performance of the user’s interaction via the web interface. Prior to the availability of Server Manager for JD Edwards EnterpriseOne, the main interface for JD Edwards EnterpriseOne Server Administration Workbench (SAW) can be accessed via the following URL:
http://<sys>:<port>/jde/saw/index.jsp
where <sys> is the name of the JAS server system and <port> is the port on which the JAS server is listening. Within this browser interface, two of the areas will be discussed in this document: JAS SAW and Enterprise SAW.
The JAS SAW tool allows an administrator to monitor the performance of the JAS server and its interactions with the other components of the application and system. It can be accessed either from the above URL, or directly: http://<sys>:<port>/jde/saw/sawJAS.html
where <sys> is the name of the JAS server system and <port> is the port on which the JAS server is listening. JAS SAW provides various views for monitoring:
System Summary – shows a high-level view of the heap’s memory allocation, number of users logged in, and business functions.
User List – shows the number of users signed on and active. CallObject Info – lists the business functions that have been run and statistics about the calls. Work with Log files – contains the logs and ini files. Environment – lists the various operating system and Java properties. Config – shows some of the JAS.INI configuration settings. JDENET pool – lists all of the connections to the enterprise server. Work with JDBj – contains details of the JDBC connections and caches the JAS server maintains. Virtual Clients – lists all virtual client sessions and activity within them. Outstanding Requests – shows any requests currently waiting for the enterprise server to return. Thread List – shows all threads running within JAS and their current activity.
Each of these views is useful for tracking various aspects of the JAS server and its configuration. For example, the System Summary view shows how many users are currently active on the system and how much memory they are using in the JAS server. See Figure 14.
Figure 14 - EnterpriseOne JAS SAW system summary screen
The second area of SAW is the enterprise server portion of JD Edwards EnterpriseOne with useful information about the jobs running on the enterprise server. Access it via the main URL above or directly via the URL:
http://<sys>:<port>/jde/saw/sawEnt.html
When prompted for host and port, enter the name of the JD Edwards EnterpriseOne enterprise server and its port (6014 by default). SAW for enterprise server also contains multiple views:
Server Summary – shows a high-level view of the enterprise server instance, including time the server has been running, all currently running EnterpriseOne processes, and any zombie processes that have not been removed.
All log files – lists all the log files in the log directory on the JD Edwards EnterpriseOne server including those for currently running processes and those no longer running (e.g., porttest, cleanup, etc.)
Active log files – lists all the log files in the log directory on the JD Edwards EnterpriseOne server that are for currently running processes.
PrintQueue log files – lists all the log files in the PrintQueue directory on the JD Edwards EnterpriseOne server. These are from UBEs that have run on this server (not applicable on System i).
Disk Usage – shows information for disk utilization on the EnterpriseOne server. The disk where this instance of JD Edwards EnterpriseOne is installed is highlighted in green.
View INI settings – lists all of the publicly available JD Edwards EnterpriseOne server JDE.INI settings.
Remove all Zombie processes – with SAW administrative rights, this will remove all the zombie processes from the Server Summary screen.
Package Build files – lists all of the text files in the package build area of the JD Edwards EnterpriseOne server.
View Environment Variables – lists all of the environment variables and their values for the JD Edwards EnterpriseOne server processes.
The server summary view shown in Figure 15 displays information about each of the server jobs, identifies which jobs have a backlog of requests, and allows tracing to be turned on dynamically.
Figure 15 - EnterpriseOne Enterprise SAW system summary screen
There is an alternative, older version of enterprise SAW which can be run from an i5/OS command line. (The system library, such as E812SYS, must be in the library list for this command to work properly). See Figure 16. Note that this version can still be used even after the availability of Server Manager for JD Edwards EnterpriseOne because it only replaces the graphical version of SAW.
Figure 16 - EnterpriseOne green screen Work with Server Processes screen
The interfaces for tuning EnterpriseOne using the Server Manager are somewhat different. For example, Figure 17 shows Java heap size information. The path to navigate to this screen is as follows: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne HTML Server instance > Under Runtime Metrics on the left, click Java Environment
Figure 17 - Server Manager Java environment information
Adjust
Prior to the availability of Server Manager for JD Edwards EnterpriseOne, the JD Edwards EnterpriseOne provides configurable parameters through INI files in the IFS. These files can be edited using the edtf command from the System i command line. For the enterprise server, this is the JDE.INI file which can be edited by entering the command: edtf ‘/E812SYS/ini/jde.ini’ In the tuning suggestions that follow, this is refered to as the JDE.INI file.
The JAS server provides configurable parameters through the JAS.INI file in the IFS. On the System i command line, enter the command:
where <sys> is the name of the System i server and <ent-app> is the name of the enterprise application. In the tuning suggestions that follow, this is referred to as the JAS.INI file.
With the availability of the ServerManager for JD Edwards EnterpriseOne, all of these settings are managed using a graphical interface and can no longer be set by editing the JDE.INI or JAS.INI files. The following sections show both methods.
1) Single-threaded kernels in JDE.INI - number of call object kernels
The JD Edwards EnterpriseOne enterprise server makes use of various jobs known as “kernels” to accomplish work for a web user. Security kernels authenticate the credentials for web users. Call object kernels run business functions on behalf of web users. The configuration interfaces provide two types of settings related to these jobs. The first setting is the number of jobs automatically prestarted when JD Edwards EnterpriseOne services are started. Additional jobs are started if a request arrives and all jobs are currently active—but only up to the second setting, which is the maximum number of jobs allowed to run.
Call object kernel jobs are capable of handling the requests for multiple users. Because each job caches information and uses system resources, starting too many jobs is not efficient. However, the presence of too few call object kernels could cause users to wait for business functions to run and increase response times. Previous versions of this document indicated 15-20 users per call object kernel is optimal but feedback from customers indicates 6-10 users per call object kernel. The best guidance is to use a tool such as SAW for enterprise servers to monitor the environment to find the best setting. When call object kernels are in single-threaded mode, monitor the Enterprise SAW system summary screen as shown in <Figure 13> and, if outstanding requests are backing up, either increase the number of call object kernels or consider switching to multi-threading (see next section).
Starting an optimal number of jobs is recommended for security kernels and network jobs as well. One security kernel for every 100 users (minimum of two) and one network job for every 20 call object kernel (minimum of two) is a reasonable choice.
Automatically starting a reasonable number of these kernel types is recommended but depends on environment. In an environment where workload is high and users all log in at the same time, it may be reasonable to set the value for AutoStartProcess equal to the value for maxNumberOfProcesses. In an environment where workload is low and work does not all start at the same time, setting the value for AutoStartProcess equal to half of the value for maxNumberOfProcesses may yield better results.
Prior to the use of the Server Manager, these settings are all changed in the JDE INI file.
With the Server Manager, the recommended values are the same but the settings are changed via the graphical interfaces. Figure 18 through Figure 21 show the panels associated with these settings. To navigate to the general panel for kernel definitions, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne Enterprise Server instance > Under Configuration on the left, click Kernel Definitions. Note that either the scroll bar on the right or the links at the top of the page permit navigation to the specific kernel definitions.
Figure 18 - Server Manager general kernel definitions
Figure 19 - Server Manager call object kernel settings
Figure 20 - Server Manager security kernel settings
To navigate to the panel for kernel definitions shown in Figure 21, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne Enterprise Server instance > Under Configuration on the left, click Network and Queue Settings > click on JDENET Configuration at the top. Note that either the scroll bar on the right or the links at the top of the page permit navigation to the JDENET configuration values.
Figure 21 - Server Manager network kernel settings
2) Multi-threaded kernels in JDE.INI - thread settings and call object kernels
Beginning with 8.96_A1 system code, (requiring application code 8.11_SP1 or higher), Oracle has introduced the optional capability of multi-threading within call object kernels. Previously, call object kernels were single-threaded which meant that each kernel handled only one request at a time. Requests from other users assigned to the same kernel would wait in a queue to be processed. In some
environments under heavy workload, these requests had the potential to build lengthy queues and negatively impact response times.
The multi-threading capability addresses this problem of long-running business functions (LRBFs). Threading guarantees that a business function call will be processed immediately. Function call requests are never queued when multi-threading is enabled. The following section first shows these parameters as they appear in the JDE.INI file and then how they appear using the Server Manager interfaces.
There are three new parameters for the configuration of multi-threaded call object kernels. With 8.96_A1, these parameters are not listed in the JDE.INI file but the default value is single-threading. These entries only need to be added to the [JDENET_KERNEL_DEF6] section if values other than the defaults are desired. As with any kernel change, JD Edwards EnterpriseOne services must be restarted for changes to take effect. To verify the configuration, review the jde.logs. Messages are written to the jde.logs at start-up identifying the threading mode, pool size and increment. The default values for 8.96_A1 are:
singleThreadedMode=Y
ThreadPoolSize=20
ThreadPoolSizeIncrement=5
singleThreadedMode – This parameter will enable/disable multi-threading. A value of "Y" enables single-threading, and a value of "N" enables multi-threading.
ThreadPoolSize – Every kernel maintains its own thread pool of worker threads. This value establishes the number of threads maintained in each pool. As the number of concurrent requests increases in a kernel, the active threads for that kernel will grow. This will continue until the number of threads reaches the ThreadPoolSize value. This value defines the thread pool size, not the maximum number of threads that can be created within each kernel. The maximum number of threads can exceed ThreadPoolSize. In the case where the number of concurrent requests exceeds ThreadPoolSize, an additional thread will be created to accommodate the request. This ‘overflow’ thread will not become part of the pool. It will be destroyed immediately after the request for which it was created has been processed. Be aware that there is overhead associated with the creation and destruction of overflow threads. Choose values for both kernels and thread pool size that will minimize the need to create and destroy overflow threads. Entries will be written to the call object kernel logs when thread requirements exceed the ThreadPoolSize. A single message is entered in the log for every 1,000 threads created and destroyed to avoid excessive logging when thread pool size is exceeded. If this message appears, re-evaluate the configuration.
ThreadPoolSizeIncrement – This value defines the number of worker threads to be initiated at start-up (after the initial or main thread). It also defines the number of threads added to the pool when a new function call request arrives and no idle threads are available which will continue until the thread pool size has been reached.
Internal testing with multi-threading enabled achieved the best performance with a thread pool size of 20 per call object kernel and an increment of 1. Based on discussion with Oracle experts, the ThreadPoolSize value should be set to twice the number of users per call object kernel. Thus, when enabling multi-threading, the recommended configuration starting point for i5/OS is:
[JDENET_KERNEL_DEF6] singleThreadedMode=N ThreadPoolSize=2*x where x is the number of users per call object kernel
Internal testing also indicated that multi-threading can support an even higher number of users per Call object kernel than the 15-20 users observed in tests for single-threading. As indicated above, this is a larger value than most customers report. The best way to establish the optimal number of users per kernel for a specific environment is to try a number of values and use a tool like JAS SAW to monitor and compare the results. For example, Figure 22 displays the JAS SAW view called CallObject Info and is sorted on the avgTime column. This field shows the average response times of the business function calls. The number of call object kernels which minimizes these response times during peak workload is the correct value for the environment.
Figure 22 - EnterpriseOne JAS SAW CallObject Info screen
The recommendation for security kernels, network jobs, and numberAutoStartProcess settings remains the same as single-threaded. See the preceding section.
There are a number of ways to monitor thread usage either through the operating system via iSeries Navigator or WRKACTJOB from the i5/OS command line, or through the Enterprise SAW utility. See Figure 23 through Figure 25 for examples of each method. Note that Figure 25 shows no outstanding requests because multi-threading is enabled.
Note: Prior to enabling multi-threading, it is crucial to ensure that any customized Business Function code is rendered “thread-safe”, meaning that it can be run in a threaded environment without unpredictable interaction between the threads. The main issue is that any shared objects must be accessed in a
synchronized manner. See the Oracle Redpaper “Multi-threaded Kernels” listed in Appendix D for more information.
Figure 23 - Using the iSeries Navigator to monitor thread usage in call object kernels
Note: With 8.12 there is a new kernel called the Metadata kernel which is [DEF30] in the JDE.INI. Its function is to help manage access to the new XML spec format, which has replaced TAM specs. Since there actually is a JVM running within the kernel, it normally has a higher thread count than call object kernels. Refer to Oracle Redpaper “Platform Configuration Considerations for XML Metadata for JD Edwards EnterpriseOne” listed in Appendix D for information on the XML Metadata kernel.
Figure 25 - EnterpriseOne Enterprise SAW to monitor thread usage in call object kernels
With the Server Manager, the recommended values are the same but the settings are changed via the graphical interfaces. Figure 26 shows the panel associated with the multithreaded call object kernel settings which provides a pull down to specify the Thread Mode for Call Object Kernels followed by fields for the Thread Pool Size and Thread Pool Increment. To navigate to the general panel for kernel definitions, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne
Enterprise Server instance > Under Configuration on the left, click Kernel Definitions.
Figure 26 – Server Manager multithreaded call object kernel settings
3) Maximum users for the JAS server in JAS.INI
The maximum users setting in the JAS.INI acts as a threshold. Once the maximum number of users has been reached, no additional users are allowed to log in to JD Edwards EnterpriseOne until another active user logs out. Set the MAXUser value equal to the maximum number of users to be concurrently connected to the JAS. In the JAS.INI file’s OWWEB section, replace the “x” to equal the maximum number of users expected:
[OWWEB] MAXUser=x
Prior to the availability of Server Manager, go into JAS SAW under the User List pull-down to verify that the MAXUser setting is high enough by comparing it to the number of users connected during peak activity.
With the Server Manager, the recommended values are the same but the settings are changed via the graphical interfaces. Figure 27 shows the panel associated with these settings. To navigate to this panel, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne HTML Server instance > Under Configuration, click Web
4) JDENET connections for the JAS server in JAS.INI
The connections between the JAS server and the enterprise server are TCP/IP-based and are referred to as JDENET connections. The number of JDENET connections should be the same as the number of users accessing the JAS server. Prior to the availability of Server Manager, these values are configured in the JAS.INI file. To increase the number of connections, add a line with a maxPoolSize to the [JDENET] section of the JAS.INI file and replace the “x” with the user count:
[JDENET] maxPoolSize=x
JAS SAW under the JDENet Pool pull-down can be used to verify the setting. During peak activity, monitor the waiting column. This number should usually be “0” to ensure that no latency problems exist for JDENET connections.
With the Server Manager, the recommended values are the same but the settings are changed via the graphical interfaces. Figure 28 shows the panel associated with these settings. To navigate to this panel, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne HTML Server instance > Under Configuration on the left, click Network Settings.
DB2 for i5/OS Tuning DB2 for i5/OS is an advanced, 64-bit Relational Database Management System (RDBMS) that leverages the On-Demand features of IBM’s System i5™. A member of IBM’s leading edge family of DB2 products, DB2 for i5/OS supports a broad range of applications and development environments at a lower cost of ownership due to its unique autonomic computing (self-managing) features.
The tight integration of DB2 with i5/OS provides unique attributes to this RDBMS. Single Level Store and the Object Based Operating System (i5/OS) minimize the effort required to manage the database, while maintaining the mainframe-like reliability and security. Automation of many of the common Database Administrator (DBA) tasks required by other RDBMS’s is a cornerstone of DB2 for i5/OS lower cost of ownership.
Because DB2 UDB for iSeries is an integrated part of i5/OS, many of the tools used to analyze the database are also part of i5/OS’s command set.
The JD Edwards EnterpriseOne environment performs the majority of its database access through three interfaces:
See Figure 29 for the list of the different database interfaces, the parts of EnterpriseOne that use them, and the jobs and subsystems that execute the SQL requests for these interfaces.
Native JDBC --JAS running on same system as the database --If multi-threading, when the kernel receives an additional request
QSQSRVR (prestarted) QSYSWRK
Local EDRS (single-threaded)
JD Edwards EnterpriseOne application server on same system as database
JDENET_K E812SYS, etc.
Local EDRS (multi-threaded, 8.96 and up)
JD Edwards EnterpriseOne application server on same system as database
QSQSRVR (prestarted) QSYSWRK
Remote EDRS JD Edwards EnterpriseOne application server on separate system from database
--QXDARECVR (one job per connection) --QXDAEDRSQL (1 job)
QSYSWRK
Figure 29 - System i database connection types
Measure and Analyze
The System i Performance Monitor and Performance Explorer (PEX) utilities can be used to monitor the overall system and database performance. To look more closely at the database component itself, use the database monitor tool. The database monitor can be started through iSeries Navigator or through System i system commands. The recommendation is to use the iSeries Navigator interface.
After starting iSeries Navigator, expand the system, expand the “Databases” section, and then expand the local directory (typically this will be the system name) as shown in Figure 30. Right-click “SQL Performance Monitors”, select “New” and then “SQL Performance Monitor” to start the database monitor. In the new window, on the “General” tab, give the monitor job a name, and a library for storing the data, and on the “Monitored Jobs” tab, select the “All” radio button (unless specific database jobs have been identified). Then click OK. The monitor job will be displayed in the right pane of the window.
Figure 30 - Starting the SQL performance monitor through iSeries Navigator
Since the monitor will impact the end-users’ performance while it is running, it should be run for a short period of time (10-20 minutes) and over a limited number of jobs, if possible. Choose a time period when the system is running the workload of greatest concern. When monitoring is complete, right-click the job in the right pane and select “End”.
Alternatively the following commands can be used to start and stop the database monitor over all jobs using System i commands:
Database monitor information captured in this way can also be imported into the iSeries Navigator interface. Right-click “SQL Performance Monitors” as shown in Figure 30 and select import. Enter the name of the monitor and the library containing the data.
Adjust
DB2 UDB on iSeries has several settings that can be changed to improve the performance of the JD Edwards EnterpriseOne web client environment. Some of these are operating system settings, while others are settings within the web client configuration files.
1) Improve database access performance by creating additional indexes
Using the information collected by the database monitor (as described in the Analyze and Measure section above), iSeries Navigator can perform various queries on this information. These queries can be used to identify many things: temporary indexes that the system is creating for SQL statements, other SQL statements that require sorting, or long running queries. In addition, iSeries Navigator has a function to explain how specific SQL statements are being executed and another function to automatically create a new index to improve the performance of a query. Indexes created through the iSeries Navigator interface should only be used temporarily to test the index and see if it improves the performance of the query. Indexes that help performance should be deleted and then recreated through the JD Edwards EnterpriseOne Table Design Utility. Using JD Edwards EnterpriseOne to create indexes ensures that they are maintained by the application and will not be lost when the application is upgraded.
V5R4 contains new support for a system level Index Advisor in iSeries Navigator, a valuable tool to determine what indexes are being advised and which statements could benefit from them. This can result in much greater productivity, especially since this information is available without running the database monitor. Figure 31 shows a sample of the Index Advisor. This interface can be used to create the recommended indexes and analyze the statements which recommended their creation.
Figure 31 - Sample Index Advisor display
A cautionary note is to avoid blindly creating indexes in large numbers against JD Edwards EnterpriseOne files. In fact, only create an index that is identified as resolving a specific problem. The
index suggestions provided by the System i tools are based on heuristics and algorithms which “cast a wide net”. Adding too many indexes to a given JD Edwards EnterpriseOne file can potentially hurt performance by hindering the optimizer’s functionality and requiring extra system overhead for their ongoing maintenance. They also require disk space. Indexes are not “free”, therefore, and each new index should be evaluated and tested carefully before being added permanently through the JD Edwards EnterpriseOne Table Design Utility.
For additional information on DB2 tuning, please refer to the documentation listed in Appendix D.
2) Tune the number of database connections for the system
i5/OS maintains prestarted jobs for database connections. A prestart job starts before a work request is received, either when the subsystem starts or as a result of the Start Prestart Jobs (STRPJ) command. Prestart jobs are launched from a prestart job entry in the subsystem description. The prestart job entry specifies properties such as what program to run in the prestart job, the memory pool in which the prestart job runs, the number of jobs to start, the threshold at which new jobs will be started, the number of times the job is reused, and the number of additional jobs to start.
The JD Edwards EnterpriseOne web client environment makes use of database prestart jobs. Refer back to Figure 29 to review the list. If a single system is running the JD Edwards EnterpriseOne enterprise server, database, and JAS (All-In-One or AIO), then QSQSRVR prestart jobs are generally being used. If JAS is on a separate system (Virtual Three-Tier or V3T), QZDASOINIT prestart jobs are primarily used. If JD Edwards EnterpriseOne has multi-threading enabled, both AIO and V3T environments make use of additional QSQSRVR jobs. Oracle and IBM worked together to enhance the use of XDA APIs to invoke the more efficient QSQSRVR jobs whenever possible, although QXDARECVR jobs are still used as well. All Windows® clients use ODBC, which requires QZDASOINIT jobs. Regardless of the type of environment and the type of prestart job, the process of tuning the number of database connections for the system is consistent. The following guidance applies to both the QSQSRVR and QZDASOINIT jobs. The examples shown are for the QSQSRVR jobs. To modify them for use with QZDASOINIT, specify QZDASOINIT in place of the QSQSRVR job name and specify QUSRWRK instead of QSYSWRK for the subsystem name.
The system maintains the prestart jobs and starts additional jobs, if necessary. In addition, every five minutes, i5/OS determines whether there are extra prestart jobs not being used. If there are, the operating system gradually starts ending the extra jobs until they are reduced to the number of jobs specified in the initial start setting. Starting and stopping these jobs can cause extra activity as the system attempts to maintain the proper number of jobs. To view the current settings on the database system, use the following command, DSPSBSD QSYSWRK, and select option 10. This will display the various prestart jobs for the subsystem, and then use option 5 for the program QSQSRVR.
To determine the number of prestart jobs currently being used and during the peak period use the command DSPACTPJ SBS(QSYSWRK) PGM(QSQSRVR) as shown in Figure 32. Take note of the peak number of prestart jobs in use.
Figure 32 - Use the DSPACTPJ command for the average and peak number of jobs
Enter the CHGPJE command and press F4 to make the necessary changes for the environment as shown in Figure 33. Use the peak number noted earlier for the “Initial number of jobs” or round it up slightly. By setting the initial number of prestart jobs equal to the peak number of jobs, the additional work of starting new jobs during normal operations is avoided. The jobs are started when the subsystem starts and available as the connection requests are made. The recommended value for “Threshold” is “5” and for “Additional number of jobs” is “10.” In this example, the peak number was 179 and the system will prestart 200 jobs. When 195 jobs are in use, the threshold of five available jobs is reached, and the system will automatically prestart ten more jobs. Note that the maximum number of jobs (MAXJOBS) ships with a value of *NOMAX and should not be changed.
Figure 33 - Use the CHGPJE command to set new values
The parameter Maximum number of uses (MAXUSE) should be left at 200 (the shipped value); allowing the QSQSRVR jobs to be reused 200 times minimizes the number of jobs starting and stopping. If the MAXUSE parameter needs to be reset to the default value of 200, choose F10 for additional parameters, page down, and enter it as shown in Figure 34.
3) Tune the number of database connections for the web client environment
JAS uses JDBC connections to handle its database work. See Figure 29. A JDBC connection is made for a specific System i user profile with a given set of properties. JD Edwards EnterpriseOne makes use of proxy user profiles that allow many JD Edwards EnterpriseOne users to access the System i server through a common user profile. Whenever a proxy user profile is used, JD Edwards EnterpriseOne creates a pool of JDBC connections that many users can share. A connection pool is started and maintained by JAS for every connection type, where a connection type is the proxy user profile and a set of connection properties.
Prior to the availability of Server Manager, these values are configured in the JAS.INI file, the settings for the JDBC connections are maintained in the JDBj.INI file, which is located in the WEB-INF directory. Typically, this will be:
where “x” is set to the maximum number of concurrent database connections from the web client per pool to the database server. The default value of 5 for minimum and initial connections is correct but changing the poolGrowth parameter to 10 is recommended. When maxConnection value is reached, further JDBC requests will be denied, (after retrying 3 times). If the maxConnection is set to the maximum number of concurrent users, this value needs to be revisited periodically and increased as the number of users on the system grows larger. There is no harm in setting maxConnection to a high value as connections are only used as needed up to the maxConnection limit.
Another consideration is the use of the Multiple Application Framework (MAF), which allows each user to open multiple windows and potentially run multiple applications simultaneously, hence opening additional JDBC connections to the database server. It is difficult to predict the impact of MAF on an environment as various users open a different number of applications in any given session. While there is some sharing of resources with MAF, it is safe to assume that the maximum number of connections will increase. MAF usage, therefore, needs to be factored in when setting the maxConnection limit value.
If the JD Edwards EnterpriseOne environment is not using proxy user profiles and each user is mapped to its own System i user profile, the recommendations are considerably different. In this case, set the initial number of connections to “1,” minimum connections to “1,” pool growth to “1” to avoid starting unnecessary JDBC connections.
In an environment where proxy user profiles are not in use, “x” should also be set to maximum number of concurrent users for maxConnection as there is no harm in setting maxConnection to a high value. Connections are only used as needed up to the maxConnection limit.
With the Server Manager, the recommended values are the same but the settings are changed via the graphical interfaces. Figure 35 and Figure 36 show different versions of the panel associated with these settings. To navigate to this panel, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne HTML Server instance > Under Configuration on the left, click JDBJ Database Configuration. Click the link JDBj Connection Pools at the top of the panel.
Figure 35 - JDBj connection pool settings for proxy users
Figure 36 - JDBj connection pool settings when not using proxy users
Oracle also recommends a resultSet Timeout value. This value specifies how long a connection stays dedicated to a given user application and is specified in milliseconds. Specifying too high a value means that a connection will remain dedicated for a longer period of time which can result in insufficient connections available for other work. The default value is 60000 as shown below.
Prior to the availability of Server Manager, this value was configured in the JDBj.INI file:
With the Server Manager, the recommended values are the same but the setting is changed via the graphical interfaces. Figure 37 shows the panel associated with this settings. To navigate to this panel, use the following path: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne HTML Server instance > Under Configuration on the left, click JDBJ Database Configuration. Click the link JDBj Runtime Properties at the top.
Figure 37 - Result set timeout settings for Server Manager
4) Optimize the use of SQL Packages
SQL packages are i5/OS objects that contain both the control structures and the access plan data that are necessary to process SQL statements on the application server when running a distributed program, such as JD Edwards EnterpriseOne. Because SQL packages are shared resources, the information built when a statement is prepared is available to all the users of the package. This saves time, especially in a JD Edwards EnterpriseOne web client environment where many of the users execute the same or similar queries.
All the types of database interfaces used by JD Edwards EnterpriseOne make use of SQL packages with the exception of the Native JDBC driver which is used with AIO environments. (Native JDBC uses the Call Level Interface (CLI) which is implemented with Dynamic SQL which does not use SQL packages.) SQL packages have been the target of several changes in recent releases to improve their scalability and integrity. With V5R2, DB2 for i5/OS started delivery of an enhanced optimizer for SQL statements called the SQL Query Optimizer (SQE). The previous support is called the Classic Query Optimizer (CQE). In general, SQE will provide better optimization than CQE. SQE has an added benefit for SQL packages in that it reduces the overhead and complexity of updating the SQL package because it stores access plans in a global system-managed cache. This cache is used for all access plans implemented by SQE and allows up to three access plans per statement based on environment values which can influence performance.
There are two important considerations when using SQL packages in a JD Edwards EnterpriseOne web client environment:
Ensuring SQL packages are being used effectively Knowing when to delete SQL packages
When underlying metadata has changed in the SQL package When the SQL package will no longer be used (to clean up disk space)
EnterpriseOne has a setting called SQL Package Library which controls package reuse for UBEs. The possible values are as follows:
The value 2, the default setting, is designed to handle a special kind of UBE called Table Conversions (TCs) which runs during an upgrade. It means that SQL packages for UBEs will never be reused. This is necessary because TCs all share the same name. Turning off their reuse improves performance of upgrades as the next UBE would not find the correct framework if it attempts to use the SQL package created by the previous UBE. A setting of 2 will result in the creation of SQL package in QRECOVERY starting with the letter T followed by the job number. Leaving this value at 2 for normal operations is not recommended because UBEs will run slower as they will not be able to reuse the SQL package information.
A value of 0 or 1 allows reuse of SQL packages for UBEs and is better for performance for normal operations. The SQL packages are created in QRECOVERY and are identifiable by the UBE name such as Rxxxxx.
Changing the SQL Package Library setting to a 1 or 0 is highly recommended during normal operations in order to take advantage of the benefits of SQL packages for UBEs. Note that this setting does not affect the SQL packages created for kernel jobs where the naming convention begins with OW or OW_M (manual commit) followed by the kernel’s unique job number, for example, OW123456. It also does not affect ODBC “fat” client SQL packages which begin with ACTIVCO or printing UBE SQL packages which begin with UBEPRIN.
Prior to the availability of Server Manager for JD Edwards EnterpriseOne, the SQL Package Library is in the JDE.INI file under [DB System Settings]. With Server Manager for JD Edwards EnterpriseOne, this value is configured using the graphical interface as shown in Figure 38.
The path to navigate to this screen is as follows: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne Enterprise Server instance > Under Configuration on the left, click Database Configuration.
Figure 38 - SQL Package Library setting with Server Manager
JD Edwards EnterpriseOne has another setting which relates to SQL package placement for JDBC access. The JAS code creates a separate SQL package in each library it accesses with JDBC when using QZDASOINIT jobs (V3T environment). It is more efficient to use only one SQL package for all JDBC access. Prior to the availability of Server Manager for JD Edwards EnterpriseOne, the AS400 Package Library value was configured by adding a new setting in the JDBj.INI to force all JDBC access to use a single library for storing SQL packages:
The above setting adds the JAS SQL packages to the same library already used by the JD Edwards EnterpriseOne kernel jobs.
With Server Manager for JD Edwards EnterpriseOne, this value is configured using the graphical interface as shown in Figure 39. The path to navigate to this screen is as follows: Access Server Manager (which displays the Management Dashboard) > Click on the Managed Home Location for the desired environment > Click on the desired EnterpriseOne HTML Server instance > Under Runtime Metrics on the left, click the link to JDBj Runtime Properties.
Figure 39 - AS400 Package Library setting with Server Manager
Whenever a Java serialized object generation has been run, the SQL package JDBJxxx (where xxx is a system-generated suffix, typically 899) is either created or updated. After every generation, delete this SQL package, because it contains installation-specific information that is not necessary for normal web client sessions.
Packages must be deleted when the underlying metadata for statements stored in the package has been changed. If a table, view, stored procedure, or other SQL object is altered, information in the package may not be updated. Therefore, JD Edwards EnterpriseOne SQL packages should be deleted whenever significant changes have been made to the database, operating system, or hardware. Examples of significant changes are those that may cause a large amount of access plan rebuilds, such as applying a database group PTF, upgrading the operating system, or applying a JD Edwards EnterpriseOne Electronic Service Update (ESU) when it contains table changes. Although not required, it may also be useful to delete SQL packages when indexes are created or deleted. Deleting SQL packages can also be made a part of a routine maintenance schedule. Because any user SQL package that is needed is recreated when the JD Edwards EnterpriseOne application services are started, there is little functional risk in deleting them but it will degrade performance as statement and access plan data must be rebuilt.
As stated earlier, JD Edwards EnterpriseOne kernel jobs use SQL packages beginning with OW or OW_M created in the QRECOVERY library. Each time the enterprise server is ended and restarted, new SQL packages are built and associated with the new kernel jobs. Old SQL packages associated with kernel jobs that have ended are never used again and can be deleted to save disk space.
Many customers delete SQL packages based on concerns of reaching the maximum size which defaults to approximately 500 MB. If this is a concern for this environment, consider using the SQL_INCREASE_PKG_LIMIT value which allows them to grow to approximately 1 GB. The procedure for implementing this value is documented in an IBM informational APAR which can be found using the URL listed in Appendix D.
There are two alternative techniques for deleting SQL packages. The first is based on SQL package names and the second is based on SQL package ownership. This first technique can be used with a good understanding of what SQL packages exist in the specific environment and if there is a low risk for deleting SQL packages used by other applications or used by DRDA programs for remote access. To delete SQL packages by name when enterprise services are down, the following commands can be used. The same commands can also be used as part of a scheduled maintenance.
The following command can be used to delete the SQL packages that are not normally reused and take up disk storage: DLTSQLPKG SQLPKG(QRECOVERY/OW*)
The following commands can be used to deleted the SQL packages that are created after installing, upgrading, or generating Java serialized objects: DLTSQLPKG SQLPKG(QRECOVERY/JDBJ*) DLTSQLPKG SQLPKG(QRECOVERY/T*)
When metadata has changed, delete additional SQL packages using these commands: DLTSQLPKG SQLPKG(QRECOVERY/R*) DLTSQLPKG SQLPKG(*ALL/ACTIVCO*) DLTSQLPKG SQLPKG(*ALL/UBEPRIN*)
Never delete SQL packages starting with the letter “Q” as they are used by the system. If JD Edwards EnterpriseOne is unable to connect to the server, verify that the SQL package QSQXDPKG in QSYS still exists. If not, a service provider must be contacted to correct the problem.
The alternative technique applies to the same SQL package names but is safer as it reduces the risk of deleting any SQL packages that do not belong to the JD Edwards EnterpriseOne environment. Use the Work with Objects by Owner (WRKOBJOWN) command to display all objects owned by the user profiles JDE and ONEWORLD. Within the list, option 4 can be used to delete the desired SQL packages.
5) Apply any recommended SQL settings
There are two settings that should only be applied when they have been recommended by IBM, Oracle, or a JD Edwards EnterpriseOne service provider.
The SQL Optimizer component of DB2 for i5/OS has an option to optimize SQL statements in one of two ways. An optimization goal of *FIRSTIO instructs the optimizer to optimize the statement to return the first result as quickly as possible. The typical scenario for *FIRSTIO is a transaction where a user is waiting for the first result to be returned. An optimization of *ALLIO optimizes the statement to return all the results as quickly as possible. The typical scenario is for a report where the goal is to generate the entire report as quickly as possible. Oracle frequently recommends specifying *ALLIO for UBEs and *FIRSTIO for web client workload. Applying these settings to specific environments can also cause performance degradations so determining the correct settings is beyond the scope of this document.
With V5R2, DB2 for i5/OS started delivery of an enhanced optimizer for SQL statements. It is called the SQL Query Optimizer (SQE) while the previous support is called the Classic Query Optimizer (CQE). In general, SQE will provide better optimization than CQE. In some cases, Oracle recommends an option called Ignore Derived Index which allows more SQL statements to be processed by SQE rather than CQE. Specifically, it instructs the optimizer to ignore the existence of any indexes or logical files which
are incompatible with SQE. This has the potential for degrading performance because it may force the optimizer to implement SQL statements without the use of optimal indexes.
These parameters are generally specified using the QAQQINI file which is used to configure DB2 support. The QAQQINI options file can be specified at the system level or for specific jobs. By default, all jobs on the system look for a QAQQINI file in the library QUSRSYS. The Change Query Attributes (CHGQRYA) command can be used to provide a different library where the job should look for the QAQQINI file. If there is not one present, SQL runs with default processing options. The QAQQINI in the library QSYS is a prototype version provided by IBM. It is not used by default and IBM recommends that it not be used or updated. The library list is never used to search for a QAQQINI file. Because both of the QAQQINI parameters described above have the potential to degrade performance, they should only be applied when recommended by Oracle or another service provider. In that case, instructions will be provided on how to specify them correctly for the environment.
6) SQL Server Mode Considerations
Starting with EnterpriseOne Tools 8.95_N1 and SP23_QC or SP23_R1, EnterpriseOne defaults to turning on SQL Server mode. Essentially, this moves SQL processing from the requesting job to background QSQSRVR jobs which provides added function and application flexibility. This was done for four reasons:
1. JD Edwards EnterpriseOne Tools releases 8.96 and 8.97 include support for multi-threaded Call
Object Kernels as described above. If the singleThreadedMode value is set to ‘N’, SQL Server Mode will be used.
2. Vertex version 3.2.23 requires SQL Server Mode. Note to JDE reviewers: I’ll need the exact references for Vertex versions. We also talked about 2.9.0 for another version.
3. The metadata kernel which helps manage access to the new XML spec format requires SQL Server Mode. This applies only to environments running both EnterpriseOne 8.12 Application and 8.96 or 8.97 Tools.
4. JDBNET kernels which provide access to DB2 on System i from a platform that doesn't have a native driver, for example Sun requires SQL Server Mode. Note that this consideration applies only if System i is the database server for a platform other than System i.
If SQL Server Mode has been enabled, the i5/OS job log of any JDE Call Object Kernel or other JDE jobs such as UBEs will contain SQL7908 messages which indicate which job is actually performing the SQL operations: For example, “Job 020573/QUSER/QSQSRVR used for SQL server mode processing”
Because of the use of server mode, the SQL processing that was normally done in the front end job (e.g. a UBE job) is now done by one or more QSQSRVR back end jobs. For resources such as processor and disk, this makes no difference to tuning procedures. QSQSRVR jobs in the idle state show a run priority value of 20 but they “inherit” the run priority of the invoking job when they are active. There are however some tuning procedures which may need to be revised based on the use of SQL Server Mode.
First, memory resources may need to be evaluated because QSQSRVR jobs run by default in the *BASE pool which may be different from where the invoking job runs. For example, an environment may have a separate shared pool that is used only for UBE execution. If SQL Server Mode is active, the QSQSRVR jobs will run in the *BASE pool which may not have been configured optimally for this workload. If there is an issue with excess paging due to QSQSRVR jobs, the following steps show how to configure them to use a different memory pool.
• Change the QSYSWRK subsystem description to add a second pool. This can either be a private pool or a shared pool, this example uses a shared pool: CHGSBSD SBSD(QSYSWRK) POOLS((1 *BASE) (2 *SHRPOOLn))
• Change the prestarted job entry for QSQSRVR to indicate that they should run in the pool just defined: CHGPJE SBSD(QSYSWRK) PGM(QSQSRVR) POOLID(2)
• Stop and restart the QSQSRVR jobs using the End Prestart Jobs (ENDPJ) and Start Prestart Jobs (STRPJ) commands.
• Monitor the faulting rates and activity levels in the new pool to ensure that is configured optimally. Alternatively, automatic adjustment of the memory pool can be activated using the QPFRADJ system value and the WRKSHRPOOL command as discussed previously in this document.
The second difference in tuning procedures comes from the use of QAQQINI files to configure SQL processing options. If the only QAQQINI file being used in QUSRSYS, it will be used by both the front end jobs and the back end QSQSRVR jobs. If however a specific QAQQINI file was configured for particular jobs such as UBEs, this QAQQINI file would not be used by the QSQSRVR back end jobs which could impact performance. The only generally available solution is to reconfigure to use a single QAQQINI file in QUSRSYS. IBM is also evaluating changes to i5/OS V5R4 which allow QSQSRVR jobs to inherit the QAQQINI attributes of the front end job. If these changes become available, they will be identified in the IBM informational APAR which can be found using the URL listed in Appendix D.
The third difference in tuning procedure is related to the use of the database monitor. Because the SQL processing for a job is done by QSQSRVR jobs rather than inline, any database monitors must include the QSQSRVR job(s) in addition to the base jobs such as UBE’s. When analyzing database monitor output from an environment in which SQL Server Mode is being used, the column qqc103 in the monitor output can be used to see which SQL operations were done by a QSQSRVR job on behalf of a UBE job. This technique is effective primarily for UBEs because of the convention that the SQL Package name corresponds to the name of the UBE. Another alternative to analyzing database monitor output is to use the SQL7908 messages described above to identify which QSQSRVR job(s) did work on the behalf of a front end job.
TCP/IP Settings Depending on network, or line, speed, TCP/IP performance can often be improved by setting larger send/receive buffers. The TCP/IP attributes for the send and receive buffer sizes ship with the defaults set to 8192 bytes. These defaults correspond to an Ethernet line speed of 10 million bits per second. Set the TCP/IP attributes to 65536 if line speed is 100 million bits per second in full duplex mode to speed up performance, especially in a V3T environment. Similarly, change the buffers to 1048576 if line speed is 1 gigabit per second with duplex set to *auto detect. The changes take effect immediately. An example from the i5/OS command line is: DSPLIND <Ethernet line name> to determine line speed and duplex characteristics. CHGTCPA TCPRCVBUF(65536) TCPSNDBUF(65536). As always, these changes need to be tested and evaluated for each environment.
Appendix A – Software and Hardware Levels All tests were performed using i5/OS V5R4. It is highly recommended that a production environment be kept current with the JD Edwards EnterpriseOne Informational APAR. The “InfoAPAR” is a list of required PTFs by operating system version maintained by IBM for JD Edwards EnterpriseOne (and JD Edwards World) products. The link below contains links to the Informational APARs for V5R4, V5R3 and V5R2: ibm.com/servers/enable/site/events/jde_links.html
Tests were conducted with both All-In-One (AIO) and Virtual Three Tier (V3T) environments. An overview of the components on each system is shown in Figure 40 and Figure 41 below.
AdminConsole
9060
HTML Clients
“All In One Box”V5R4, EnterpriseOne Release 8.12, WebSphere 6.0, HTTP
Appendix B – Configuration Files Following are the configuration files for HTTP and the JAS and enterprise servers. (The WebSphere configuration settings are edited through the Administrative Console, which does not offer a file listing.) The AIO environment is configured for 200 users.
HTTPD.CONF WebSpherePluginConfig /QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/config/cells/DENI502/nodes/IHS_DENI502_WASHTTPSVR_node/servers/IHS_DENI502_WASHTTPSVR/plugin-cfg.xml LoadModule was_ap20_module /QSYS.LIB/QWAS6.LIB/QSVTAP20.SRVPGM # Configuration originally created by Create HTTP Server wizard on Mon Aug 21 13:11:53 MDT 2006 Listen *:88 DocumentRoot /www/washttpsvr/htdocs Options -ExecCGI -FollowSymLinks -SymLinksIfOwnerMatch -Includes -IncludesNoExec -Indexes -MultiViews #LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined #LogFormat "%{Cookie}n \"%r\" %t" cookie #LogFormat "%{User-agent}i" agent #LogFormat "%{Referer}i -> %U" referer #LogFormat "%h %l %u %t \"%r\" %>s %b" common #CustomLog logs/access_log combined Loglevel Error MaxKeepAliveRequests 0 KeepAlive On ThreadsPerChild 40 LogMaint logs/access_log 7 0 LogMaint logs/error_log 7 0 SetEnvIf "User-Agent" "Mozilla/2" nokeepalive SetEnvIf "User-Agent" "JDK/1\.0" force-response-1.0 SetEnvIf "User-Agent" "Java/1\.0" force-response-1.0 SetEnvIf "User-Agent" "RealPlayer 4\.0" force-response-1.0 SetEnvIf "User-Agent" "MSIE 4\.0b2;" nokeepalive SetEnvIf "User-Agent" "MSIE 4\.0b2;" force-response-1.0 <Directory /> Order Deny,Allow Deny From all </Directory> <Directory /www/washttpsvr/htdocs> Order Allow,Deny Allow From all </Directory> NameVirtualHost DENI502:88 <VirtualHost DENI502:88> Alias /jde /QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/installedApps/DENI502/EA_JS_88.ear/webclient.war </VirtualHost> <Directory /QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/installedApps/DENI502/EA_JS_88.ear/webclient.war> Order Deny,Allow Allow From all </Directory> <Directory /QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/installedApps/DENI502/EA_JS_88.ear/webclient.war/WEB-INF> Order Deny,Allow Deny From all </Directory>
JAS.INI # Please refer to the JAS Installation Guide for detailed information on # this file. [SECURITY]
DataSource=System - 812 SecurityServer=DENI502 UseLogonCookie=FALSE CookieLifeTime=7 SSOEnabled=FALSE SSOUserIDOnly=FALSE # set password only if SSOUserIDOnly is set to TRUE Password= #Version Security level for task explorer - 0 is default, set to 1 for strict version security StrictVersionSecurity=0 [OWWEB] PathCodes=('PD812') MO QUEUE=webclient.war/moqueue MAXUser=200 UseMOWinNTShare=FALSE SystemDateFormat=MDE SystemDateSeparator=/ ShowSubmitJobs=TRUE AutoPopulate=ON AutoPopulateBufferSize=50 # The HelpPath key determines where JAS looks for help files. # Syntax: "http://[machine]/[path]/". # Note, if you specify "/jde/owhelp/", this machine is assumed. HelpPath=/jde/owhelp/ PPCSetDefaultFocus=FALSE # Library Name for the AS/400 STRJOURNAL stored procedure # auto resume interval for fetch update dialogs, in milliseconds TimeWaitBeforeAutoResume=1000 # Global Page size for grids. # This setting overrides the application level page size when the application level page size is smaller # than this setting. # Valid values are from 0 to 100. When this value is greater than 100, the Global Page size will be set # to 100. # The default value is 0, which will never override application level page size. GlobalPageSize=0 # the default section size for "go to end" functionalilty # if there are more than 60 visible columns on the grid, the system will reduce this section size by 50%. SectionSize=200 [CACHE] # These intervals are in milliseconds. For example, 60000ms = 1 minute UserSession=2400000 CacheCheck=60000 [SERVER COMPONENTS] # Do not modify this section com.jdedwards.runtime.virtual.MAFComponentLoader com.jdedwards.jas.UserManager com.jdedwards.jas.JDBCProxy com.jdedwards.jas.JDEORB com.jdedwards.jas.DDValidation com.jdedwards.jas.security.SecurityBroker com.jdedwards.jas.UDCJDBC com.jdedwards.jas.JDEUDCText com.jdedwards.jas.JDEUpdates com.jdedwards.jas.JDEQueries com.jdedwards.jas.JDEOWDirect com.jdedwards.jas.ServerQuery com.jdedwards.jas.JDESignon com.jdedwards.jas.PerfMonInit [JDENET] # Enterprise Server JDENET port serviceNameConnect=6014 # JAS Server JDENET Listening port serviceNameListen=6014 # Maximum number of dedicated kernel types maxKernelRanges=1 maxPoolSize=200 # Time out value for requests sent to the Enterprise Server enterpriseServerTimeout=90000
# Directory for JDENET temporary file tempFileDir=webclient.war/temp # Clustered logical datasource retry interval ClusterRetryInterval=60000 # Dedicated Kernel Definitions [JDENET_KERNEL_DEF1] krnlName=XAPI Kernel processClassName=com.jdedwards.runtime.virtual.xapi.PublishedMessageProcessor startMessageRange=15001 endMessageRange=15250 maxNumberOfThread=3 [SERVER] # Enterprise Server and port providing Glossary Text information glossaryTextServer=DENI502:6014 # Encoding scheme # 1252- English and Western European # 932- Japanese # 950- Traditional Chinese # 936- Simplified Chinese # 949- Korean codePage=1252 #per application team, set the default setting to true. This will impact the #performace negatively, change it back to false if jargon is not needed #enableJargon=TRUE enableJargon=FALSE jargonCacheTimeout=360000 [LOGS] #stdout=/QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/logs/AS_JS_88/SystemOut.log #stderr=/QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/logs/AS_JS_88/Systemerr.log # The STDERR and STDOUT keys must point to the same directory that was supplied for the # STDERR and STDOUT fields when defining the WebSphere Application Server. # This is usually the INTERNET directory under B7333. #stderr=~LOG_DIR~/logs/stderr.txt #stdout=~LOG_DIR~/logs/stdout.txt WebServerErrLog=/QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/logs/AS_JS_88/Systemerr.log WebServerOutLog=/QIBM/UserData/WebSphere/AppServer/V6/Base/profiles/default/logs/AS_JS_88/SystemOut.log [TRANSACTIONS] # Configuration settings to customize transaction processing within JAS. # ReapInterval : Interval in minutes of how often the TransactionReaper # should check for abandoned transactions. # Valid values: Integer from 1 to n # Default: 5 minutes # MaxAge : Maximum age in minutes of a transaction. Transactions # older than this will be rolled back by the # TransactionReaper. # Valid values: Integer from 1 to n # Default: 10 minutes ReapInterval=5 MaxAge=10 [ERPINTERACTIVITY] #interactivity level. valid values are: LOW, MEDIUM, and HIGH InteractivityLevel=HIGH # whether multiple browsers fetch is enabled MultipleBrowserEnabled=FALSE # the maximum number of open browsers for each user MaxOpenBrowsers=10 # the number of records fetched for each database fetch before getting a system warning DBFetchLimitBeforeWarning=2000 [TASKEXPLORER] Version=2 [PIM Sync] # Synchronization super user information. # This user information is used as a proxy user to create sessions to EnterpriseOne for all the users # synchronizing CONTACTS, APPOINTMENTS, and TASKS. # This user must have full access to the CONTACTS, APPOINTMENTS, and TASKS database. # MUST BE CHANGED to match installation
user=PSFT password=PSFT environment=ENV role=*ALL # Session pool size # A session represents a connection (i.e. signon) to EnterpriseOne. # All the session in the pool will be created using the synchronization super user information. # It is recommended to set this number to match the number of CallObject kernels on # the EnterpriseOne Enterprise Server. poolSize=20 # Synchronization business function names, update this after APP. Devlelopment finalized # DO NOT CHANGE contactBSFN=PIMSynchronize appointmentBSFN=PIMSynchronize taskBSFN=PIMSynchronize # trace request/response XML to JASDEBUG, true is on, false is off showXML=false # trace request/response XML to stdout, true is on, false is off verbose=false [EVENTS] # The InitialContextFactory and JNDI provider URL for the event server's JNDI service. initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory jndiProviderURL=corbaloc:iiop:localhost:2809 #Specify the Mail Merge Location on Web Server, it should be under the webclient dir. [MAIL MERGE AND DOC GEN] MailMergeLocation=webclient.war/MailMerge #Specify the necessary settings from the readme file created by the installation #of the Transaction Server Component - Performance Monitor [PERFMON] # URL of Performance Monitor. Used by instrumented code to register with # Performance Monitor. monitorUrl=none # PerfMon Pool size ClientPerfCacheSize=100 # Identifier for source of performance data. hostPort= # Transaction will be timed out by Monitor server if end transaction is not # received this number of milliseconds after the start transaction. transactionTimeout=60000 # Not currently being used. sampler=60
JDBj.INI #======================================================================= # jdbj.ini - JDBj configuration # # This file contains configuration information for JDBj, which provides # general database access capabilities on behalf of J.D. Edwards Java # solutions. # # IMPORTANT: All keys in this file are case sensitive. #======================================================================= #======================================================================= # ERP specific information # # These sections apply only when accessing ERP data. These sections are # ignored for standalone database access. #======================================================================= #----------------------------------------------------------------------- # Bootstrap session # # The user, password, role information is optional. It is used by the # the JDBJ Unit tests and JDBExplorer only if these parameters are not # specified on the command line. The environment is required field otherwise # JAS cannot signon to the HTML client. # # NOTES: * This information in this section corresponds to the information # specified in the [DB SYSTEM SETTINGS] section of this installation's # JDE.INI file.
#----------------------------------------------------------------------- [JDBj-BOOTSTRAP SESSION] user=JDE password=JDE environment=PD812 role=*ALL #----------------------------------------------------------------------- # Bootstrap physical data source # This defines the data source where the OCM and some other system # tables reside. JDBj uses this at bootstrap time and later to look up # OCM entries on demand. If it is not valid, then no ERP database # access is possible. # Here is a description of each field in this section: # ---------------- --------------------------------------- ----------- # Field Description Applies to # ---------------- --------------------------------------- ----------- # name The data source name. This is not that All # important for bootstrap connections, # but it does show up in error messages # and the log. # ---------------- --------------------------------------- ----------- # databaseType The database type. One of the All # following: # # I = AS/400 # O = Oracle # S = SQL Server # W = UDB # M = MSDE # ---------------- --------------------------------------- ----------- # server The server (i.e. the host), or AS/400, # "localhost". SQL Server # MSDE # ---------------- --------------------------------------- ----------- # database The database. Oracle,UDB # ---------------- --------------------------------------- ----------- # serverPort The server port. SQL Server # ---------------- --------------------------------------- ----------- # physicalDatabase The physical database (used as library AS/400, # qualifier for AS/400). SQL Server, # MSDE # ---------------- --------------------------------------- ----------- # owner The owner. Oracle, # SQL Server, # UDB, # MSDE # ---------------- --------------------------------------- ----------- # lob Supports lobs. Oracle, # # AS/400 # ---------------- --------------------------------------- ----------- # unicode Performs unicode conversion. SQL Server # MSDE # ---------------- --------------------------------------- ----------- # databaseInstance The instance name of server. (JDELocal) MSDE # ---------------- --------------------------------------- ----------- # translateOn AS400 translate on (default is FASLE) AS400 # ---------------- --------------------------------------- ----------- #----------------------------------------------------------------------- # # NOTES: * This information in this section should match the # corresponding information specified in the # [DB SYSTEM SETTINGS] section of this installation's JDE.INI # file. #----------------------------------------------------------------------- [JDBj-BOOTSTRAP DATA SOURCE] name=System - 812 databaseType=I server=DENI502
serverPort= database= physicalDatabase=SY812 owner= lob=false unicode=true databaseInstance= translateOn= #----------------------------------------------------------------------- # Bootstrap spec data source (Optional) # This defines the data source where the serialized spec tables reside. # JDBj uses this at bootstrap time and after to look up serialized spec # objects on demand. JDBj first looks for the name specified in this # section in the Data Source Master table (F98611). If it finds a data # source there, it uses it to read the serialized spec tables. If it # does not find the data source in the Data Source Master table, then # it initializes a new data source based on the rest of the fields in # this section. # # If this section is not specified, then JDBj uses the OCM to find the # serialized spec tables. If it is not valid, then no ERP database # access is possible. # # See the description for "Bootstrap physical data source" above for # information about which fields must be filled in for a given database # platform. #----------------------------------------------------------------------- # [JDBj-SPEC DATA SOURCE] # name= # databaseType= # server= # serverPort= # database= # physicalDatabase= # owner= # lob=false # unicode=true # user= # password= # databaseInstance= # translateOn= #======================================================================= # END - ERP specific information # # The rest of the sections apply when accessing ERP and standalone data. #======================================================================= #----------------------------------------------------------------------- # JDBC drivers # # This defines JDBC drivers and JDBC specific settings. #----------------------------------------------------------------------- [JDBj-JDBC DRIVERS] ORACLE=oracle.jdbc.driver.OracleDriver AS400=com.ibm.as400.access.AS400JDBCDriver SQLSERVER=com.microsoft.jdbc.sqlserver.SQLServerDriver UDB=COM.ibm.db2.jdbc.app.DB2Driver [JDBj-ORACLE] tns=tnsnames.ora [JDBj-LOGS] jdbcTrace=false [JDBj-SERVER] dbcsConversionTolerant=true #----------------------------------------------------------------------- # Connection pool settings #----------------------------------------------------------------------- [JDBj-CONNECTION POOL] minConnection=5 maxConnection=200 initialConnection=5
poolGrowth=10 ; The minimum number of connections to a data source. When closing old connections, ; the value set by this parameter will remain in the pool regardless of use. ; Valid values: 0 or greater ; Default value: 5 #minConnection=5 ; The maximum number of connections to a data source for all users. Additional ; database connection requests beyond this value will be queued for the next available ; connection. ; Valid values: 1 or greater (must be equal to or greater than "minConnection") ; Default value: 50 #maxConnection=50 ; The number of connections to initialize upon pool creation. ; Valid values: a value equal to or greater than "minConnection" AND equal to or ; less than "maxConnection" ; Default value: 5 #initialConnection=5 ; The increment of connections the system will create when a request for a connection ; cannot be satisfied with the current allocation as long as the maxConnection value ; has not been reached. ; Valid values: The rule of thumb is (poolGrowth >= maxConnection/10) ; Default value: 5 #poolGrowth=5 ; Amount of time in milliseconds that a connection remains idle before it is flagged ; to be cleaned up. Keeping this value high may or may not add to performance. Reducing ; the value may reduce memory consumption. ; Valid values: 0 or greater ; Default value: 1800000 (30 minutes) connectionTimeout=1800000 ; Amount of time in milliseconds that the pool cleaner is set to clean data sources ; that have a validation string. When cleaning occurs, any connections which have been ; flagged as idle will be cleaned up. The amount of time between a connection ; becoming idle and being cleaned up can be as long as the connectionTimeout value plus ; the cleanPoolInterval value. ; Valid values: 0 or greater ; Default value: 600000 (10 minutes) cleanPoolInterval=600000 ; The maximum number of JDBC prepared statements cached on each JDBC connection. ; Valid values: 0 or greater ; Default value: 50 maxSize=50 ; The number of JDBC statements purged from a JDBC connection if the maxSize limit is ; reached. The statements purged will be the statements in the cache which have not ; been used for the longest amount of time. ; Valid values: The rule of thumb is (cachePurgeSize >= maxSize/10 + 2) ; Default value: 5 cachePurgeSize=5 #----------------------------------------------------------------------- # JDBj Runtime properties # These are all optional. They correspond to system runtime properties # applicable to JDBj logical connections. # # NOTES: * In each case, the values listed are the defaults. The # template default entries are commented out. Make sure # and remove the pound sign (#) when changing these values. #----------------------------------------------------------------------- [JDBj-RUNTIME PROPERTIES] ; AS400 Database ASP property. Use this setting if you are running your iSeries ; server with multiple user databases or IASP (Independent Auxiliary Storage Pool) ; and have your EnterpriseOne tables located on the IASP. The IASP name can be found ; by using the command WRKRDBDIRE. This entry is not needed if you only have *LOCAL ; configured on your system in the WRKRDBDIRE Remote Location name. ; Valid values: Any valid string # AS400DatabaseASP=null ; AS400 package name property. Overrides the default sql package ; name on the AS400 with the specified name. ; Valid values: Any valid string # as400Package=JDBj ; AS400 package library name property. Overrides the default sql package
; library name on the AS400 with the specified name. ; Valid values: Any valid string # as400PackageLibrary=JDBj-Library, added 9/26/06 as400PackageLibrary=QRECOVERY ; AS400 extended dynamic property. Overrides the default extended dynamic ; setting with the specified setting. If specified to a false, AS400 database ; will not use packages. This will have a negative impact on performance. ; Valid values: true, false # as400ExtendedDynamic=true ; Data cache entry size threshold property. Sets the maximum ; size (in rows) for a single entry in the data cache. If a ; potential entry exceeds this threshold, then it will not be ; cached. -1 indicates that all eligible entries should be ; cached. ; Valid values: -1 or greater # dataCacheEntrySizeThreshold=500 ; Data cache entry threshold property. Sets the maximum size (in ; entries) for the data cache. If the data cache exceeds this ; size, then the least recently used entries are removed to ; make room for the new entry. -1 indicates that there is no ; maximum. ; Valid values: -1 or greater # dataCacheEntryThreshold=100 ; Data varification property. Enable or disable the data verification ; between actual data and EnterpriseOne specification for insert and ; update operations. ; The verification is performed on the following types: ; - EVDT_CHAR ; - EVDT_STRING ; - EVDT_NID ; - EVDT_TEXT ; - EVDT_VARSTRING ; - EVDT_VARCHAR ; - EVDT_MATH_NUMERIC ; This property will have a negative impact on performance. ; Valid values: true or false # dataVerification=false ; Oracle NCHAR Trimming property. Indicates if the Oracle NCHAR ; Trimming logic is turned or off. True means the returned NCHAR ; data is intact. False means always right trim the returned ; NCHAR data. ; Valid values: true or false # disableOracleNcharTrimming=false ; E1Menu cache purge property. Sets the number of ; milliseconds after which inactive spec cache entries are ; purged. 0 means to never purge spec cache entries. ; Valid values: 0 or greater # E1MenuCachePurge=3600000 ; Force single data source property. Indicates whether JDBj ; should force operations involving multiple database objects to ; run against a single data source. If this is true, JDBj will ; only resolve the physical data source for the first database ; object involved in a given operation. Otherwise, JDBj will ; resolve physical data sources for all database objects and ; throw an exception if a single operation spans multiple data ; sources. ; Valid values: true, false # forceSingleDataSource=false ; Result set timeout property. Sets the the number of ; milliseconds for the result set timeout. A result set will ; timeout if it has not had any operations for a period of time. ; -1 means that result sets will not timeout. ; Valid values: -1 or greater # resultSetTimeout=60000 ; Retry interval property. Sets the interval (in milliseconds) ; to wait before retrying idempotent database operations. -1 ; means not to retry, 0 means retry immediately. ; Valid values: -1 or greater # retryInterval=0
; Retry maximum property. Sets the number of times to retry ; idempotent database operations. -1 means to retry ; indefinitely. ; Valid values: -1 or greater # retryMaximum=5 ; OCM cache purge property. Sets the number of ; milliseconds after which inactive OCM cache entries are ; purged. 0 means to never purge OCM cache entries. ; Valid values: 0 or greater # ocmCachePurge=3600000 ; Personal Spec Versions property. Indicates if user's personal ; version can be read. This is only enforced during a read and not ; during a spec generation. If it set to a true, the personal version ; will be returned if it exists, otherwise the public version will be ; returned. If the property is set to a false, then the personal ; version will not even be read and we will default to the public ; Valid values: true , false # personalSpecVersions=false ; Service cache purge property. Sets the number of ; milliseconds after which inactive service cache entries are ; purged. 0 means to never purge service cache entries. ; Valid values: 0 or greater # securityCachePurge=3600000 ; Service cache purge property. Sets the number of ; milliseconds after which inactive service cache entries are ; purged. 0 means to never purge service cache entries. ; Valid values: 0 or greater # serviceCachePurge=3600000 ; Spec cache purge property. Sets the number of ; milliseconds after which inactive spec cache entries are ; purged. 0 means to never purge spec cache entries. ; Valid values: 0 or greater # specCachePurge=3600000 ; Spec consistency check property. Sets the level of spec ; consistency checking. Set this property to a higher level to ; improve exception messages relating to spec inconsistency ; problems. Set this to a lower level when it is not needed ; since it may degrade performance. ; Valid values: full, minimal, none # specConsistencyCheck=minimal ; Spec generate on demand property. Indicates whether JDBj ; should generate specs on demand if it can not find them ; in the persistent cache. ; Valid values: true, false # specGenerateOnDemand=false ; Transaction isolation property. Sets the isolation level to be ; used for transactions. ; Valid values: default, none, read uncommitted, read committed, ; repeatable read, serializable # transactionIsolation=default ; Transaction timeout property. Sets the number of milliseconds ; for the transaction timeout. A transaction will timeout if it ; has not had any operations for a period of time. If this ; timeout is set to a -1 then the transaction timeout feature ; will be disabled. (This currently only happens when JDBj is ; run as part of a JAS transaction.) ; Valid values: -1 or greater # transactionTimeout=120000 ; Trigger auto fetch property. Indicates whether JDBj should ; automatically fetch rows to be changed in order to pass them ; to ERP triggers. This is needed for certain triggers to ; work properly. ; Valid values: none, single, all # triggerAutoFetch=none ; Updatable result set timeout property. Sets the the number of ; milliseconds for the updatable result set timeout. An ; updatable result set will timeout if it has not had any ; operations for a period of time. -1 indicates that updatable ; result sets should have the same value as RESULT_SET_TIMEOUT.
; Valid values: -1 or greater # updatableResultSetTimeout=-1 ; Usage execution threshold property. Sets the expected maximum ; time (in milliseconds) for a single database operation to ; execute. If a single database operation takes longer than this ; threshold, then the statement and time will be logged as part ; of usage tracking. ; Valid values: 0 or greater # usageExecutionThreshold=20000 ; Usage fetch size threshold property. Sets the expected maximum ; fetch size (in rows) for a single fetch to return. If a single ; fetch returns more than than this threshold, then the actual ; fetch size will be logged as part of usage tracking. -1 ; indicates that any fetch size is valid. ; Valid values: -1 or greater # usageFetchSizeThreshold=500 ; Usage result set open threshold property. Sets the expected ; maximum time (in milliseconds) for a result set to remain ; open. If a result set is left open longer than this threshold, ; then the result set and time will be logged as part of usage ; tracking. This does not automatically close the result set. A ; usage result set open threshold value of -1 indicates that no ; such usage tracking will occur. ; Valid values: -1 or greater # usageResultSetOpenThreshold=60000 ; Usage tracking property. Enables or disables usage tracking. ; This provides additional tracking and logging to use during ; testing. Usage tracking does incur a performance penalty so it ; should be disabled for production code. ; Valid values: true, false # usageTracking=false ; Usage tracking output property. Specifies the destination of ; usage tracking output. ; Valid values: log, exception # usageTrackingOutput=log ; Usage transaction active threshold property. Sets the expected ; maximum time (in milliseconds) for a transaction to remain ; active. If a transaction is left active longer than this ; threshold, then the transaction and time will be logged as ; part of usage tracking. This does not automatically rollback ; the transaction. A usage transaction active threshold value of ; -1 indicates that no such usage tracking will occur. ; Valid values: -1 or greater # usageTransactionActiveThreshold=120000 ; Maximum number of parallel application generators. ; Controls how many serialized JAVA application ; objects can be generated at one time. ; For a low-power server, use a lower value. ; For a high-power server, use a higher value. ; valid values: 1 or greater # ParallelAppGens=10 #======================================================================= # END OF FILE #=======================================================================
agentActive=false # URL of Performance Monitor. Used by instrumented code to register with # Performance Monitor. monitorUrl= # Identifier for source of performance data. hostPort= # Time to wait for response from E1 Java Adapter (Java Kernel) jdenetTimeout=60 # Transaction will be timed out by Monitor server if end transaction is not # received this number of milliseconds after the start transaction. transactionTimeout=60000 # Not currently being used. sampler=60 # Maximum number of Java Adapters (Java Kernels) maxJavaAdapter=1 # Default filter level used by the agent for all transactions. filterMask=1 [PERFMON_JAVA_ADAPTER_1] # Name of machine where Java Adapter is running. javaAdapterHost= # Port on which Java Adapter is communicating; should be the same as # the [JDENET] serviceNameListen value used by the E1 Transaction Server. javaAdapterPort= [JDE JVM] # Settings governing the usage of the in-process JVM inside of E1 processes. # The JVM is used primarily to support XML specs but would be used for any # Java code run inside of an E1 process. JDK 1.4 must be installed on # this ISeries for Enteprise One to function. JDK 1.4 is a part of the OS V5R2 # and later. # Class path for the JVM will be constructed using all the .jar files contained # in the <system library>/classes directory. It is possible to prepend # items from other locations to the class path by setting the 'CLASSPATH' attribute # in the [JDE_CG] section. [METADATA] # There are some parts of metadata objects that are stored in the Object Librarian data source and are # retrieved after the metadata object is deserialized from XML. This data is not needed during normal # runtime processing and to improve performance should be turned off. # '0' - Do not retrieve data from Object Librarian data source when deserializing metadata. # '1' - Retrieve data from Object Librarian data source and fully populate metadata objects when deserializing # metadata. AllCPopulationEnabled=0 UseServerForConversion=0 #0 is default and means use inline JVM processing rather than sndmsg to metadata kernel to jvm work [TRUSTED NODE] numTrustedNodes=1 RegularLifeTime=5760 ExtendedLifeTime=5760 NodeName=_LOCALNODE MachineName=_LOCALNODE NodePassword=_LOCALPWD
The huge growth in data processing capabilities on the System i5 family of servers along with the introduction of complex e-business applications has astronomically increased the amount of data processed in only a few seconds. iDoctor for iSeries, software and associated services, is key to evaluate the "health" of the system. It automates the analysis of this vast amount of data in a timely manner, which is essential in order to resolve many of today's complex system and application problems. The iDoctor family of products and services includes: Job Watcher, PEX Analyzer, Heap Analysis Tools for Java, and PTDV.
Job Watcher represents an old approach retooled with new technology designed to reduce the dependency on trace data and allow "real time" drill-down of data without an undesirable impact on system performance. PEX Analyzer simplifies the collection and extends the analysis of Performance Explorer (PEX) STATS, PROFILE and Trace capabilities. Both of these tools require licenses that must be purchased separately. iDoctor also provides two additional functions without any need for additional licensing. Heap Analyzer can be used to perform job heap analysis and object profiling (size and identification) over time. PTDV is the Performance Trace Data Visualizer which can be used for processing, analyzing, and viewing Performance Explorer collection trace data residing in PEX database files. For additional information on iDoctor, visit the following URL: https://www-912.ibm.com/i_dir/idoctor.nsf
Oracle’s Performance Workbench
Performance Workbench is an Oracle-created tool which analyzes the content of JD Edwards EnterpriseOne debug log files and produces reports which contain timing and profiling data from JD Edwards EnterpriseOne code. It is widely used by customers, business partners, and Oracle internal developers. The data is based largely on JD Edwards EnterpriseOne business functions and tables. Very large and otherwise unwieldy debug log files can be reduced to manageable statistical summaries which can be used to analyze and troubleshoot JD Edwards EnterpriseOne code. It is downloadable from Oracle Customer Connection as a zip file and runs on a Windows system. Extensive help files with usage examples are included with the tool. For more information visit the URL (userid and password required): http://www.peoplesoft.com/corp/en/iou/performance/perf_workbench.jsp
Server Manager for JD Edwards EnterpriseOne blog http://servermanager.blogspot.com/
Server Manager for JD Edwards EnterpriseOne Guide (user id and password required) http://www4.peoplesoft.com/contdoc.nsf/0/AF435396A0013A9488257387006EE71F?OpenDocument
Oracle Redpapers (userid and password required)
Multithreaded Kernels: Preparing for This Throughput Enhancement and Best Practices Business Function Coding (September 2005)
Platform Configuration Considerations for XML Metadata for JD Edwards EnterpriseOne (January 2006)
“Performance Tuning EnterpriseOne and WebSphere 5.0.2” (February 2005) for non-System i platforms only http://www.peoplesoft.com/corp/en/iou/red_papers/index.jsp
Additional Resources
For additional copies of this document and for other resources like the older, WebSphere 5.0 Tuning Document, IBM eServer iSeries Performance and Tuning Tips for Oracle’s JD Edwards EnterpriseOne 8.10 and 8.11 Web Server, please visit: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs
For additional IBM Redbooks not listed above, please visit http://ibm.com/redbooks
For specific information on JD Edwards Solutions from Oracle on System i, please visit http://www-03.ibm.com/servers/eserver/iseries/solutions/oracle/index.html
For additional information on integrated, collaborative enterprise solutions from IBM and Oracle’s JD Edwards EnterpriseOne, visit ibm.com/solutions/businesssolutions/oracle
References in this document to IBM products or services do not imply that IBM intends to make them available in every country.
DB2, IBM, the IBM logo, iSeries, i5/OS, System i, System i5, Tivoli, and WebSphere are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both:
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates.
Other company, product, or service names may be trademarks or service marks of others.
Information is provided "AS IS" without warranty of any kind.
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.
Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.
All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact the local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction.
Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.
Photographs shown are of engineering prototypes. Changes may be incorporated in production models.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
Visit www.ibm.com/pc/safecomputing periodically for the latest information on safe and effective computing. Warranty Information: For a copy of applicable product warranties, write to: Warranty Information, P.O. Box 12195, RTP, NC 27709, Attn: Dept. JDJA/B203. IBM makes no representation or warranty regarding third-party products or services including those designated as ServerProven or ClusterProven.
This publication was developed for products and services offered in the United States. IBM may not offer the products, services or features discussed in this document in other countries. Information is subject to change without notice. Consult the local IBM representative for information on offerings available in the desired region.
The examples given in this paper are hypothetical examples of how a customer can use the products described herein and examples of potential cost or efficiency savings are not based on any actual case study. There is no guarantee of comparable results. Many factors determine the sizing requirements and performance of a systems architecture. IBM assumes no liability for the methodology used for determining the configurations recommended in this document nor for the results it provides. Any performance data contained in this presentation was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements quoted in this presentation may have been made on development-level systems. There is no guarantee these measurements will be the same on generally-available systems. Some measurements quoted in this presentation may have been estimated through extrapolation. Actual results may vary. Users of this presentation should verify the applicable data for their specific environment.
