Chapter 3: Component Tuning  Java component performance

Chapter 3: Component Tuning

Common component performance issues

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.


Tracing and debugging settings

Tracing properties enable additional logging, which can be useful when debugging problems. However, tracing requires additional file I/O and computation. For best performance, disable all tracing and debugging properties. An easy way to do this is to run the performance and tuning wizard on your components.


Thread-related issues

EAServer is scalable because it is multithreaded and multiprocessor-safe, using a thread pooling model to run components. Ideally, a component:

These settings affect the threaded execution of your component.


Bind thread

The Instances/Bind Thread setting in the EAServer Manager Component Properties dialog box specifies whether component instances must be bound to the thread that creates the instance. You can also set this property as com.sybase.jaguar.component.bind.thread using jagtool.

This option decreases scalability. Twice as many threads are needed to run the component, since each instance requires the client thread plus another thread bound to the component. Also, while the thread is bound to the instance, it cannot be pooled and used to service requests involving other components.

Enable this option only for ActiveX components, PowerBuilder components if required (see “PowerBuilder component performance”), and components of other types that use thread-local storage. Otherwise, disable this feature so EAServer can run the component on any available thread.


Concurrency

The Instances/Concurrency setting in the EAServer Manager Component Properties dialog box specifies whether component instances can execute concurrently on multiple threads. You can also set this property as com.sybase.jaguar.component.thread.safe using jagtool.

Enable this option for any component that is thread-safe. Concurrent access can decrease the response time of client method invocations. If this option is disabled, EAServer serializes all method calls to the component. Concurrency applies to execution of all instances. With concurrency disabled, a call to one instance cannot overlap the execution of another instance.

If the Sharing setting is enabled for your PowerBuilder component, disable the Concurrency setting. PowerBuilder is thread-safe at the session level only. For other component types, concurrency requires that your implementation be thread-safe. The requirements depend on the value of the Sharing setting as described in Table 3-1.

Table 3-1: Coding requirements to support concurrency

Sharing enabled?

Coding requirements

No

Protect any static instance variables; synchronize access to them to prevent concurrent access from different threads. Exceptions to this rule are read-only static variables, such as those 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.

Yes

Same as the above, but you must protect all instance variables since one instance is called by multiple threads.

If you enable the Concurrency setting for a component that does not meet these requirements, you may encounter hard-to-diagnose threading errors such as race conditions. In a race condition, multiple threads update the same data simultaneously. The outcome of conflicting updates is unpredictable and may cause crashes or incorrect results.


Sharing

If the Instances/Sharing option is enabled in the EAServer Manager Component Properties dialog box, a single instance serves all client requests. You can also set this property as com.sybase.jaguar.component.sharing using jagtool.

For best performance, this option requires that you also enable the concurrency option. However, if your component has read-write static or instance variables, you must synchronize all access to them. This can create bottlenecks where threads wait to access synchronized data or methods. Such bottlenecks can reduce performance and may lead to larger problems such as deadlock or starvation. Also, in a cluster, the component is not a true singleton object: while one instance runs per server, multiple instances run in the cluster, one instance per server. For these reasons, Sybase recommends that you avoid the Sharing/Singleton pattern if your implementation has read/write static or instance variables.

You can use sharing and concurrency without synchronization if your implementation has no read/write static or instance variables. This can reduce memory use since only one instance is loaded. However, the effect is likely to be negligible unless the implementation class is very large.


Thread monitors

Thread monitors provide a means to limit the execution time devoted to specified components and component methods. You can assign components and methods to a thread monitor to ensure that no more than a specified maximum number of threads will be active at any point executing the methods and components assigned to the monitor.

You can also use thread monitors without a limit on the number of threads. Doing so allows you to use the monitor trace properties to record performance data.

Thread monitors are not active for component calls that use the lightweight container (see “Lightweight container”).

NoteAlternatives to thread monitors As an alternative to configuring thread monitors to govern component load, you can configure response-time threshold monitoring for your application components or network listeners. For more information, see Chapter 9, “Using the Performance Monitor.”

To create or configure a thread monitor, follow the instructions in Thread monitor properties in the EAServer System Administration Guide.

StepsAssigning a component or method to a thread monitor

  1. Display the properties for the component or method, then display the Advanced tab.

  2. For a component, if the com.sybase.jaguar.component.monitor property is not present, add it. Otherwise modify this property. Set the value to the name of the thread monitor.

    For a method, if the com.sybase.jaguar.method.monitor property is not present, add it. Otherwise modify this property. Set the value to the name of the thread monitor.

  3. Regenerate and recompile the component skeleton.


Stateful versus stateless components

A component that remains bound to a client instance between consecutive method invocations is called a stateful component. A component that can be unbound from the client after each method call is said to be a stateless component. Typically, an application built with stateless components offers the greatest scalability. In the stateless model, each instance can serve different clients during the “think time” that is typically seen in interactive applications. In the stateful model, each client requires a dedicated component instance for the lifetime of the client session.

You can either configure stateless behavior, or code the component to call the appropriate lifecycle control method to unbind the component instance from the client reference in each business method. For more information, see “Component lifecycles” in the EAServer Programmer’s Guide for more information.

The stateless model requires an implementation that supports stateless execution. For example, if your component requires two subsequent invocations to compute a result for the client, it will break if you change the component properties to enable stateless behavior.

If you use stateful components, configure the Instance Timeout setting on the Component properties: Resources tab in EAServer Manager or by setting the com.sybase.jaguar.component.timeout property with jagtool. This setting limits the time that an instance can be bound to a client session.


Instance pooling

Instance pooling allows a single component instance to service multiple clients. Rather than creating a new instance for each client, EAServer maintains a pool of instances for reuse to service multiple clients. Instance pooling increases performance by eliminating the overhead of creating new instances for each client session. EAServer supports pooling of EJB components by default. “Component lifecycles” in the EAServer Programmer’s Guide describes how you can implement components of other types that support pooling.


Configuring component instance pool properties

To enable pooling, set the Pooling option on the Instances tab in the EAServer Manager Component Properties dialog box. You can set this property as com.sybase.jaguar.component.pooling if using jagtool.

You can configure the number of instances pooled for a component by configuring the properties in Table 3-2. These properties are found on the Resources tab in the EAServer Manager Component Properties dialog box.

Table 3-2: Component instance pooling properties

Property

Description

Maximum pooled instances

Specifies the maximum pool size. If the maximum pool size is reached, EAServer destroys excess instances after deactivation. The default is 0, which means no limit.

Minimum pooled instances

The minimum pool size. The default is 0.

Named instance pool

Specifies that the component shares space in a named instance pool, as described in “Named instance pools”.

Maximum active instances

Specifies the maximum number of instances that can exist at the same time. For a C++ component that runs as an external process, 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.

Maximum wait

Specifies the maximum client wait time when the Maximum Active Instances property is set to specify a limit on the number of simultaneous active instances and the limit has been reached. The request blocks, with blocking time constrained by the Maximum Wait property. If the blocking time expires, the caller receives a CORBA::NO_RESOURCES exception.

While instance pooling can decrease client response time, it can also increase memory usage in the server. If pooled instances often sit idle, the memory used for pooling is wasted.

You can configure the maximum and minimum pool size to constrain the memory used to maintain an instance pool. For example, a heavily used component should have higher minimum and maximum pool sizes than a less commonly used component. If a component has periods of high use followed by low use, you can set a minimum size to allow the instances to be released during times of low use. Doing so frees memory for use by other components.

EAServer does not preallocate instances for the pool. The pool size grows as additional instances are required to satisfy client requests, up to the maximum specified size (if a maximum size is specified). Once the minimum pool size is reached, the size will not shrink below this size. To release idle pooled instances, EAServer has a garbage collector thread that runs periodically. Each time it runs, the garbage collector removes one idle instance from the pool, unless the minimum pool size has been reached.

If you configure a minimum pool size, configure a maximum size that is slightly larger. The difference between the maximum and minimum size provides a damping factor that prevents repeated instance allocation and deallocation if the actual pool size hovers near the minimum size.

If the maximum pool size is reached, EAServer still creates new instances, but destroys them immediately rather than placing them in the pool. You can set the Maximum Active Instances property to put an absolute limit on the number of instances that can run. Doing so allows you to partition the server resources among different components.

You can monitor the effectiveness of these settings by checking the Maximum Pooled Instances and Peak Maximum Instances Pooled setting for the package that contains your components. Ideally, the number of instances should rarely rise above the number of pooled instances. See “Using the Runtime Monitor” in the EAServer System Administration Guide for more information.


Named instance pools

Named instance pools provide more administrative control over how components are pooled. This feature allows you to control the number of component instances that EAServer creates for a set of components. Set the com.sybase.jaguar.component.instancePool property to assign your component to a pool other than the default. If this property is not set, the component runs in one of the default pools described in Table 3-3.

Table 3-3: Preconfigured instance pools

Name

Description

Maximum number of instances

SystemPool

The default for components whose Instances/Bind Thread property is disabled.

infinite, denoted by -1

BindThread

The default for components whose Instances/Bind Thread property is enabled.

512

By default, EAServer assigns components that do not have the Bind Thread setting enabled to SystemPool. This pool imposes no limit on the number of instances. For components placed in SystemPool, the component’s properties control how many instances can be pooled.

The BindThread pool has a limited size that you can modify. As described in “Bind thread”, components that run with Bind Thread are resource intensive. Setting a limit on these instances prevents them from monopolizing the available threads.

You can create new pools with different instance pool settings to partition the memory used to run different components. For example, you can create a larger instance pool for frequently used components and create smaller pools for seldom used components.

In EAServer Manager, you can manage the instance pool settings in the top-level Instance Pools folder. Sybase recommends that you do not modify the SystemPool settings, or create new pools that have no size limit.

StepsCreating an instance pool

  1. Highlight the Instance Pools folder.

  2. Select File | New Instance Pool. The Instance Pool Wizard appears.

  3. Follow the wizard pages to configure the properties.

StepsViewing or modifying an instance pool

  1. Expand the Instance Pools folder.

  2. Highlight the instance pool you want to modify and choose File | Properties.

  3. In the Instance Pool Properties dialog box, on the General tab, enter a description and the maximum number of instances. By default, the maximum number of instances is set to 512. Sybase recommends that you do not create an instance pool with the maximum number of instances set to -1 (infinite). If you need an instance pool with an unlimited number of instances, use the preconfigured SystemPool.

  4. To enable debugging, which writes instance pool information to the server log file:

    1. Select the Advanced tab.

    2. Click Add.

    3. Enter these values:

NoteYou must refresh an instance pool or refresh the server before any changes to instance pool properties take effect.

StepsRefreshing an instance pool

  1. Expand the Instance Pools folder, then highlight the instance pool you want to refresh.

  2. Choose File | Refresh.

StepsAssigning a component to an instance pool

If you do not specify an instance pool for a component, EAServer assigns one of the default instance pools automatically using the following criteria. If a component’s Instances/Bind Thread property is enabled, EAServer assigns the component to the BindThread instance pool; otherwise, it assigns the component to the SystemPool instance pool. If you enable the Instances/Bind Thread option for a component in the SystemPool, EAServer changes the instance pool selection so the component uses the BindThread instance pool.

Assign the component to an instance pool as follows:

  1. In EAServer Manager, highlight the component to assign to an instance pool.

  2. Select File | Properties.

  3. On the Resources tab, select a Named Instance Pool from the drop-down list.

StepsDeleting an instance pool

  1. Expand the Instance Pools folder.

  2. Highlight the instance pool you want to modify and choose Edit | Delete.

NoteYou cannot delete the preconfigured SystemPool or BindThread pools.

StepsManaging instance pools using jagtool

  1. You can also use these jagtool commands to create and configure instance pools: copy, create, delete, list, props, refresh, and set_props. For example, to create a new instance pool called “MyPool,” use this syntax:

    jagtool create InstancePool:MyPool
    

Optimizing intercomponent calls

If your components make many intercomponent calls, you can use one of the following techniques to improve performance:





Copyright © 2005. Sybase Inc. All rights reserved. Java component performance