- 301 - You need to differentiate between:
•
Occasional sudden slowness, e.g., from background processes starting up
•
General slowness, perhaps reflecting that the application was not tuned for the current load, or that the systems or networks are saturated
•
A sudden slowdown that continues, often the result of a change to the system Each of these characteristic changes in performance indicate a different set of problems.
13.6 More Factors That Affect Performance
The following sections discuss some aspects of the application that may not immediately strike you as part of the performance of the application. But they do affect the users perception of the
application performance, and so are relevant.
13.6.1 User Interface Usability
The applications user interface has a significant effect on the users perception of performance. The time required to navigate through the user interface to execute some functionality is seen by the user
as part of the applications response time. If window and menu navigation is difficult, performance is seen to be bad and actually, it is bad.
The user interface should support the natural flow of the users activity; otherwise, you are forcing the user to perform less efficiently. Improving only the navigability of the user interface, even with
no other changes to the application, improves the perceived performance of an application.
13.6.2 Training
Training users to use the application is also a performance issue. Without proper training, users may not use the application efficiently, and will then compare the application unfavorably with another
application they are comfortable with. Since they are comparing similar functionality, the user immediately focuses on the differences. The main difference, of course, is the perceived
performance.
The user never thinks he is untrained. He simply feels that executing some function in your application takes forever, as he stumbles through menu options trying to find what he wants, fills in
forms incorrectly, etc. The result is a perception of bad performance.
Note that making help desks available is an essential part of the training program. Training is seldom so thorough that all parts of the application are covered in enough detail, and it is also
common for people to forget some of their training. A help desk keeps the users from getting lost and giving up on the most efficient route to solve their tasks.
13.6.3 Server Downtime
If people cant start a piece of software, they can get frustrated, but they dont normally view this as bad performance. Most people would instead get annoyed at the quality of the software. But when
servers are not running, this can be perceived differently. Sometimes a server that isnt running is perceived as bad-quality software, but sometimes it is seen as poor performance. If the server stops
responding in the middle of processing, this is invariably seen as slow performance. Consider your own response to a stalled download from an HTTP server.
- 302 - Avoiding server downtime is a robustness issue as well as a performance issue. Servers should be
designed to avoid unnecessary downtime and minimize necessary downtime. One issue when running servers is altering their configuration and patching them. If you need to stop a server from
running while you make changes, this affects its perceived performance. You must signal it to stop accepting requests and either wait for current requests to terminate or forcibly terminate all
requests; either way, this causes interruptions in service to the clients.
[15] [15]
Load-balancing products often provide features that allow server maintenance with minimum downtime.
It is possible to design servers that can be reconfigured and patched with no downtime. Designing for reconfiguration on the fly is easier. In this case, you typically have a configuration file. One
common solution is for the server to periodically test the timestamp of the configuration file and reread it if the timestamp changes. This solution also provides good security as presumably, the
configuration file can be changed only by authorized persons. Another solution is for the server to recognize and accept a particular signal as a sign to reset its configuration. In most servers using
this solution, the signal is an operating-system signal that is trapped. However, Java does not support operating-system signal handling , so if you steer down this path, you need either to install
operating-system handlers yourself using the Java native interface or use another communication mechanism, such as sockets. If you do use sockets, you need to consider security aspects; you dont
want unauthorized persons triggering a server reconfiguration.
Patching a running server is more complex. You need to provide some level of indirection on how the request-processing classes and all the classes they depend on are loaded. The most basic
solution is to use the configuration file to list names of all classes. Then the server must be built using
Class.forName
to access and create any classes and instances. This way, providing a new version requires only changing the class names in the configuration in an atomic way to avoid
corruption.
A more sophisticated solution is to use different
ClassLoader
s. Note that any particular class in Java is identified by its package and class name, and by its
ClassLoader
. It is possible to have classes with the same package and class names loaded multiple times in the same VM whether the
implementation is the same or different for those classes using multiple
ClassLoader
instances. This is easiest in Java 1.2, where there is a proliferation of
ClassLoader
s. A useful classloader for this type of runtime patching is the
URLClassLoader
:
This method gets a new implementation of a RequestProcessor every time.
public RequestProcessor getNewRequestProcessor {
URL[] urls = {new URL...}; Class c = RequestServerMain.class;
ClassLoader cl = c.getClassLoader ; URLClassLoader xtra_cl = new URLClassLoaderurls , cl;
c = xtra_cl.loadClassRequestProcessor; RequestProcessor proc = RequestProcessor c.newInstance ;
return proc; }
public void processRequestRequest aRequest, RequestProcessor proc {
Signal to get a new implementation of a request processor by passing a null value in the proc variable
if proc == null proc = getNewRequestProcessor ;
proc.processRequestaRequest; ...
- 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
