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 specific versions of EAServer,
so 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
Pooled component destruction
EAServer 4.2 explicitly destroys pooled component instances before the
server shuts down. This allows for components to perform cleanup operations,
such as closing database connections. If the server takes too long to
shutdown (or shutdown/restart) and cleanup is not required for components,
you can disable this feature at the server level, or specify how long
the server should wait for each instance destruction method to return
when destroying pooled instances. The server-level values can be overridden
for specific components as desired.
Applicable for Solaris only, in EAServer 4.1.2 or higher.
You can configure a pool for each listener, so that incoming connection
requests will be pooled if the server is so busy that there are no threads
available when the request arrives. The outstanding requests will be polled
until they can be handled.
Small pool sizes can cause client connection requests to time out before
the server can handle the request. Large pool sizes use more memory on
startup. You can configure and tune different request pool sizes for different
protocols based on your application requirements. For example, you would
want a larger pool size for HTTP than IIOP if the majority of your application
requests are through HTTP.
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.
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.
com.sybase.jaguar.server.http.maxthreads
com.sybase.jaguar.server.http.numthreads
Setting this number too high will result in thrashing, with many threads
waiting for a slice of CPU time. (See CPU sizing information in Section
10 System-Level Tuning and Sizing.)
The com.sybase.jaguar.server.maxconnections property should
be set to accommodate the number of IIOP connections you expect. By default,
this property is set to 30, which is probably too small for most production
applications.
When the server is very busy with many client connections, client request
threads may repeatedly conflict with each other for access to low-level
system resources. Flow control can improve performance by limiting the
number of threads that can concurrently execute code that is governed
by flow control.
Before setting these properties in a production environment, it is important
to do stress testing based on expected peak load conditions.
The com.sybase.jaguar.server.maxthreads property specifies
the total number of combined HTTP and IIOP threads. As a general guideline,
set this property as follows: [http.maxthreads] + [server.maxconnections] + [50 extra]
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.
These flags are new to JDK 1.3, and are added using the EAServer
property com.sybase.jaguar.server.jvm.options.
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:+OverrideDefaultLibthread
In order to use the alternative thread library, follow these
steps:
add -XX:+OverrideDefaultLibthread to JVM options
in shell:
LD_LIBRARY_PATH=/usr/lib/lwp
export LD_LIBRARY_PATH
start EAServer
On Solaris 2.6, try using -XX:+UseLWPSynchronization to see if
that helps as the alternative thread library is not available in
2.6
-XX+UseISM
Intimate Shared Memory (ISM). ISM provides the benefit of having larger
pages(4mb) and locking pages to memory. If you have enough memory to
dedicate to EAServer, then turning on ISM could help performance. Be
aware that ISM does not guarantee larger pages unless your system has
been rebooted and there is enough contiguous physical memory to fulfill
ISM needs.
Requirements in /etc/system
2.8:
· set shmsys:shminfo_shmmax=0xffffffff
· set shmsys:shminfo_shmseg=32
2.6:
· set shmsys:shminfo_shmmax=0xffffffff
· set shmsys:shminfo_shmseg=32
· set enable_grp_ism=1
-XX:-DisableExplicitGC
Disable calls to explicit GC.
EAServer calls System.gc() periodically. You can try disabling this
to see if it will help GC performance. The System.gc called is just
a hint, so turning on DisableExplicitGC might not do anything.
Allow Just-In-Time compiling (JIT) by setting the com.sybase.jaguar.server.jvm.nojit
property to false. JIT converts Java bytecode into native machine code,
which generally runs much faster than when the bytecode is executed by
the interpreter.
For improved performance, EAServer 4.0+ can run with JDK 1.3 and the
Java HotSpot virtual machine. On some platforms, EAServer can also use
the Java HotSpot VM with JDK 1.2.
Be sure all unnecessary tracing is off. This includes the server-level
trace options for Attentions, Network Driver APIs, Network Driver Requests,
Protocol Data, Protocol Headers, Servlets, JAAS Debug, JCM Trace.
EAServer 4.1+ supports caching of static content. Static page caching
can increase performance by caching static files in memory. You can configure
the cache size, which files are cached, and how long the cached content
is stored.
Cache Size
The default cache size is 10 megabytes, which should be sufficient for
most uses unless an application includes a lot of static images/texts.
Cache timeout
The default timeout is 10 minutes. Set this to a higher value when you
know the static content being served does not change often.
Exclusion List
Exclude-files are useful for turning off things that you know are used
sparingly to ensure the cache stays relevant. You wouldn't want to inadvertently
bump off 100 cached images because a request came in for a 5mb PDF that
is only used once. See:
By default, EAServer will wait indefinitely for open transactions to
be completed. If desired, you can set a maximum number of seconds that
EAServer should wait by default, and override the default at the component-level
when needed. When a specified maximum is reached, EAServer will return
an exception to the client.
By default, EAServer will wait indefinitely for component instances to
be released. You can set a maximum number of seconds that EAServer should
wait by default, and override the default at the component-level if desired.
When a specified maximum is reached, EAServer will return an exception
to the client.
EAServer requires a random seed to initialize the random
number generation used in cryptographic algorithms. The data used as the
seed for the random number generation depends on your platform. You can
set the JAGUAR_RANDOMSEED variable to improve EAServer performance without
diminishing the randomness of the seeding data.
Check the classpath and bootclasspath in the the system
environment and/or server start script to ensure that it is clean and that
the order is appropriate
Section 2: EAServer Clusters
Category
Performance Considerations
More Information
In-memory HTTP session replication
EAServer 4.2 can distribute HTTP session data using in-memory
replication rather than database storage. This feature can improve performance
by avoiding the overhead of writing to the database.
Starting in EAServer 4.1.2, you can limit the time a CORBA or EJB client
waits for a server response before trying another server in the cluster.
This ensures that failover happens without an unreasonable delay. By default,
the is no time limit.
Increased availability and load balancing can be achieved
by adding more members and name severs into a cluster. However, the binding/rebinding
and heartbeat detection times increase as the number of members/name servers
in a cluster increases
Performance decreases as the frequency setting is set shorter, since
it causes servers to ping each other more frequently. Ensure Heartbeat
Frequency is set reasonably.
If the cluster includes components that enable object caching automatic
persistence, you can choose one of four synchronization options for the
caches; None (default), Mirror, Replicate, Invalidate.
The Replicate and Invalidate options provide two alternative ways to
replicate with transaction consistency, if you need to do so. Between
the two, the Invalidate option may yield better performance if the component's
state is large, and the cluster has many members.
You can mark selected components to support
transparent automatic failover. If a client has an object reference for
a component on a server in a cluster, the client's object reference will
provide transparent failover, unless all the servers in the cluster fail.
This section includes performance suggestions for all components in general,
and for specific component types.
It is important to realize, however, that in addition to choosing the appropriate
property settings, you should review and tune the code of the component itself
for optimum efficiency.
These recommendations apply to all components, regardless of their type. Follow
these suggestions for every component, in addition to the ones provided for
specific component types.
Category
Performance Considerations
More Information
Pooled component destruction
EAServer 4.2 explicitly destroys pooled component instances before the
server shuts down. This allows for a component to perform cleanup operations,
such as closing database connections. If this is causing delays in server
shutdown (or shutdown/restart) and cleanup is not required, you can disable
this feature or specify how long the server should wait for each instance
destruction method to return when destroying pooled instances. (The component-level
setting takes precedence over the server-level setting.)
New in EAServer 4.1.3, thread monitors provide a way to limit the execution
time devoted to specific components and methods. Thread monitors can be
defined with a desired maximum number of threads, then components and/or
methods associated with the thread monitor. As a result, EAServer will
ensure that no more than the specified maximum number of threads will
be active at any point executing the methods and components assigned to
the monitor.
Alternatively, you could implement thread monitors without a limit on
the number of threads, for the purpose of recording performance data based
on the monitor trace properties.
If you see unexpected deadlock or slow database
throughput when executing transactional components, check for the following
setting in the properties of the component that initiates the transaction:
com.sybase.jaguar.component.iso_level=serializable
This setting causes the transaction to run with serializable isolation
level, which can cause deadlocks or degraded performance. For components
that are not EJB 1.0 beans, delete this setting using the All Properties
tab in the component properties dialog box. This setting was erroneously
used as a default for new components in past versions of EAServer.
If the component is an EJB 1.0 session bean, verify that the Transaction
Isolation Level setting on the Transactions tab matches your application
requirements.
EAServer 4.1.2 introduces a new stub and skeleton
model for pseudocomponents, which eliminates the unnecessary step of marshaling
for network transport.
Object instantiation is expensive. To improve overall performance, use
instance pooling, which allows EAServer clients to reuse component instances,
eliminating the resource drain caused by repeated creation of component
instances.
Instance pooling can decrease client response time, but can also increase
memory usage in the Jaguar server. You can configure the maximum and minimum
pool size to constrain the memory used to maintain an instance pool. By
default, no minimum or maximum is set. You can increase memory efficiency
by ensuring that heavily used components have higher minimum and maximum
pool sizes than less commonly used components.
If you specify a maximum, the pool size will grow as additional instances
are required to satisfy client requests, up to the maximum specified size.
Subsequently, EAServer destroys excess instances after deactivation. As
a result, instance pooling benefits are lost when the maximum is configured
too low.
"Supporting instance pooling in your component",
and "Component properties: Instances" in EAServer
Programmer's Guide
Named Instance Pools
Named instance pools are available in EAServer 3.6.1 ESD4, and 4.1.1+.
This feature allows specific components to be grouped into specific pools,
with minimum and maximum instances defined.
This feature can be especially useful for components that have the Bind
Thread property set.
When this option is enabled, component instances are bound to the creating
thread. Although components with this setting may be pooled, and multiple
instances may still run concurrently on separate threads, scalability
is decreased. In addition, extra resources are required since twice as
many threads are needed -- the client thread plus another thread bound
to the component.
Enable this option only for ActiveX components,
and components that use thread-local storage (see the PowerBuilder
components section). Otherwise, disable this feature so EAServer can run
the component on any available thread.
Avoid this model - it uses stateful components and does not use pooling,
which greatly reduces scalability.
Bind object causes an instance of a stateful component to be bound to
a client's proxy reference until the client destroys or releases the reference,
or the client times out.
Concurrency indicates whether multiple instances can be simultaneously
active on different threads. Set to true by default, to offer the highest
performance.
Important: With concurrency set, you must protect any static
instance variables by making them thread-safe. Exceptions to this rule
are static variables that include the final modifier (meaning it is a
constant that cannot be changed), and static variables defined as a primitive
datatype that is 32 bits or less. This restriction is required in order
to prevent thread race conditions, which cause random unpredictable results
that can be very difficult to troubleshoot.
Avoid this model. Since there is one instance per server, you must synchronize
all instance and static variables, which creates a bottleneck each time
a synchronization is done.
Additionally, developers need to be aware that in a cluster, each server
has it's own instance, so the component is not truly a singleton object.
The shared flag should only be used in specific scenarios where the component
is designed with the above considerations in mind, and the developer is
aware of the potential server bottlenecks and cluster implications.
For improved performance, connections should
not be held any longer than necessary. Early deactivation prevents a client
application from tying up connections and other resources that are associated
with a component instance. There are two ways to support early deactivation:
Code your component to call the completeWork or rollbackWork transaction
state primitive to cause explicit deactivation of the instance. This
technique is useful when your design requires deactivation to occur
after some, but not all, method calls.
Enable the Auto demarcation/deactivation property (com.sybase.jaguar.component.tx_vote)
so the component is automatically deactivated after every method invocation.
Important Note: This property is ignored for EJBs, and for components
that use the CtsComponents::ObjectControl interface. For those component
types, see "Stateless versus Stateful components"
"Supporting early deactivation in your
component", "Using transaction state primitives", "Component properties:
Transactions" in EAServer
Programmer's Guide
Stateless versus Stateful components
Use stateless components whenever possible. Stateless components
with pooling enabled are ideal, since they are deactivated after each method
call, allowing them to serve more client. On the contrary, stateful components
remain bound to a calling client for multiple business methods. If you need
to accumulate data across method invocations, consider one of these alternatives
instead of using a stateful component;
Use connection caching and database commands to accumulate data in
a remote database. This is the preferred technique.
Accumulate data in the client using a data structure ( IDL structure
and sequence types) that is passed to each method invocation. This technique
is only practical if the amount of data is small. Sending large amounts
of data over the network will degrade performance.
If the accumulated data is small and represented by simple data structures,
you can store the data in a local file.
For ActiveX, C, or C++ components, use the EAServer shared objects
interface, which allows components to store references to shared data.
Recommendation: Set property com.sybase.jaguar.component.stateless=true
Important Note: This property should only be set for EJB session
beans, or components that use the control interface CtsComponents::ObjectControl.
For other component types, see "Early Deactivation"
"Stateful versus stateless components",
"Component Life Cycles", "Creating ActiveX Components",
"Share data between C or C++ components" in EAServer
Programmer's Guide
Persistence for stateful components
State data can be stored either in memory or to a persistent data store.
In-memory storage offers better performance than persistent storage.
In-memory storage uses a mirror-pair model where data is replicated between
pairs of servers running in the cluster. Each client session has two points
of failure (the originating server, and its mirror-pair twin.)
Persistent storage uses a remote database to store component state. A
component instance can failover to any other server in the cluster where
the component is installed. Persistent storage requires a highly available
database, otherwise the database itself can become a single point of failure.
For components that participate in a transaction,
use isRollBackOnly to test if the transaction already doomed before the
method executes more logic that would have to be rolled back.
If a component performs updates to a non-critical
database (for example, logging usage statistics that are not considered
as mission-critical data) you can choose Not Supported as the component's
transaction attribute to eliminate the overhead of using two-phase commit.
By default, EAServer will wait indefinitely for open transactions to
be completed, unless a maximum has been set at the server level, or overridden
at the component level. When a specified maximum is reached, EAServer
will return an exception to the client.
By default, EAServer will wait indefinitely for instances to be released,
unless a maximum has been set at the server level, or overridden at the
component level. When a specified maximum is reached, EAServer will return
an exception to the client.
By default, EAServer will wait indefinitely to be able to create a new
instance of a component if a request arrives when the maximum number of
instances exist and are all busy. The wait time can be constrained if
desired.
com.sybase.jaguar.component.maxwait
Note: This property is applicable only when the com.sybase.jaguar.component.objects
property is set to a non-zero value.
For best performance, enable the Concurrency option and disable
the Bind Thread option.
Concurrency allows multiple method invocations to occur
simultaneously, which can decrease client response time.
Also, if your component has a run() method that executes
indefinitely, you must enable the Concurrency option
or no clients will be able to invoke methods.
Disabling the Bind Thread option allows EAServer to run
the component on any available thread. (This option should
only be enabled for ActiveX components and components
that use thread-local storage.)
Follow these suggestions for all types of Java components and applications.
Category
Performance Considerations
More Information
Result sets and JDBC Statements
If you use the Java Connection Manager (jcm) classes,
you must explicitly clean up java.sql.Statement objects to avoid
memory leaks. Before releasing a connection back into the cache,
call Statement.close() and set the Statement reference to null.
Several profiling tools are available to help identify bottlenecks,
memory leaks, and other performance issues in a Java components,
applications, and applets. Profiling can help you identify
code that needs to be modified or removed for performance
reasons.
For EJBs, follow these suggestions in addition to the ones provided for Java components, and for components in general.
Category
Performance Considerations
More Information
Lightweight EJB Container
EAServer 4.1.3 provides a lightweight EJB container, to optimize
performance for suitable EJB-to-EJB calls. This feature can be extremely
beneficial for calls from session beans to entity beans. There are specific
restrictions, so be sure to see the documentation to see where this feature
can be used in your application.
EAServer 4.1.3 includes customized wrappers for the Sybase jConnect and
Oracle JDBC drivers. The wrapper drivers offer better performance for
CMP entity beans by allowing updates to be deferred to the end of each
transaction and sent together as a command batch. As a result, network
round trips between the database server and EAServer are reduced.
The drivers include numerous settings that should be tuned for your application.
The EJB 2.0 architecture introduces local interfaces for
calls to an EJB component from within the same Java Virtual Machine. In
EAServer, you can use local interfaces for intercomponent calls, and for
component invocations made from Servlets and JSPs hosted by the same server
as the component.
Using local interfaces can improve performance, but in coding you must
be aware that parameters are passed by reference rather than by copy,
so object instances passed through a local invocation can be shared by
the client and component, and that the called component must be hosted
in the same server process as the calling component since Local interfaces
are not location transparent.
For best performance, set the Read Only property for all methods that
do not modify data. As a result, the ejbStore or ctsStore method is not
invoked after the business method returns.
In addition, if you are updating multiple fields, call the entity bean
from session bean with the transaction open, then do multiple sets in
entity bean, so only one ejbStore will occur instead of being called for
each set.
EAServer supports object and query caching for EJB entity beans and entity
components that use automatic persistence. Caching can improve performance
by minimizing the number of database select queries required for load,
finder, and select operations. Performance gains may range from 1.5 to
2 times faster for applications where most transactions are updates, and
from 3 to 30 times faster for applications where most transactions are
read-only.
Object Caching is off by default and can be turned on for all Components
and their finder methods that use Automatic Persistence.
To further optimize performance, you can;
turn on Query Caching if there are Entity Beans that have finder and
ejbSelect methods
set up database change notification so that updates and deletes do
not invalidate the cache
use named caches to tailor the cache sizes for individual components
or a group of components.
Object Caching is implemented in C++ by the CtsComponents/ObjectCache
component.
If for any reason you want to change the operating characteristics of
the ObjectCache component, you can implement the CtsComponents/ObjectCache
interface and employ that as your object caching mechanism instead.
Ideally, cache managers should be coded in C++ to avoid the overhead
of Java garbage collection.
For entity components that use automatic persistence, using timestamps
for concurrency control yields the best performance in most cases.
In optimistic concurrency control, use of the timestamp reduces unnecessary
database read operations for tables with many columns or large column
values (such as Sybase text or image columns).
EAServer uses relationship components to manage relationships
between EJB 2.0 CMP entity beans. The tables represented by related components
must be related in the database. To maintain the relationships, foreign
keys offer better performance than join tables, but can be used only when
one destination instance relates to a given source instance.
EJB 2.0 entity beans can use EJB Query Language (EJB-QL) in the EJB-JAR
deployment descriptor. EAServer translates EJB-QL to SQL at runtime. You
can configure additional EAServer query mapping properties to enable caching
of the query results for improved performance.
EAServer 4.1.2 includes new server properties to tune the buffers used
when creating servlet responses. EAServer utilizes both 4K and 8K buffers
for servlet responses. By default, 128 of the 4K buffers, and 128 of the
8K may be pooled.
You can change the maximum number of pooled. You could also disable the
pooling, which could degrade performance as the buffer is repeatedly allocated
and deallocated.
New in EAServer 4.1.2. For a faster response than with page caching,
you can cache specific servlets in Java core memory. There are limitations
on which servlets can use this feature; refer to the documentation for
details.
To improve the performance of Servlet and JSP requests, you can use the
page caching feature. When page caching is enabled for a Servlet or JSP
Web component, EAServer checks the cache before invoking the Web component.
If an appropriate response is found in the cache, EAServer returns the
contents of the cache, instead of calling the Servlet
Page caching is not enabled for any JSPs or Servlets by default. It must
be enabled on page by page basis as caching requirements might be different
for each JSP/Servlet See:
If possible, Servlets should be coded to be thread-safe so
the service method can be called concurrently from multiple threads. This
threading model is the default for Servlets running in EAServer, and in
most cases, offers the best performance
JSP / Servlet Performance Advantages over CGI, ISAPI, and
NSAPI
JSPs and Servlets provide superior performance and scalability because
they can be compiled, loaded into memory, and reused by multiple clients
while running in a single thread, and they can take advantage of connection
caching or pooling.
Additionally, they overcome many of the deficiencies of CGI, ISAPI, and
NSAPI. Although the CGI-BIN interface is not platform-specific, code has
to be recompiled for different platforms, and performance is poor for
large-scale applications because each new CGI request requires a new server
process. Similar platform-specific interfaces such as ISAPI and NSAPI
improve performance, but at the cost of even less portability.
The com.sybase.jaguar.webapplicaton.jspc-interval property value indicates
if and when the JSP runtime checks whether a JSP is current.
For best performance, set to -1 so the JSP runtime never checks.
If set to 0, the JSP runtime always checks.
To specify the number of seconds before the next check, set the value
to a number greater than 0. If a request comes in before the time expires,
the JSP is not checked.
You can set initialization and destroy timeouts for Web Applications,
and override most of the settings at the individual Servlet level. See
these properties for more information:
You can decrease the amount of time it takes to serve up
the first request to a Servlet by loading it on server startup with the
com.sybase.jaguar.servlet.load-on-startup property.
If you configure a C++ component to execute within
a dedicated external process, be aware the component will not utilize
EAServer transactions or connection caches.
The com.sybase.jaguar.component.objects specifies the maximum
number of component instances that can exist at once. For
a C++ component that runs as an external process, it specifies
the maximum number of simultaneously running external processes.
If a request arrives when the maximum number of instances exist
and are all busy, the request blocks, with blocking time constrained
by the Maximum Wait setting.
After a method finishes all operations on a collection,
release the reference and all shared variable references. This
helps to prevent memory leaks. Releasing collection and shared
variable references does not release the shared variable values.
You can define get and set methods that control runtime
properties for your component. However, using get and set methods
to access properties over a network decreases performance
In addition to good design and coding practices you would follow for any PowerBuilder applications, follow these suggestions for PowerBuilder components deployed to EAServer.
Category
Performance Considerations
More Information
Version recommendation
For best performance, upgrade to a minimum of PowerBuilder
8.0.3 and EAServer 4.1.3. These two versions include coordinated changes
that are designed to improve performance for PowerBuilder components running
in EAServer. Improvements include improved memory management and reduced
virtual address space.
PowerBuilder 8.0.3 readme file
Datastore row height size
If you are retrieving a lot of rows of data, try setting
the datawindow.detail.height.autosize property for the datastore object
to false. Depending on the number of rows being retrieved, disabling this
property can have a significant -- or even dramatic -- impact on performance.
If you have autosize enabled for the height or width of any specific objects,
try disabling those settings as well.
There are a number of steps you can take to reduce the memory
footprints of DataStores. Documentation includes an explanation of system
resource utilization, monitoring tips, and suggestions.
A technique for sharing class group loaders can be used
to reduce the memory requirements -- sometimes dramatically -- of EAServer
when running multiple PowerBuilder components.
For large retrievals or imports into a DataWindow object, set the datawindow.storagepagesize
property to large. Setting this property allows the DataWindow to most
efficiently use the available virtual memory. While the setting LARGE
is recommended, a setting of MEDIUM is also available.
PowerBuilder 7.0.3 readme, and in online help for later
versions.
Bind Thread property
Do not use Bind Thread unless it is required in your environment:
In Unix deployments, it is not required -- set it to false for all
components
In Windows deployments using PowerBuilder 8.0.3 or higher, it is not
required -- set it to false for all components
In Windows deployment using a version less than 8.0.3, it is not required
if you only use local variables for datastore references -- set it to
true only if you declare a DataStore as an instance or global variable.
If the Bind Thread property is set to true, be sure to utilize Named
Instance Pools, which is described in the Components
in general section.
In the development environment, this property must be set to TRUE if
you are using live editing to build your component. Remember to change
it to FALSE on deployment if possible.
If you do not use a feature such as display formatting, validation rules,
or client-side scripting, you can enhance performance by preventing the
server component from generating code for the unused feature.
You can also cache client-side methods in JavaScript files to reduce
the size of the generated code and increase performance on both the server
and the client. Without JavaScript caching, each time a Web DataWindow
is rendered in a client browser, JavaScript code for DataWindow methods
is generated on the server and downloaded to the client. However, there
is no performance gain if the client web browser settings prevent caching.
Using a customized component instead of the pre-installed HTML generator
component allows you to set properties for your component in Jaguar Manager.
Setting properties reduces the number of method calls required to configure
the component and can result in improved performance, maintainability,
and scalability.
Specifically, you can set the source file and DataWindow object on the
server so that the DataWindow object is loaded when the component instance
is created, resulting in fewer method calls from server-side scripts in
the Web page. You can also improve performance by having your custom component
maintain its state.
By default, the PSJaguarConnection methods for using a Web
DataWindow make several trips to the server. You can set the bOneTrip argument
to make one trip to the server instead.
This section contains suggestions for the EAServer Message Service.
Category
Performance Considerations
More Information
Releasing resources
EAServer allocates resources for each of these objects: connections,
sessions, message consumers, and message producers. When you no longer need
one of these objects, you should close it to release its resources and help
the application run more efficiently.
SHARED_LISTENER Indicates whether multiple clients can simultaneously
receive messages from the queue. When a queue is not shared, only one client
at a time can receive messages from it
REQUIRES_TRANSACTION determines whether JMS publish, send,
receive, and onMessage calls can participate in a transaction. If you set
this to false, it significantly improves performance throughput for transient
message bulk processing
To provide permanent destinations for JMS client applications,
define message queues and message topics using Jaguar Manager. When you
create a permanent destination, you can optimize its configuration properties,
which benefits every JMS client application that uses the destination.
By default, the Reader, Writer and Worker Threads are set to 0.
For high-volume client notification with transient messages, you can
improve performance by tuning the number of reader and writer threads
if it improves throughput.
For component notification, you can prevent or allow parallel message
processing by changing the worker threads setting.
Be sure to follow good coding practices for the language you write the client application in.
Additionally, follow these suggestions for clients you plan to use with EAServer.
Category
Performance Considerations
More Information
Client Design Issues
In designing your client, plan to optimize network performance
by keeping traffic between the client and components on the
server to a minimum. To optimize network performance, plan
to:
Cache property changes in client data structures
Validate field values on the client
Update only the rows and columns that have changed
Group data changes into larger sets with fewer method
calls
Compress large blobs before passing them between server
and client. Some free data compression tools are available,
including zlib.
The IdleConnectionTimeout property specifies the amount of time
a connection is allowed to sit idle. By default, connections
do not timeout. Specifying a finite timeout for your client
applications can improve server performance. If many instances
of the client run simultaneously, a finite client connection
timeout limits the number of server connections that are devoted
to idle clients. A finite timeout also allows rebalancing
of server load in an application that uses a cluster of servers.
For C++ clients, use the ORBIdleConnectionTimeout option.
For CORBA-Java clients -- If you specify an idle connection timeout,
make sure the garbage collection interval (com.sybase.CORBA.GCInterval)
is set to an equal or lesser value
"Creating EJB Clients", "Creating Java-CORBA
Clients", "Creating C++ Clients" in EAServer
Programmer's Guide
Specify the number of times that a network connection may be
reused to call methods from one server. The default is 0,
which indicates no limit. The default is ideal for short-lived
clients. The default may not be appropriate for a long-running
client program that calls many methods from servers in a cluster.
If sockets are reused indefinitely, the client may build an
affinity for servers that it has already connected to rather
than randomly distributing its server-side processing load
among all the servers in the cluster. In these cases, the
property should be tuned to best balance client performance
against cluster load distribution. In Sybase testing, settings
between 10 and 30 proved to be a good starting point. If the
reuse limit is too low, client performance degrades.
Web proxies can be used to improve network performance,
by caching the results of frequently executed Web requests. Web
proxies typically act as a gateway for outgoing connections from
a group of workstations, and are sometimes used to enhance network
security, by restricting and/or logging the protocols and servers
used in client connections.
By default, the client ORB attempts to open IIOP connections,
then attempts an HTTP-tunnelled connection if plain IIOP fails.
Since Web proxy connections require HTTP tunneling, set the
following property to true to eliminate the performance overhead
of trying plain IIOP connections before trying HTTP-tunnelled
IIOP.
SSL reuses the previously negotiated security session parameters in a
number of short-lived connections, which results in a relatively large
performance gain over setting up completely new security sessions for
each connection. When a security session is reused, clients avoid a CPU-intensive
encryption of the premaster-secret using the server's public key. Similarly,
servers avoid a CPU-intensive decryption of the premaster-secret using
its private key. By configuring these parameters, you can control SSL
caching on the server side.
The com.sybase.jaguar.server.http.force.close property specifies whether
HTTP-tunnelled IIOP connections should be closed after sending each IIOP
response. When debugging proxy configurations, you can set this property
to true if it helps your debugging efforts. This setting degrades server
performance, so it should only for debugging purposes.
EAServer 4.1.3 adds the ability to establish HTTPS connections between
your Web server redirector and EAServer. SSL session IDs are cached for
reuse by the client. This improves performance if the client is frequently
connecting and disconnecting to the same server.
The associated cache size, session duration, and current connections
for the session can be tuned as needed.
This is an optional property that specifies the length of time, in seconds,
to keep a connection alive before it is closed by EAServer. The default
value is 120 seconds (2 minutes) and can be modified, if necessary, to
improve performance.
This optional property determines the number of requests processed before
EAServer closes the connection. The default value is 100 and can be modified,
if necessary, to improve performance.
Good database and query design is essential for database performance in general.
Additionally, these suggestions are applicable to working with databases
in EAServer.
Category
Performance Considerations
More Information
Physical Database Connections
Physical database connects are very expensive. You can reduce the cost
using EAServer connection caches. A connection cache maintains a pool
of connections to a database\ server, increasing performance by allowing
connection sharing and reuse. Since more clients can be serviced using
fewer third-tier connections, CPU time and memory are not consumed by
opening more connections than necessary.
You can set the pool size using the Number of Connections
in Cache property. After a connection is released, it is returned to the
pool. The default value is 10. You can increase this number if performance
suffers due to an insufficient number of available connections. To tune
the number of connections, use runtime monitoring to ensure that there is
not a large number of Forced Connections.
Disable connection sanity check. When the option is enabled, EAServer
verifies that the connection is open and accepts commands before making
it available for reuse. Disabling the option increases performance, but
may complicate debugging. For example, components may release a connection
that is not ready for use by another component, such as when there is
unretrieved results on the connection.
Ensure that connection caches that utilize a com.sybase driver
class are defined with the DYNAMIC_PREPARE property set to FALSE for optimal
performance. In EAServer 4.1.1 and above, this property is set to FALSE
by default. However, it may have been set to TRUE by default in earlier
versions. In EAServer 4.1.1 and above, a warning is printed in the log file
if a connection cache has this property set to TRUE. For earlier versions,
the warning is not printed.
Connection Cache Size
The default value of 10 is probably too low for most production
applications, and should be monitored and tuned based on your application
needs. By default, connections are refused if there are no available connections
in the pool. However, it is possible to change the behavior to wait until
a cache is available, or to force a new connection to be made. Optimally,
the number of connections defined for the cache should be enough to service
the normal load of connection requests, so there are not an excessive amount
of refusals, waits, or forces.
Connection Management in C, C++, and ActiveX components
ActiveX, C, and C++components can call the Connection Manager
routines to take advantage of connection caching. These routines manage
caches of ODBC, Client-Library, or Oracle Call Interface (OCI) connections.
When there are many configured caches, a component can achieve better performance
by passing the cache handle explicitly in JagCmGetConnection to eliminate
repeated internal table searches.
JDBC driver properties can also provide good performance boots depending
on what you enable/disable.
To help you choose a driver type, read the JavaWorld article " JDBC
drivers in the wild" to learn the differences between JDBC driver
types, and how to benchmark them.
Documentation for the JDBC driver you are using
jConnect
The jConnect documentation includes a chapter devoted to
the ways to fine-tune and improve performance when working with jConnect.
Some operating systems fully utilize multiple CPUs, while
others do not. Depending on the OS you are using, you may need to bind EAServer
to each CPU in order to take advantage of the multiple processors.
On UNIX platforms, concurrent client connections to EAServer are limited
by the operating system limit for the number of file descriptors that
can be opened in one process. Before you start the server, set the file
descriptor limit in the shell where you will start the server.
For example, to set the limit to 1024:
Using a text editor, open the bin/serverstart.sh file.
Below the first comment block, add this line:
ulimit -n 1024
See your UNIX documentation for more details on the ulimit
command
AIX memory
A document is available that describes tuning options available
to customers running EAServer 4.2 on AIX. It provides guidelines for utilizing
large address space, and tuning JVM heap size and MAXDATA.
You should always stress test an application before putting
it into production. A variety of stress testing tools are
available, to help you simulate a load to test if the application
will scale and perform at acceptable levels. Some of the tools
are available free of cost. For example, OpenSTA is free from
www.opensta.org
Benchmarking
A whitepaper is available that points out the fundamentals involved in
an application server benchmark, and outlines the results for EAServer
tests for the nile.com benchmark. In addition, EAServer results are posted
for these benchmarks:
If you are connecting to a database server on the same
machine as the Web server, do not select Client as the Agent. This
would result in the local connection being made through the network,
which would cause a decline in performance.
"Setting up the Adaptive Server Anywhere database
server for PowerDynamo" in the PowerDynamo
User's Guide
Text substitution
Rather than text substitution, significant performance
improvements can result in some circumstances using host variables
in a SQL statement, since it can be executed repeatedly without
being reparsed
If a script or template does not require any connections
to a database to complete execution, specifying <no connection>
in the definition, so that no connection object is created during
the execution of the document.
Java classes can be accessed from within a database
or within the file system. If you do not need the Java classes
stored in the database (for replication or other reasons), you
should store them in the file system for performance reasons.
Parsing large documents with toDOMDocument can be expensive.
Design your site so this occurs as infrequently as possible. You
can avoid unnecessary parsing of the document by attaching the
DOMDocument object to the session object.
The Global Sort component, which provides high performance
sorting of small to medium length lists and supports multiple alphabets
and sort orders. This feature is documented in Using Global Sort.
The XML conversion module (XCM) tool is a high-performance
EAServer component development tool that provides encoding verification
and character set conversion for XML data. Using the XCM Tool describes
how to use this feature.
EAServer 4.1 introduces Java-to-IDL and IDL-to-Java code generation optimizations.
These optimizations can increase your productivity when you deploy Java
based applications with complicated component class hierarchies and when
you generate Java stubs for these applications. The J2EE EAR importer,
EJB JAR importer, and the Java code generator have been enhanced to allow
you to specify a code generation strategy as follows:
Full - Always generates Java or IDL types for every interface
and type.
Incremental - Compares IDL and Java timestamps to determine
whether new versions must be generated. Java timestamps
are maintained in a database in the EAServer repository.
Optimistic - Similar to Incremental, except that the check
for changed types in each IDL module or Java package
ends if the first comparison indicates no change.
EAServer supports hot refresh of components by using
a Java class loader. This feature speeds the development process
by allowing you to deploy new class versions without restarting
the server. To enable refresh, set com.sybase.jaguar.component.refresh
to true, which is set by default.
Last Revised: Jun 10, 2003 Product: EAServer Technical Topics: Java, Application Servers, Performance & Tuning, Component-based Development, Internet Application Development
Business or Technical: Technical Content Id: 1019504 Infotype: Technote
