The performance tips given in this section are intended to help Bank 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. However, the application must exploit this feature by
returning objects to the cache.
- 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. Also, consider
removing any setting not required in your solution from the configuration
file.
- 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 many
processes 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.btt.automaton.ext
and com.ibm.btt.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 and do not use 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.
- Trace:
- Use the BTTLog.doXXX(doDebug/doInfo/doWarn/doError/doFatal) method
as a Boolean condition for tracing 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 doXXX method is
true.
- 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™ 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.