|
Section 3: Components
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.
- Components in general
- Service components
- java">Java components
- EJBs
- Web components (JSPs and Servlets)
- C++ components
- C components
- ActiveX components
- PowerBuilder components
Components In General
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
Instance pooling
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.
EAServer 3.6.1 ESD4 Release Bulletin, and EAServer 4.1.1 Release Bulletin
Bind Thread
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.
"Component properties: Instances" in EAServer Programmer's Guide
Bind Object
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.
"Component properties: Instances" in EAServer Programmer's Guide
Concurrency
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.
"Component properties: Instances" in EAServer Programmer's Guide
java.sun.com/developer/Books/performance2/chap3.pdf">Race Conditions and Mutual Exclusion on the Sun java.sun.com/developer/Books/performance2/">Java Developer Connection
Sharing
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.
"Component properties: Instances" in EAServer Programmer's Guide
Stateless versus Stateful components
Use stateless components whenever possible. Rather than using a stateful component, consider one of these alternatives when you need to accumulate data across method invocations;
- 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.
"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.
"Managing Persistent Component State" in EAServer Programmer's Guide
Releasing connections and other resources
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 for the component, so the component is automatically deactivated after every method invocation.
"Supporting early deactivation in your component", "Using transaction state primitives", "Component properties: Transactions" in EAServer Programmer's Guide
Efficient Coding for Transactions
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.
"Defining transactional semantics" in EAServer Programmer's Guide
Tracing and Debugging
Be sure all tracing and debugging flags are turned off in the production environment. These properties include:
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
