- 303 -
}
In most cases, you will find that a customized classloader is the best solution, especially because you can include consistency checking within that classloader, as well as ensuring atomicity of
changes. You can even provide unloading and loading of classes, which is probably the most sophisticated solution available for runtime patching.
13.7 Performance Checklist
•
Consider performance at each stage of the development cycle.
o
Plan for tuning phases.
o
Leave code tuning until after the code is functional and debugged.
o
Consider how a particular performance change will affect other parts of the application.
o
Identify performance limitations.
o
Eliminate performance conflicts.
o
Consider how the performance scales as the application scales.
o
Consider how the performance scales as the application load varies.
•
Determine the general characteristics of the application in the analysis and design phases.
o
Minimize the features in the requirements.
o
Specify performance boundaries and goals.
o
Consider the numbers, sizes, and sources of objects, data, and other parameters of the application.
o
Create an abstract model of the application to identify any performance problems.
o
Design applets to engage the user as soon as possible.
o
Identify and focus on the performance costs of shared resources.
o
Target decoupling, indirection, abstraction, and extra layers in the design.
o
Predict the performance of design elements that block, copy, queue, or distribute.
o
Consider alternative designs that bypass or reduce high performance costs.
o
Avoid transactions where possible.
o
Minimize transaction time where transactions are necessary.
o
Lock only where the design absolutely requires it.
o
Design parallelism into the application wherever possible. Identify what cannot be parallelized.
o
Watch out for too much parallelism. There are diminishing returns from parallelism overheads.
o
Balance workloads. Unbalanced parallel activities may limit the performance of the system.
o
Split up the data among many different files preferably on separate disks.
o
Support asynchronous communications.
o
Decouple activities so that no activity is unnecessarily blocked by another activity.
o
Minimize points where parallel activities are forced to converge.
o
Design for redundant servers and automatic switching capabilities.
o
Consider using batch processing.
o
Design more flexible method entry points to your classes, to provide greater performance flexibility when developing reusable code.
•
Partition distributed applications according to the data and processing power requirements of components.
o
Minimize the communication between distributed components.
o
Avoid generating distributed garbage.
o
Reduce transfer costs by duplicating data.
o
Cache distributed data wherever possible.
- 304 -
o
Minimize the synchronization requirements of duplicated data.
o
Use compression to reduce transfer time.
•
Design objects so that they can be easily replaced by a faster implementation.
o
Use interfaces and interface-like patterns e.g., the factory pattern.
o
Design for reusable objects.
o
Use stateless objects.
o
Consider whether to optimize objects for update or for access.
o
Minimize data conversions.
o
Minimize the number and size of developed classes for applications that need to minimize download time.
•
Constantly monitor the running application.
o
Retain performance logs. Choose one set as your comparison standard.
o
Monitor as many parameters as possible throughout the system.
o
Note every single change to the system. Changes are the most likely cause of performance variations.
o
Listen to the application users, but double-check any reported problems.
o
Ensure that caching effects do not skew the measurements of a reported problem.
•
Make the user interface seem fast.
•
Train users to use the application efficiently.
•
Minimize server-maintenance downtime.
Chapter 14. Underlying Operating System and Network Improvements
If you control the operating system and hardware where the application will be deployed, there are a number of changes you can make to improve performance. Some changes are generic and affect
most applications, while some are application-specific. This chapter applies to most server systems running Java applications, including servlets , where you usually specify or have specified to you
the underlying system, and where you have some control over tuning the system. Client and standalone Java programs are likely to benefit from this chapter only if you have some degree of
control over the target system, but some tips in the chapter apply to all Java programs.
I dont cover operating-system and hardware tuning in any great detail, though I give basic tips on monitoring the system. More detailed information on Unix systems can be obtained from the
excellent book System Performance Tuning by Mike Loukides OReilly. Another more specific book on Suns Solaris operating system is Sun Performance and Tuning, by Adrian Cockcroft and
Richard Pettit Prentice Hall. A couple of relevant Windows systems books are Windows NT Performance Monitoring, Benchmarking, and Tuning, by Mark T. Edmead and Paul Hinsberg New
Riders and Windows NT Applications: Measuring and Optimizing Performance, by Paul Hinsberg MacMillan Technical Publishing.
It is usually best to target the operating system and hardware as a last tuning choice. Tuning the application itself generally provides far more significant speedups than tuning the systems on which
the application is running. Application tuning also tends to be easier though buying more powerful hardware components is easier still and a valid choice for tuning. However, application and system
tuning are actually complementary activities, so you can get speedups from tuning both the system and the application if you have the skills and resources.
Here are some general tips that apply for tuning systems:
