Download (direct link):
Item 38: Design Strategies for Eliminating Network Bottleneck Pitfalls
In a distributed world where, as Sun Microsystems says, "the network is the computer," the network is also where a lot of performance bottlenecks can be found. If your software communicates over the network, your design must be flexible enough to tune your performance so that waiting for network traffic does not become the weakest link in your system. Whether you are programming with Sockets, Remote Method Invocation (RMI), CORBA, Enterprise JavaBeans, or using SOAP messaging for Web services using JAXM or JAX-RPC, it is important that you concentrate on your design so that
336 Item 38
network latency is not a factor. At the same time, you want to design your system with a flexible architecture.
Although some Java programmers experience problems when designing parallel processing algorithms in network computing, most of the pitfalls we've experienced relate to call granularity in remote messages or method calls. That is, the more messages and calls sent over a network, the more network traffic may impact the performance of your application. In network programming, many developers design their systems where clients send multiple small messages over the network, giving the client more details in the specifics of the transaction but increasing the amount of network connections in an application session. Most of the time, systems that are designed without performance in mind fall into this "granular messaging" trap. In this pitfall, we provide a scenario where we discuss design patterns and strategies for general network programming, and we discuss examples for systems developed with Enterprise JavaBeans.
To demonstrate these challenges, let's look at a scenario for a network application for an automobile service center. An enterprise application for this auto shop supports troubleshooting for its vehicle service. When customers arrive at the auto shop, they tell the employees their customer number and the make and model of their automobile, and they describe their problem. This online application allows the employees and mechanics to look up information about their automobile, find troubleshooting solutions, and provide real-time assistance in fixing the problem. The use cases for the auto shop workflow are shown in Figure 38.1. As you can see from the figure, the auto shop employee enters the car trouble information (probably with the customer's information), gets the owner information from the database, gets the vehicle history from the database, gets possible solutions to the problem, and finally, gets part numbers related to those solutions that are provided.
Looking past the use case and into how data is stored, we see that the application needs to talk to four databases: the owner database with information about the owner's automobile and his or her service history, the "car trouble" database with common problems and solutions, the automobile database about makes and models of cars, and the parts database that keeps part numbers for different makes and models of cars.
General Design Considerations
Before we even look at the pitfalls that occur in each API, the following should be made abundantly clear: Although there are four databases full of information, it would be a bad decision to design your client in such a way as to query the databases directly, as shown in Figure 38.2. Such a design would put too much implementation detail in the client, and a very possible bottleneck will be in the management of the JDBC connections, as well as the amount of network calls happening. In Figure 38.2, for each network transaction, there is significant overhead in the establishment and setup of each connection, leading to performance problems. In addition, such a solution is an example of a very brittle software architecture: If the internal structure of one of these databases changes, or if two databases are combined, a client application designed as shown in Figure 38.2 will have to be rewritten. This causes a software maintenance nightmare.
Design Strategies for Eliminating Network Bottleneck Pitfalls 337
Enter Car Owner Information
Get Part #s for Possible Solutions Figure 38.1 Use cases of auto shop scenario.
Figure 38.2 Bad client design: calling databases directly.
338 Item 38
Figure 38.3 shows an approach that abstracts the implementation details about the four databases from the clients. Instead of the client communicating directly with the four databases, the client communicates with four Java objects. This is good because implementation-specific details in each database are abstracted from the client. The abstraction objects hide these details from the client, but the workflow logic still exists in the client. Added to that is that there is still a potential performance bottleneck: The solution still requires many network calls from the client. For example, if there were eight possible solutions to a car trouble problem, the solution in Figure 38.3 would require 11 network connections (one connection each to the owner, automobile, and car trouble abstractions, and eight connections asking for parts for possible solutions). If this system were live, the performance of this would be unacceptable.