This document provides an overview of ways to improve performance for EAServer applications. It includes suggestions for server-level and component properties, and for design and coding practices.

There are many variables involved for application throughput and response times. In addition to tweaking the code in your application for optimum performance, you can tune EAServer based on application specifics as well.

But where do you start? What parameters are available? How will changing them affect performance? This paper can serve as a guide to give you a point of reference to start from. As such, there is no silver bullet given, but rather a comprehensive look at what performance tuning is available in EAServer.

Some of the material presented here only applies to EAServer 4.1+, although much of it applies to older versions as well. Be sure to check the EAServer documentation for the version you are using for clarifications and additional details.

With the exception on Section 14, these suggestions focus on improving performance in a production environment.

All of these recommendations are general guidelines. Results may vary depending on the design of your application, hardware and network configuration, and other factors. For best results, you should monitor and measure performance as you fine-tune the configuration and application.

Section 1: General EAServer Tuning

This section contains suggestions to help improve overall performance of EAServer, regardless of the type of components, features implemented, or business logic used. Follow these suggestions for every EAServer installation.

Category Performance Considerations More Information HTTP Request Logging By default, EAServer logs information about every HTTP request made. To improve the speed at which requests are served, you can disable the HTTP request log. "HTTP Config", and "HTTP logging and statistics" in EAServer System Administration Guide HTTP Threads

The HTTP thread settings allow you to balance memory resources. A maximum value set too high needlessly uses memory resources. To tune this setting, monitor the total number of hits listed in the httpstat.dat file for indications of a heavily loaded server, and adjust the maximum thread setting as necessary.

Setting this number too high will result in thrashing, with many threads waiting for a slice of CPU time. As a general guideline, consider a limit of 100 clients per CPU on Solaris, and 75 clients per CPU on Windows.

· com.sybase.jaguar.server.http.maxthreads
· com.sybase.jaguar.server.http.numthreads

Section 10 System-Level Tuning and Sizing

"HTTP Config" in EAServer System Administration Guide

Extra threads are needed for service components, thread manager and message service. If you are not calculating precisely, a guideline is to add another 50 threads.

Important Note: See component Bind Thread property -- components with this setting require twice as many threads.

Stack size determines how many client requests can be served simultaneously. If there are a large number of clients utilizing the server, you may want to reduce the default stack size, which is the amount of memory reserved for the call stack associated with each thread.

For Unix, set the stack size using the com.sybase.jaguar.server.stacksize property.
For NT you need to modify the jagsrv.exe using editbin.

You can specify the minimum and maximum JVM heap size with com.sybase.jaguar.server.jvm.maxHeapSize and com.sybase.jaguar.server.jvm.minHeapSize

(This property is valid for any version of the JVM)

"Repository Properties Reference" in EAServer System Administration Guide

Memory Management within Java Processes

NT & Solaris flags

• -Xms - minimum heap size
  Always increase the -Xms to a reasonable size (such as at least 64m) so the JVM does not have to spend time allocating memory.

   

• -Xmx - maximum heap size
  If you have the memory to spare, set -Xms to the same size as -Xmx.
  (Note: On Solaris, the maximum value for -Xmx is 4g. In order to use the maximum value on Solaris, check shmmax in /etc/system that
  shmsys:shminfo_shmmax=0xffffffff

   

• Garbage Collection (GC)
  These flags are for tuning the Garbage Collections memory allocations and are highly dependent on the behavior of your application. They should only be set after collecting statistics on the GC behavior of your application.

   

  • -XX:NewSize - minimum size of the young generation
    
  • -XX:MaxNewSize - maximum size of the young generation
    
  • -XX:NewRatio - ratio between young and old generation
    
  • -XX:SurvivorRatio - ratio of survivor space with respect to young generation, there are 2 survivor spaces in the young generation

     

  • Setting NewSize and MaxNewSize to each other bounds the size of the young generation like -Xms and -Xmx for the heap size. NewRatio is a more coarse level option to do the same thing. The SurvivorRatio is set to 25 by default and should be sufficient. You should set the NewSize and MaxNewSize to half the size of -Xmx if you observe a lot of regular GCs happening and want to delay a full GC as much as possible. Your application will run more smoothly for the majority of the time and you only pay for the one full GC instead of many GCS throughout your application.

     

  • -XX:ThreadStackSize
    If you know that EAServer will be creating a lot of threads, like when servicing a lot of clients or doing operations like creating a lot of objects or beans, then it might be of benefit to lower the stack size so that they don't take up a lot of heap. Try setting to 128k or 64k(min) to see if that will cause less GCS and help with performance.

Solaris-Only flags

• -XX:TLESize
  Size of the thread local portions of heap in young generation only in the server vm.

   

• -XX:-UseTLE
  Turn off thread local heaps.
  For the server vm, you could completely eliminate TLE or tune the size so that they don't impact heap space when there are many threads.

   

• -XX:+OverrideDefaultLibthread
• -XX:+UseLWPSynchronization
  
  • If you find that EAServer is causing a lot of context switches, or observe an abnormally high amount of %sys cpu usage on a multi-cpu Solaris machine when running EAServer, try using the alternative thread-library that comes with Solaris 2.8 and turning on the -XX:+Overr

    [1] [2] [3] [4] [5] [6] [7] [8]  下一页