The performance tips given in this section are intended to help Branch
Transformation Toolkit solutions achieve the best performance results. A solution
architect should decide, based on the solution design, which of the following
suggestions apply.
- Object cache:
- The caching of formatters and operations is enabled or disabled in the
configuration file (check enableFormatsCache inside the initialization
section). However, the application must exploit this feature by returning
objects to the cache.
- The HTML Connector returns all the mapper formatters to the cache. Only
cacheable objects are cached.
- Configuration file:
- The toolkit expects some configuration settings to be available in the
configuration file. If these settings are not available, internal exceptions
are thrown and trace entries are generated, thus consuming CPU cycles even
though the default values are still used. When migrating existing applications
to an environment where a new product release is installed, consider reviewing
the provided configuration file and identifying the changes. An example is
the "queueBufferSize" settingn at the main settings level, which defaults
to 12. Also, consider removing any setting not required in your solution from
the configuration file.
- Shared typed data descriptors:
- With the addition of the parameters Hashtable into the base data element
class, any data element instance may have its own parameters and reuse the
same data descriptor instance associated with the unique data type, thus also
reusing the type converters and validators. Check the "shareDataDescriptors"
setting inside the initialization section of dse.ini.
- Mapper formatters:
- When defining mappers to map elements from/to a flow to/from an operation
or subflow, use DataMapperConverterFormat instead of DataMapperFormat. Also,
consider using byReference="true" for each of the mapping elements (always
keeping in mind the implications that this behavior may have in the context
hierarchy).
- Data access:
- Avoid using wildcards when using the getValueAt access method. Use complete
data element's paths instead.
- Synchronized code:
- The application flow definitively needs to synchronize those critical
code lines when they are executed from concurrent threads (such as arranging
the context hierarchy). However, big chunks of synchronized code lines may
represent a bottleneck in the solution and reduce the overall throughput.
- Services access and pooling:
- Usually, a solution seeks to improve performance when launching business
operations after logging on. It is therefore good design to perform as much
process as possible during the initialization of the services, during the
session establishment or user logon, so that the actual business processes
execute as quickly as possible.
- To avoid bottlenecks while accessing services that cannot be re-entered
from concurrent users/threads, use services pools. The number of services
in the pool must be sized according to the expected load rate. Correct sizing
will have a definitive impact on the overall solution throughput.
- Formatter decorators:
- When a record formatter definition includes many formatter entries followed
by the same kind of decoration (such as a fixed "#" as a delimiter), consider
extending the formatter class to include the decoration inside the format
process. This mechanism will create only one object (usually a StringBuffer)
instead of several strings.
- Exceptions that are part of the normal flow:
- Avoid exceptions that are normal during the application execution flow
(such as DSEObjectNotFound).
- Extended classes to be customized:
- Classes available in extension packages (such as com.ibm.dse.automaton.ext
and com.ibm.dse.base.types.ext) are especially provided to be further extended
in a solution. Consider extending these classes both to add your own logic
and to remove non-required logic.
- Client/Server Mechanism:
- Consider using a compression decorator in the client/server request and
response formatters to minimize the amount of data sent through the communications
network.
- JSPs.
- Use JSPTags instead of JSPBeans.
- Consider a solution based on an XML-formatted data set being returned
to the client and processed by a template processor in the client (XSLT).
The corresponding request handler may be extended to build a faster stream
based on formatters instead of JSPs. This approach requires less network bandwidth
and is faster than building the response on the server. However, it has other
implications that need to be considered such as the XSL support in the Web
browsers.
- Deployed JARs:
- Choose only the JARs that belong to the components that are used in the
solution. Keep JAR files granular and as small as possible.
- High availability, load balancing, failover, and session persistence:
- 24x7 available solutions have a very high performance or monetary cost.
Consider using load balancing with session affinity, so that once the user
establishes a session with a server image or clone, all the requests will
be routed to that clone. If session persistence is enabled, tune the minimum
boundary size of the session data to be persisted in order to enable compression
(check setting minSizeForCompression inside the initialization section of
DSE.INI).
- Trace:
- Do not use the product trace mechanism as an application log. Instead,
use database access services for this purpose.
- Configure the trace settings according to the running environment. Settings
such as whether to trace to file, intermediate buffer size (linesOfBuffer),
and showOriginator have direct impact on the solution performance.
- Use the Trace.doTrace method as a Boolean condition for tracing (before
using the Trace.trace method) in the application flow, to check whether the
system will trace the entry based on the external configuration. The application
will only create the string if the returned Boolean for the doTrace method
is true.
- Application sessions table management:
- The application is responsible for maintaining the sessions table through
the Context class protocol. It is crucial to clean session information from
the table when the user logs off or when a session expires, to avoid apparent
memory leaks and performance degradation. Both session entries and processor
instances maintained in a session need to be removed from the table. Processor
instances available in the cache also need to be removed in these cases.
- JDBC Table access services:
- Consider using stored procedures when requiring access to several tables
in the application flow. Cross-logic against several tables using many JDBC
Table access calls is not recommended.
- Java(TM) Profiler:
- Identifying the objects that are created most often and the classes and
methods that use more CPU time during the request process is crucial to optimizing
the solution performance. Any Java profiler may be used to get this information,
and this is a task that should be done during the whole development cycle,
without waiting until the final implementation of the solution.