This document provides information for tuning the WebServer and NSJSP products on NonStop servers and consists of the following sections:

Transcription

1 Tuning Guide for itp Secure WebServer and NonStop Servlets for JavaServer Pages (NSJSP) on HP NonStop Servers Authors: Neilson Lee, Yi-Tsung Cheng & Ram Ranganathan 12 th October 2004 Introduction The purpose of this white paper is to provide configuration guidelines and tuning information for itp Secure WebServer (WebServer) and NonStop Servlets for JavaServer Pages (NSJSP) on HP NonStop servers. This white paper assumes that the WebServer and NSJSP products have been installed in their default locations (/usr/tandem/webserver and /usr/tandem/webserver/servlet_jsp, respectively). These directories will change, depending on your WebServer and NSJSP installation. This document provides information for tuning the WebServer and NSJSP products on NonStop servers and consists of the following sections: 1. Region Directives 2. File Caching in the WebServer http daemon 3. Caveats of Using Conventional TCPIP and the TCPIP Parallel Library (TCPIP/PL) 4. WebServer Configuration 5. SSL Global Cache Server 6. Mapping Static Content through Filemaps 7. NSJSP Configuration 8. Aligning WebServer and NSJSP or CGI Processes 9. Pre-compiling JSP Programs 10. Configuring Support for Persistent Sessions 11. SQL/MX Nonblocking I/O Support 12. Memory Considerations: Moving QIO to KSEG2 13. New Heap Manager (T1269) 14. Java Heap Setting 15. JVM Tuning for HotSpot 16. Other HP NonStop System Tuning Areas Background Information The WebServer and NSJSP products together provide a platform for deploying multitier distributed web applications. The WebServer provides a full range of services for running an online commercial or informational enterprise on the Web. In addition to basic Web-related services, the WebServer provides access control, enhanced logging, customized error messaging and automatic directory indexing. NSJSP implements the Java Servlets and JavaServer Pages specifications and provides an environment for developing and running Servlet and JSP programs on NonStop Systems. Servlet and JSP programs extend the functionality of web-based applications by providing dynamic content in a web-serving environment. Hewlett-Packard Company

2 NSJSP Introduction NonStop Servlets for JavaServer Pages (NSJSP) is a scalable Java Servlet and JavaServer Pages (JSP) Container based on the Tomcat Container from Apache Software Foundation. NSJSP implements the Java Servlets and the JavaServer Pages specifications. For more details, check your NonStop Servlets for JavaServer Pages (NSJSP) System Administrator s Guide and the itp Secure WebServer System Administrator s Guide. Java Servlets are secure and powerful server-side components that programmatically extend the functionality of a web server. They are essentially simple Java classes implementing Servlet interfaces that are executed by a Java Virtual Machine (JVM) service (called the Servlet Container). JavaServer Pages (JSP) technologies provide a simplified, clean, and fast way to generate dynamic content in a Web environment. JSP programs are a level of abstraction (above Java Servlets), which provide ease in developing applications for the Web without the application developer s knowing any Java language constructs and programming. JSP and Java Servlets are platform- and server-independent technologies that provide for ease in portability and deployment across diverse web-serving environments. Section 1: Region Directives Region directives are a powerful programming construct that allows controlled access to server-side paths (allowed or denied based on the specified options). The specified commands apply to all the URLs matching the specified url-path value. The Region directives are normally specified in the httpd.config file and any other files sourced in by the httpd.config file (users can create configuration files tailored to their environment and use the source command to bring in those files). For example: Region /myprotectedpath/* { Deny } Additionally, Tcl variables can be used in Region directives to vary the access control based on factors like time of day, web client host name, IP address, or any other HTTP header information. However, the cost of Region directives is high and, therefore, can adversely affect performance. HP recommends that you use Region directives with care and only when necessary. Section 2: File Caching in the WebServer http daemon To improve performance, the WebServer enables you to cache file opens, file statistics information, and the actual file contents after they have been accessed. As a result, subsequent file accesses are served from the file cache rather than accessing them all over again from disk. This caching Hewlett-Packard Company

3 improves your overall performance in terms of not only the response time, but also the CPU utilization. Due to the nature of the HTTP protocol, the WebServer has two types of caches: the file statistics information and actual content. The file stats information is mainly used to serve the request headers related to file modifications, such as Last-Modified, If-Unmodified-Since. File stats are retrieved through an OSS call fstat, which then reads the file label. Caching the file stats would eventually reduce the number of I/O operations and improve the overall performance. In the same way, the actual file content is read directly from the disk. Caching the file content reduces the number of disk operations and improves the WebServer s performance. Also, you could achieve the same goal by using the disk cache feature provided by the HP NonStop Disk Process (DP2). The advantage of using the WebServer file cache is that it gives direct control and access to the file caches. If employing only the disk cache, you would have to rely on the discretion of DP2 to determine when to expire a file cache. Additionally, performance would depend on how many other applications are accessing the same disk, which might cause the file cache to be swapped out. Depending on the file cache configuration and the cache contents, more memory might be used by the WebServer. As a result, this additional memory might create more page faults for the CPU and negatively impact the overall performance. Therefore, you should also consider the overall system resources when tuning the WebServer and the NonStop system. Be cautious when using this feature with frequently updated static files. The WebServer might build file caches that it is unable to use, In the worst-case scenario, the older version could be returned from the file cache rather than the updated version. Therefore, you need to understand the following configuration directives, set their values appropriately according to your environment, and use the vcache script as needed. vcache A shell script vcache is available in the /usr/tandem/webserver/conf directory to validate the cache entries in all of the httpd servers. This script causes the WebServer to verify its cached information, ensuring current file content is provided to clients. However, the process of validating cache entries goes through the entire cache table and might temporarily consume system resources. Therefore, file updates should be conducted during off-peak hours. Section 2.1: Configuration Directives CacheTime CacheTime sets up the time interval (in minutes) during which the file cache content will be used instead of accessing the disk directly. After this time interval expires, the cache content is invalidated, the disk files are read, and a new file cache is built. The default interval of 60 minutes (one hour) is used if this directive is not specified. In other words, the file content stays in the file cache for a period of 60 minutes. Hewlett-Packard Company

4 Here is an example of using this directive to keep the file content for 600 minutes (10 hours) before it expires: CacheTime 600 FileStatsCheckTime FileStatsCheckTime sets up the time interval (in minutes) for caching file stats information (information about a file retrieved through a call to fstat). In other words, the cached file stats are used during the period specified by FileStatsCheckTime instead of accessing the disk directly. The default interval of 60 minutes is used if this directive is not specified. If a file update is performed during this interval, the timestamp and file contents in the response might be affected, hence you should use this directive with caution. Here is an example: FileStatsCheckTime 120 This directive instructs the WebServer to cache file stats (fstat) information for 120 minutes (2 hours). If disk files are not frequently updated, the recommendation is to use a value of -1, and run the vcache script if the files are updated. Since fstat is called every time a file is accessed, this strategy might give you a significant performance improvement. MaxFileCacheEntries MaxFileCacheEntries specifies the maximum number of entries allowed in the file cache where the server stores file opens, file stats, and actual file contents. If you specify a larger number of entries, more memory might be consumed by the file cache; if you specify a smaller number, the server must access files directly from disk more frequently. Therefore, we recommend a survey of the web site as well as the physical memory configuration on the CPU. The default value of 2000 is used when no MaxFileCacheEntries configuration directive is specified. For example: MaxFileCacheEntries 5000 This instructs the WebServer to maintain a total number of 5000 file caches. MaxFileCacheContentSize MaxFileCacheContentSize specifies the maximum file content length (in kilobytes [KB] or 1024 bytes) allowed in a file cache entry. When this directive is specified, files with a content length less than or equal to the specified content length are cached entirely in the WebServer's file cache. For files with a content length greater than the specified size, only file opens and file stats are cached. The actual file content is then accessed directly from disk. The default value of 10 KB is used when no MaxFileCacheContentSize directive is specified. Here is an example, which instructs the WebServer to cache a file s content if its size is within the limit of 50 KB: MaxFileCacheContentSize 50 Both MaxFileCacheEntries and MaxFileCacheContentSize determine the maximum file cache size. For example, if MaxFileCacheEntries is set to 3000 and MaxFileCacheContentSize is set Hewlett-Packard Company

5 to 30, the maximum capacity for the file cache is 90 MB (this is only the maximum number; the actual memory usage depends on the actual content size). We recommend a survey of all static files residing on the web site and the physical memory configuration. Performance might be hindered if the WebServer consumes too much physical memory and causes a high number of page faults. A tuning process might be required to determine optimal settings for these directives. NoCache Region Command The file caching mechanism is applied to all disk files served by the WebServer. If a small number of disk files requires constant updates, frequent updates to the file cache are also required and might impact the overall performance of the WebServer. You can use the NoCache Region command to exclude some of these files from file caching and allow the static files to remain in the cache longer, thus providing for better performance. However, the Region directive is evaluated for every request and, in this case, every file access. Therefore, too many Region directives also affect the efficiency of the WebServer. The best strategy might be to keep all constantly updated files in a single region. Here is an example: Region /h/dynamic_files/* { NoCache } This Region directive causes the WebServer NOT to cache any files in the /h/dynamic_files/ directory. In summary, use the following list of steps to properly configure the WebServer file cache: - Conduct a survey of all static files residing on the web site and the physical memory configuration. - Conduct a system-wide survey for memory usage. - Decide the size of the file cache and use. - Determine how frequently these files would be updated, and decide whether to use the Region command and various cache timers. - Conduct system tuning for better performance. - Use the vcache script only in off-peak hours. Section 3: Caveats of Using Conventional TCPIP and the Parallel Library TCPIP (TCPIP/PL) The TCPIP/PL support has been incorporated in WebServer since version 5.1. TCPIP/PL support has the potential to bring a rich set of benefits to your WebServer environment. TCIP/PL support can: - increase throughput - lower CPU utilization - offer better scalability - distribute loads among multiple CPUs - present the entire NonStop system to the outside world through a single IP address - eliminate the use of the distributor and, therefore, reducing extra process hops for initial connection requests Hewlett-Packard Company

6 In essence, Parallel Library TCP/IP has multiple listener sockets on the same port. Parallel Library TCP/IP allows the server direct access to the communication environment from its own processor (CPU) instead of having to communicate through the CPU that contains the conventional TCP/IP process. Running with the Auto-Accept feature, the WebServer no longer needs its Distributor component. The httpd servers assume the listening and the distributing functions of the Distributor. The Distributor server class has been removed from the PATHWAY environment. Note that in conventional TCP/IP environments (or in a mixed TCPIP/PL and conventional TCP/IP environment), the Distributor ServerClass process is always used. Running the WebServer relies on a correctly configured TCPIP/PL environment. Every processor (CPU) specified in the Server CPUS command (in the httpd.config configuration file) needs to be enabled to run Parallel Library TCP/IP. In other words, the TCPMAN or TCP6MAN needs to be properly configured and run and a TCPMON or TCP6MON (the monitor process) should be running on every processor (CPU) specified in the Server s CPUS command. In its startup configuration phase, the WebServer validates the existence of these processes. Additionally, at least one TCPSAM or TCP6SAM (TCP socket access point) process must be running. If all of these processes are not running, the Auto-Accept feature is not used, and the WebServer falls back to using the conventional TCP/IP stack. For information about configuring for Parallel Library TCP/IP, refer to the TCP/IP (Parallel Library) Configuration and Management Manual. This manual is especially important for the configuration of the LAN adapters. The access list of the ServerNet Addressable Controller (SAC) needs to include all CPUs designed to run httpd servers. This is not new information, but just a reminder to doublecheck the configurations because the list should now contain more CPUs than previously. In conventional TCP/IP, a TCP/IP process is usually running on 2 CPUs a primary and a backup. For Parallel Library TCP/IP, if the application is running on all the other 14 CPUs, all of those need to be Parallel Library TCP/IP-enabled and must be in the access list. If a Parallel Library TCP/IPenabled processor (CPU) is present, a TCPMON process is running on that CPU. For the httpd servers to function properly, all these processes must be in place. Socket errors are reported if a TCPMON is not running on a CPU that attempts to run an httpd process. The httpd server is designed to retry the bind request if it fails. Repeated bind failures might indicate that a CPU is not Parallel Library TCP/IP-enabled. You should use only one TCPSAM process pair even where you are using more than one IP address. Unlike the conventional TCP/IP processes, one TCPSAM process can provide socket interfaces for all IP addresses configured in the Parallel Library TCP/IP environment. If you use more than one, two httpd servers might attempt access to the same port and therefore generate EADDRINUSE socket errors. Using Parallel Library TCP/IP, the WebServer automatically sets up a filter key for round-robin filtering using the PATHMON name specified in your httpd.config file. Since Parallel Library TCP/IP uses this key to distribute incoming connections to processes specifying this key, make sure no other TCP/IP application is sharing the same key. Note that the -restarth option is no longer supported if you are using Parallel Library TCP/IP. Hewlett-Packard Company

7 In summary, here is a list of steps for correctly configuring the WebServer to use Parallel Library TCP/IP: - Make sure Parallel Library TCP/IP is properly installed and enabled in your system. - Select a TCPSAM process for transport while running WebServer setup. - Make sure all CPUs specified in your Server CPUS command (in your httpd.config configuration file) are Parallel Library TCP/IP-enabled. - Make sure you are not mixing Parallel Library TCP/IP and conventional TCP/IP in your WebServer. Mixing the two TCPIP stacks actually negates all of the advantages offered by TCPIP/PL. One way to validate this configuration is to use the PATHCOM STATUS (or INFO) SERVER command to make sure the Distributor server class does not exist. - Make sure that no other application is using the PATHMON name as the Parallel Library TCP/IP round-robin filtering key. - When TCPIP/PL is in use, the httpd process manages the connection. So ensure that the httpd processes are static; otherwise, when TS/MP stops or deletes the dynamic httpd process, some connections might be lost or broken. Section 4: WebServer Configuration 1. Numstatic The default setting is 5, however a good practice is to start as many static httpd servers as the number of CPUs that will run httpd servers because dynamic server creation is expensive and affects the response time. So if you are planning to use CPU 0 to 5 to serve httpd requests, you should set the Numstatic value to at least TANDEM_RECEIVE_DEPTH (TRD) This parameter sets the maximum number of requests a single httpd process can handle. Although the receive depth is conceptually similar to the NonStop TS/MP link depth, the link depth is limited to 255 simultaneous requests per server class, whereas the receive depth is limited to 255 simultaneous requests per process. Therefore, even if you specify a value of 1 for the Linkdepth command, the httpd or NSJSP process can simultaneously service as many requests on that link according to the value specified for the receive depth. The default value is 50. NOTE: TRD has no meaning for server classes other than httpd or servlet. 3. Linkdepth & Maxlinks Linkdepth is the maximum number of simultaneous requests each LinkMon process would send per LinkMon open. Maxlinks is the maximum links from all LinkMon processes to a single server class. Both values must be set to 1 for the WebServer httpd server class. Multithreading the httpd requests You can use two techniques, individually or in combination, to allow the WebServer to handle many requests in parallel. 1. Specify a large value for Maxservers, which is the total number of servers in the class. Hewlett-Packard Company

8 2. Specify TANDEM_RECEIVE_DEPTH (TRD), which enables multithreading in an individual server process (only applicable to httpd and NSJSP server process). If you want each server to be single-threaded, the value of Maxservers should be large enough to accommodate the maximum number of concurrent requests your WebServer must be able to handle. To allow for multithreading in each server process, use the TANDEM_RECEIVE_DEPTH environment variable. (The Env command in the Server directive lets you specify environment variables.) To increase the number of concurrent requests, you can define multiple servers in the server class and use TANDEM_RECEIVE_DEPTH to make each server multithreaded. In this case, you can determine the maximum number of simultaneous requests to a server class by multiplying the value of TANDEM_RECEIVE_DEPTH by the value of Maxservers. In the configuration file delivered with the WebServer, the httpd server class consists of multiple multithreaded servers. Assigning a smaller number of servers with a higher number of threads per server has the following benefits: - In a process, all threads share system resources, such as swap space and file opens, including opens to cache files. - No system dispatching is required to switch among threads in the same process. Assigning a larger number of processes with a lower number of threads per server has different benefits: - Increased load balancing across CPUs - Less susceptibility to CPU and process failures, and better fault isolation Section 5: SSL Global Cache Server For the WebServer, the SSL session keys are either maintained in a local cache of each instance of the WebServer httpd process or in a global cache. If the keys are in each httpd process, roundrobin load balancing makes having SSL session cache hits rare. To improve the overall SSL caching performance, a better practice is to use the global cache that allows a cache of SSL session keys to be shared amongst all instances of the httpd ServerClass, thereby maximizing the cache hits and minimizing the CPU and network resources required for establishing SSL connections. To enable this feature, modify the httpd.stl.config or httpd.websafe.config file by altering the following attribute: set GlobalCahce OFF ===> set GlobalCache ON Other parameters that might influence global key caching performance are: 1. cache size, which is specified through CacheSize (default 1000) 2. cache time out, which is specified through CacheExpiration (default [24 hours]) Hewlett-Packard Company

9 Section 6: Mapping Static Content via Filemaps Serving static content (HTML pages, images, Client-side Java Scripts, Cascading Style Sheets, and so forth) has overhead when used with the NSJSP Container. It is recommended that you serve all static content through the WebServer http daemon process. The WebServer http daemon process caches static content and, thus, provides for better performance. The Filemap directive in either httpd.config or servlet.config allows you to map URI paths to physical files or directories. For example, if the following Filemaps are added to the /usr/tandem/webserver/conf/servlet.config file, all the static content in the images/ directory and the Cascading Style Sheet are served by the WebServer httpd process. Filemap /myapp/images Filemap /myapp/style.css /usr/tandem/webserver/servlet_jsp/webapps/myapp/images /usr/tandem/webserver/servlet_jsp/webapps/myapp/style.css Section 7: NSJSP Configuration In order to configure the NSJSP environment better, you might need to do the following: 1. Identify the maximum number of requests you expect your environment to handle. 2. Using the sample configuration provided, adjust it according to your request load. Let s first discuss the default configuration that comes with the NSJSP product. At startup, two NSJSP processes are started (configured through the Numstatic 2 command in the servlet.config file). Each of these processes can handle a maximum of 25 simultaneous requests (configured through the TANDEM_RECEIVE_DEPTH and Linkdepth commands in the servlet.config file each has the default value set to 25). With this configuration, the capacity of your system is set to handle 50 simultaneous requests. After surveying your environment, let s assume that at peak time 150 simultaneous requests could be present. With this load running without the default configuration being modified, three dynamic NSJSP Container processes will be started to handle the extra load because Maxservers is set to 5 and still 25 requests would be left queued up at the LinkMon process. To handle such a load and prevent the queues from building up, the NSJSP configuration should be modified so that the Numstatic is set to at least 5 servers, and the Linkdepth and TANDEM_RECEIVE_DEPTH values should be at 30 or more. With this new configuration, five static NSJSP processes will be started, and each can handle 30+ requests simultaneously. The benefit of making all the NSJSP Container processes run as static servers is that no response delay occurs due to a dynamic server process starting up. If you determine that your environment needs a lot of NSJSP processes, the best practice is to run one NSJSP Container process per CPU. If you have to run several NSJSP processes in a single CPU, ensure that no more than three NSJSP processes are running in the same CPU; otherwise, because of the size of the JVM, the response time might deteriorate due to page faults and swapping. With this configuration, data migration across processors (CPUs) does not occur, and at least 150 total threads (5 * 30) are present at the beginning to process the requests. Hewlett-Packard Company

10 Note that, because the CGI process is single-threaded to handle concurrent requests, the number of CGI processes configured should be at least the same as the maximum number of concurrent requests to be handled. Section 8: Aligning WebServer and NSJSP or CGI Processes To achieve better scalability and performance, as well as allow for using the best load balancing with HP NonStop TS/MP, HP recommends that the WebServer and NSJSP or CGI processes be vertically aligned (running on the same set of processors or CPUs). Vertically aligning WebServer and NSJSP or CGI processes helps reduce the number of intra-processor messages. CPU CPU CPU CPU httpd httpd NSJSP Container NSJSP Container itp Secure WebServer Environment The caveat here, however, is that if the CPU utilization of the NSJSP or CGI processes and the WebServer httpd daemon process is high, a better strategy is to run the NSJSP or CGI processes on a different set of processors or CPUs. This strategy allows your WebServer environment to service multiple requests in parallel more efficiently. Section 9: Pre-compiling JSP Programs JSP programs provide an easy way to generate dynamic server-side content and have a smaller learning curve as opposed to Java Servlets. Also, JSP programs do not require intimate knowledge of the Java programming language. However, within the NSJSP container, a JSP program is internally pre-compiled into a Java Servlet and run within the scope of a specialized Servlet called the JspServlet. Because they are interpreted and then compiled internally into a Servlet, JSP programs have some performance implications. Hewlett-Packard Company

11 First and foremost, every time a JSP page is requested and executed within NSJSP, the specialized JspServlet (and also the NSJSP Container) has to perform additional checks to determine if the generated Servlet class is out-of-date. This checking results in a series of OSS NameServer operations (initiated through the OSS file system stat calls), which get information about the JSP program, the temporary work directory for compiling JSP programs, and the generated Java Servlet code. These operations might not seem to be a problem intuitively, but as the number of parallel requests grows, so does the number of OSS NameServer calls. Typically, in most web application environments deployed in production, the JSP programs are rarely changed, so you should have your web application perform and scale better. It is recommended for WebServer environments where request/client load is high that you precompile and deploy your JSPs. This strategy allows you to get the best benefits out of your system and get the best of both worlds. Your development lifecycle is simplified and easier by using JSPs, and your runtime performance is high by deploying these JSPs as Servlets. The jspc.sh utility, shipped as part of the NSJSP product, allows you to pre-compile your JSPs. This utility is located in the /usr/tandem/webserver/servlet_jsp/bin directory. The jspc.sh utility, run without any arguments, will provide a list of all supported command line options. For example, if your web application located in the /h/user/mywebapp directory contains a JSP program called myprogram.jsp, the steps to pre-compile and generate a servlet named mytestprogramservlet would be: 1. Ensure your CLASSPATH contains the servlet.jar and any other classes your JSP program might use. osh> export CLASSPATH=/usr/tandem/webserver/servlet_jsp/common/lib/servlet.jar:<customCP> 2. Generate the Java Source for your JSP program. osh> cd /h/user/mywebapp osh> /usr/tandem/webserver/servlet_jsp/bin/jspc.sh -p com.myco.apps \ -d WEB-INF/classes -c mytestprogramservlet myprogram.jsp The above command runs the jspc.sh utility telling it to interpret myprogram.jsp and generate a Java Servlet named mytestprogramservlet, which is in the com.myco.apps package hierarchy. The generated source file is placed in the specified package directory hierarchy under the WEB-INF/classes destination directory (WEB-INF/classes/com/myco/apps) specified above. Note that the options for the jspc.sh utility might change across different NSJSP versions. You can run the jspc.sh utility without any arguments to see the list of supported options and their usage. 3. Compile the Java source file osh> cd WEB-INF/classes/com/myco/apps osh> javac mytestprogramservlet.java Hewlett-Packard Company

12 4. Modify the deployment descriptor (/h/ramr/mywebapp/web-inf/web.xml). This modification involves adding a logical servlet name entry for your generated Servlet class as well as a mapping to use the compiled Servlet code instead of the JSP. <servlet> <servlet-name>mylogicalname</servlet-name> <servlet-class>com.myco.apps.mytestprogramservlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>mylogicalname</servlet-name> <url-pattern>/myprogram.jsp</url-pattern> </servlet-mapping> Ensure that all the <servlet> tags and all the <servlet-mapping> tags are grouped together separately. Otherwise, the web application will not start up or be deployed correctly. The <servlet> tag defines a logical mapping for your generated Servlet class name. The <servlet-mapping> tags ensure that your generated servlet is executed if the URL pattern contains the JSP generated from the Servlet. This modification enables you to keep your links and references to the JSP pages, but internally, instead of a JSP program, the corresponding servlet will be executed. Section 10: Configuring Support for Persistent Sessions Starting with the NSJSP 2.0 product release, sessions can be kept either in the server s memory or saved in a persistent store. For in-memory sessions, the sessions are lost when the NSJSP Container process exits. To prevent session data loss with dynamic NSJSP Server processes, you should set the number of static NSJSP servers (configured via the Numstatic command) and the maximum servers (configured through the Maxservers command) to the same value. When sessions are saved in a persistent store, the sessions are maintained across NSJSP container failures and restarts. This persistent store is a JDBC store used with an HP NonStop SQL database for storing the session data. This store is managed by configuring a persistent session manager NSJSPPersistentManager. The database can be accessed through either the HP JCBC Driver for SQL/MP (JDBC/MP) or the HP JDBC Driver for SQL/MX (JDBC/MX). The NSJSP 3.0 product release supports JDBC/MX nonblocking IO to further enhance the performance. Hewlett-Packard Company

13 The following is a snippet of the Persistent Manager configuration from the itp_server.xml configuration file. The snippet uses JDBC/MX to access the underlying database. <Context path="/servlet_jsp/examples" docbase="examples" debug ="0" reloadable="false" crosscontext="true"> <Manager> classname="org.apache.catalina.session.nsjsppersistentmanager" debug="0" saveonrestart="true" checkinterval="300" maxactivesessions="-1" minidleswap="-1" maxidleswap="600" maxidlebackup="-1"> <Store classname="org.apache.catalina.session.nonstopsqljdbcstore" debug="0" drivername="com.tandem.sqlmx.sqlmxdriver" connectionurl="jdbc:sqlmx:" sessiontable="$system.t1222cat.sessdata /> </Manager> </Context> For details on how to configure for persistent sessions, refer to the NonStop Servlets for JavaServer Pages (NSJSP) System Administrator s Guide. Note that the CPU cost of using the persistent store is expensive compared to in-memory sessions. You should configure the attributes (above in blue) based on the amount of session-based traffic the applications expect to generate. As a general rule, use the following steps whenever possible: 1. Partition the NonStop SQL database table. 2. Set the value of maxidlebackup to an appropriate value. 3. Set the checkinterval to a value that is suitable for your application, to ensure that persistent manager does not check for expired sessions too frequently. 4. Depending on how your environment is configured, turn off the saving session on creation attribute of the NSJSP Arglist (in the servlet.config configuration file) by setting -DsaveSessionOnCreate=false 5. To enable the nonblocking IO of JDBC/MX, add the following to the NSJSP Arglist (in the servlet.config configuration file): -Dsqlmx_nowait=on 6. Since the database will grow over time, a good practice is to run the nsjsp_cleansessiondata script periodically to clean up sessions that are older than ndays. 7. To bring down the NSJSP environment gracefully and back up the persistent sessions, use the nsjsp_stop script. Hewlett-Packard Company

14 Section 11: SQL/MX Nonblocking IO Support Blocking mode with the JDBC/MX driver causes the whole Java VM process to be blocked when an SQL operation occurs. Nonblocking mode causes the JDBC/MX driver to block only the thread that invokes the SQL operation and not the whole Java VM process. In a multithreaded Java application, the nonblocking JDBC/MX feature enables the Java VM to schedule other threads concurrently while each SQL operation is handled by a separate thread. The following are some guidelines for an application developer writing multi-threaded Java applications: - Create only one JDBC connection per thread. Applications obtaining multiple JDBC connections in a single thread do not run the SQL/MX operations concurrently and can waste system resources because each connection requires its own SQL/MX compiler process. - Do not simultaneously use a JDBC connection from multiple threads. - Do not share JDBC Java objects, such as Statement or ResultSet objects, across threads for purposes other than canceling the SQL operation with the Cancel() method. - Be aware of the non-preemptive nature of the thread implementation in NonStop Server for Java. A CPU-bound thread runs to its completion without providing an opportunity for the thread scheduler to schedule a different thread. Section 12: Memory Considerations: Moving QIO to KSEG2 NSJSP Server applications are typically configured with large Java heap sizes, in excess of 128 MB. In addition, the Java Virtual Machine and its native components (i.e., NSJSP transport library, JDBC/MP, JDBC/MX and SQL/MX CLI) allocate memory for their own use. Thus, the overall heap space required by a single NSJSP Server process instance might be considerably higher than the Java heap space configured. When a process uses the Parallel Library TCP/IP transport provider for socket operations (like the WebServer httpd daemon Server process instance), the process becomes a QIO client. NonStop Server QIO shared-memory segments are designed such that when a QIO client process makes a socket request, a portion of the process address space is reserved for the QIO segment. This design limits the maximum useable heap size for the JVM running the NSJSP Server. The size of the QIO segment is determined by the configured physical memory for a processor (CPU) on the NonStop system. For a processor on a NonStop system configured with 4 GB of physical memory, 512 MB is used for the QIO segment. In addition, 512 MB of the user address space is reserved for the QIO segment, if the process is also a QIO client. To overcome the problem of losing address space to QIO, the QIO segment can be configured so that it is moved to the KSEG2 [1] region. This implies that the maximum size of the QIO segment will be restricted to 128 MB (instead of the default 512 MB). Before making a decision to move QIO to KSEG2, check the current maximum QIO segment size in use. If the size is within the 128 MB limit (allowing for future requirements that might increase the QIO segment size), QIO can then be moved to KSEG2. [1] KSEG2 is a special region of the privileged address space. Hewlett-Packard Company

15 To determine the QIO segment size in use, use the following SCF command: TACL> scf SCF - T9082G02 - (30APR03) (01APR03) - 03/19/ :20:31 System \NAVAE1 (C) 1986 Tandem (C) 2003 Hewlett Packard Development Company, L.P. (Invoking \NAVAE1.$DATA11.RAMR.SCFCSTM) 1-> status segment $ZM00, detail QIO Detailed Status SEGMENT \NAVAE1.$ZM00 State... DEFINED Segment State... STARTED Segment Type... FLAT_UA Segment Size MDs in Use Max MDs Used Last Fail Size... 0 Current Pool Size Initial Pool Size Max Pool Size Min Pool Size Current Pool Alloc Max Pool Alloc Current Pool Frags Max Pool Frags The maximum QIO space used in this case is 16 MB, which is well below the 128 MB limit. So QIO can be moved to KSEG2. The following SCF output shows the QIO segment as moved to KSEG2. TACL> scf SCF - T9082G02 - (30APR03) (01APR03) - 03/19/ :20:00 System \GOBLIN (C) 1986 Tandem (C) 2003 Hewlett Packard Development Company, L.P. (Invoking \GOBLIN.$DATA11.RAMR.SCFCSTM) 1-> status segment $ZM00, detail QIO Detailed Status SEGMENT \GOBLIN.$ZM00 State... DEFINED Segment State... STARTED Segment Type... RESIDENT Segment Size MDs in Use Max MDs Used Last Fail Size... 0 Current Pool Size Initial Pool Size Max Pool Size Min Pool Size Current Pool Alloc Max Pool Alloc Current Pool Frags Max Pool Frags The QIO segments on this system (\GOBLIN) have been moved to KSEG2 based on the value of the segment type. The value is RESIDENT if QIO is moved to KSEG2. The first SCF output for \NAVAE1 shows QIO to be in FLAT_UA, which indicates that QIO has not been moved to KSEG2. Section 13: New Heap Manager (T1269) Hewlett-Packard Company

16 The new C Runtime Heap manager (T1269) offers a substantial performance boost over the older heap manager (T8431). While this might not affect any pure Java code, note that the NSJSP transport library and Java Virtual Machine contain native (C and C++) code; therefore, using the new heap manager will boost the Java Virtual Machine (and hence NSJSP) performance. To find the current C Runtime Heap Manager being used on your NonStop system, see the vproc output of the ZCRESRL library: TACL> vproc $SYSTEM.sys<nn>.ZCRESRL Section 14: Java Heap Setting HP recommends that the Java Heap size for the NSJSP Server process instance be set to a value appropriate to your application. On most application server environments, the heap size is set high to optimize performance. This size could be greater than 256 MB (after QIO has moved to KSEG2). The -verbose:gc option in the NSJSP ServerClass Arglist can be used to study the frequency and length of the Java Virtual Machine s Garbage Collection operation. This data should then be used to tune the heap usage of the NSJSP ServerClass based on your application requirements. Note that the Java Virtual Machine allocates the maximum required heap for the JVM usage at startup. So the swap space considerations for the NSJSP Server process instance will be the maximum Java Heap space specified plus other JVM memory requirements and memory requirements for all native components (the primary memory intensive components being the NSJSP transport library, JDBC/MP, JDBC/MX and SQL/MX CLI). To identify the swap usage of a process or swap requirements for a CPU, you can use the NSKCOM utility. For example, from the OSS prompt you can use the following commands to identify the swap usage of all the processes or a particular process. oss> gtacl p nskcom NSKCOM - T5838G05 BASE (22JUL02) - Nov Copyright 1995 Compaq Computer Corporation $SYSTEM.SYSTEM.ZSYSCFG KMS.SWAPFILE = 0 $DATA03.SWAP.CPU0A STOP KMS.SWAPFILE = 0 $DATA03.SWAP.CPU0B STOP KMS.SWAPFILE = 1 $DATA03.SWAP.CPU1A STOP KMS.SWAPFILE = 1 $DATA03.SWAP.CPU1B STOP KMS.SWAPFILE = 0 $SWAP01.SWAP1.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP1.CPU01 KMS.SWAPFILE = 0 $SWAP01.SWAP2.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP2.CPU01 KMS.SWAPFILE = 0 $SWAP01.SWAP3.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP3.CPU01 KMS.SWAPFILE = 0 $SWAP01.SWAP4.CPU00 KMS.SWAPFILE = 1 $SWAP01.SWAP4.CPU01 KMS.SWAPFILE = 2 $SWAP23.SWAP1.CPU02 KMS.SWAPFILE = 3 $SWAP23.SWAP1.CPU03 KMS.SWAPFILE = 2 $SWAP23.SWAP2.CPU02 KMS.SWAPFILE = 3 $SWAP23.SWAP2.CPU03 KMS.SWAPFILE = 2 $SWAP23.SWAP3.CPU02 Hewlett-Packard Company

17 KMS.SWAPFILE = 3 $SWAP23.SWAP3.CPU03 KMS.SWAPFILE = 2 $SWAP23.SWAP4.CPU02 KMS.SWAPFILE = 3 $SWAP23.SWAP4.CPU03 KMS.SWAPFILE = 4 $SWAP45.SWAP1.CPU04 KMS.SWAPFILE = 5 $SWAP45.SWAP1.CPU05 KMS.SWAPFILE = 4 $SWAP45.SWAP2.CPU04 KMS.SWAPFILE = 5 $SWAP45.SWAP2.CPU05 KMS.SWAPFILE = 4 $SWAP45.SWAP3.CPU04 KMS.SWAPFILE = 5 $SWAP45.SWAP3.CPU05 KMS.SWAPFILE = 4 $SWAP45.SWAP4.CPU04 KMS.SWAPFILE = 5 $SWAP45.SWAP4.CPU05 NSK-status swap-usage 1,423,detail SYSTEM : \GOBLIN LOGTIME : March 19, :50:29 TYPE : (E=Extensible S=Shared O=Owner) (CPU Page size is Bytes) Process Pri User-ID Program File Name $JSV1 1, ,43 $DATA11.ZYQ0000T.Z00001VH KMSF-BACKED SEGMENTS: (Process Space Guarantee = 1904KB) SEG-ID TYPE SIZE RESERVATION KBYTE PAGES KBYTE B B 1 16 Heap+Global+SRL+Stack 330MB MB TOTAL MB FILE-BACKED SEGMENTS: None NSK- In the output above, the NSJSP Server process instance ($JSV1) currently uses 331 MB of swap space and has two segments allocated. This NSJSP Server process instance was started with a heap size of 256 MB, which shows that apart from the Java heap, about 75 MB for process and application-specific data is required. To get a correct picture of the swap usage of a NSJSP Server process, you should check this swap usage at a steady state, where all the native components used by the Java Virtual Machine have been fully initialized and executing in order. Hewlett-Packard Company

18 Section 15: JVM Tuning for HotSpot The NonStop Server for Java 4 (NSJ4) incorporates the HotSpot compiler. Refer to the NSJ4 manual and HotSpot tuning information on the Web for specific flags and values to tune the Java Virtual Machine. All the HotSpot options that you specify at the JVM command line need to be specified in the Arglist command for your NSJSP ServerClass (configured via the servlet.config file). Typically, the Java memory heap is divided into generations young, old and permanent. The young generation is further divided into (a) Eden, (b) two Survivor spaces and is relatively small compared to the total heap size. As objects fill up the generation, garbage collections (GC) take place. Objects that survived many GCs in the young generation are aged into the old generation. When older generation is garbage-collected, a major collection occurs and is usually very slow. Hence the longer an object survives, the slower GC becomes. The permanent generation contains the JVM classes and methods and meta data. Since GC takes place when generations fill up, the amount of available total heap memory has direct impact to the performance. The parameters that affect the heap are listed below (specified in the Arglist of servlet.ssc in the servlet.config) 1. Xms : the startup size of the memory allocation pool (the GC heap) 2. Xmx : the maximum memory allocation pool. The maximum value on the NonStop platform depends on the location of the QIO segment. If QIO is moved to KSEG2, the maximum value can be as high as 900, otherwise, it can only go to approximately XX:MinHeapFreeRatio=40 4. XX:MaxHeapFreeRatio=70 The JVM tries to maintain the proportion of free space to live objects within the limit set by the Min and Max Heap free ratio. For large server application, the default values are usually not adequate. As a general rule, grant as much memory to the JVM as possible. Another important factor to the performance is the proportion of the heap that is assigned to the young generation. The parameters for young generation heap are listed below (they need to be specified via the Arglist): 1. XX:NewRatio=nn The ratio between the young and old 2. XX:NewSize=nn The lower size bound 3. XX:MaxNewSize=nn The upper size bound 4. XX:SurvivorRatio=nn Tune the survivor spaces Hewlett-Packard Company

19 Below is a sample usage of the attributes listed above: Arglist Xms512m Xmx512m XX:NewSize=256m XX:MaxNewSize=256m \ XX:SurvivorRatio=2 These options inform the JVM to set the initial size of the heap to 512m, the maximum heap 512m, the new generation 256m (128m belongs to Eden and 2x64m survivor) and the old generation 256m. For more information about these parameters, refer to: Section 16: Other HP NonStop System Tuning Areas The Measure NonStop system tool and the JVM profiler (hprof) allow you to profile and measure the processes running on your system. Running some measurements on your application servers (processes) can help you greatly in tuning your application, as well as provide you with information on the potential areas to look at for performance improvement. OSS Name Server (OSSNS) Requests As mentioned in Section 8: Pre-compiling JSPs, the cost of OSSNS requests on your system is also a factor to consider when fine-tuning your application environment. The java.io.file class is one potential area to look at because its use results in file stat calls when the following methods in the java.io.file class are invoked: canread(), exists(), isdirectory() and isfile() Doing a measurement and looking at the NSJSP Server process instances measure counters might give you valuable insight into the number of OSSNS requests that you issue. The measure counters in the Process entity that would provide you more details, include: File-Open-Calls, Info-Calls, OSSNS-Requests, OSSNS-Redirects, OSSNS-DD-Calls, OSSNS-Message-Bytes and OSSNS-Wait-Time. Optimizing your Disk, OSS and System Configuration Other potential areas to look at while tuning your application environment include: - Storage subsystem (disk processes, cache, etc.) - OSS subsystem - TMF Subsystem - NonStop TS/MP Configurations Hewlett-Packard Company