Optimizing the web application environment

This section provides some ideas for improving the operating environment of JRun for your web application.

Optimizing session settings

Session objects are stored in memory on the server and referenced with a session ID that is passed back and forth between the client and the server. Because they are stored in memory, each session uses a small amount of system resources.

The following table describes session settings that you can change to reduce resource load:

Setting	Description
Maximum Sessions	The number of sessions JRun caches in memory before swapping them out to disk. To prevent JRun from serializing session objects, increase the number of sessions you cache in memory. You set this value in the jrun-web.xml file.
Maximum Inactive Interval (MaxAge)	The amount of time before JRun destroys an inactive session object. The default is 1800 seconds (30 minutes). Decrease this time to clear unused sessions sooner. If you are using cookies as the state-management mechanism, you can set the maximum age programmatically (with the cookie.setMaxAge method) or declaratively, in the jrun-web.xml file.

For more information on changing session settings, see "Working with sessions".

Disabling hot deployment

The hot deploy feature automatically restarts (redeploys) a running web component upon detection of changes to the component structure.

When hot deploy is enabled, JRun periodically checks the date/time stamps of all the resources to determine if the files have changed. This constant cycling uses up a small amount of system resources.

To disable hot deploy, add the following attribute to the jrun.deployment.DeployerService service in the jrun_root/servers/server_name/SERVER-INF/jrun.xml file:

<attribute name="hotDeploy">false</attribute>

Note:   You must always disable hot deployment on production servers.

Managing the thread pool

Part of configuring the connector between JRun and an external web server is optimizing the concurrency settings. Concurrency defines how HTTP requests are pooled and distributed. By changing these settings, you can limit the number of threads and requests that each JRun server processes. In effect, you can throttle the traffic for that JRun server.

If, for example, the average response time of your web application is slow because of a three-step RMI-CORBA-database transaction, then your site might need to queue up many more requests to maintain throughput without refusing any new requests. In this case, you should increase the maximum concurrent requests to a value greater than the number of expected requests. The maximum concurrent requests setting acts as a safety valve for resources.

Note:   Remember that "concurrent requests" and "concurrent users" are two distinct concepts.A website that must support 1000 concurrent users does not also need to support 1000 concurrent requests, since 1000 users will likely create only a fraction of that number of requests at one time.

The following table describes the settings with which you can configure concurrency settings for the connection to your web server:

Name	Description	Default
ActiveHandlerThreads	The initial size of the handler thread pool.	10
Backlog	The number of concurrent requests that are accepted before new requests are denied. (Previously known as Maximum Concurrent Requests.)	1000
MaxHandlerThreads	The number of concurrent requests that are accepted before new requests are queued. If your application requires more than the default concurrent users, and you have enough CPU power, you can increase the MaxHandlerThreads value to improve performance.	20
MinHandlerThreads	The minimum number of handler threads in the pool. In an environment where your website experiences spikes in traffic, set the MinHandlerThreads value higher so that a group of threads do not have to be created during a spike. You can also set MinHandlerThreads value to the expected steady state load of concurrent requests. For example, if a website has 80 concurrent requests at all times, then set the MinHandlerThreads to 80.	1
Timeout	The idle thread time out, which is the number of seconds that threads remain idle before being destroyed.	300

To change concurrency settings, add the properties to the appropriate service in the jrun.xml file with the new values, as shown in the following example:

<service class="jrun.servlet.http.WebService" name="WebService">

 ...
 <attribute name="minHandlerThreads">80</attribute>
 ...
</service>

To edit the JRun web server's settings, change the attributes of the WebService. To edit the external web server connector settings, change the attributes of the ProxyService.

Note:   Before changing any of the default JRun concurrency settings, be sure that the traffic patterns are truly observable. Arbitrarily changing settings can waste resources. For more information on load-testing web applications, see the resources in "Other resources".

Trying different JVMs

Reusing and caching objects saves memory and CPU cycles associated with JVM garbage collection and object allocation. Object allocation takes CPU cycles and memory. Garbage collecting unreferenced objects requires suspension of all other threads in the JVM while the garbage collector threads run, which slows down an application.

Choosing a JVM can make a big difference in performance of your web applications. Sun Microsystems' HotSpot Server VM and Appeal's JRockit use advanced algorithms like generational garbage collection, which reduce the runtime duration of the garbage collection threads.

You should run load tests under different environments to determine which operating system/JVM combination is best for your particular web application.

Increasing the heap size of JVMs

Changing the memory settings of your JVM can increase performance of your JRun server. Before you make adjustments, though, you must know how much memory your application requires. Perform a load test on your application and display the heap size.

Set the JVM's minimum (or initial) heap size to the highest value (memory consumption) during load testing. Also, set the maximum heap size value to something less than the total memory available, minus other required resources, but choose the highest possible value. If the maximum heap size is set to the default value in the JDK that you are using (usually 128MB), but you exceed the maximum value, "OutOfMemory" errors can occur.

To set the maximum heap size value, edit the Max Heap Size (MB) field on the JVM Settings panel of the JMC. You can change other settings by adding command-line arguments to the VM Arguments field on the same panel.

The following table describes some possible arguments. These arguments depend on which JVM you are using.

Argument	Description
-Xms<value>	Initial (minimum) value of the Java heap size.
-Xmx<value>	Maximum value of the Java heap size.
-Xss<value>	Value of the Java thread stack size.

For optimal performance, set the minimum and maximum heap size to the same value. This eliminates the need for incremental increases by the JRun process.

For more information, see your JVM's documentation.

Reducing logging activities

While log files are useful tools for debugging and tracking usage of your web applications, the overhead required to generate substantial log files can be noticeable. For this reason, consider turning off logging in your production applications and instead using your web server's logs as a source of information.

To turn off logging in JRun, set the LoggerService attributes to false in the /jrun_root/servers/server_name/SERVER-INF/jrun.xml file, as shown in the following example:

...

<service class="jrunx.logger.LoggerService" name="LoggerService">
...
  <attribute name="errorEnabled">false</attribute>
  <attribute name="warningEnabled">false</attribute>
  <attribute name="infoEnabled">false</attribute>
  <attribute name="debugEnabled">false</attribute>
  <attribute name="metricsEnabled">false</attribute>
...
</service>
...

Verbose database logging is off by default. If you turned it on while developing your web application, turn it off by editing the appropriate data source in the jrun-resources.xml file and setting the debugging element's value to false.