18.5 Case Study: The Pet Store

Sun created a J2EE tutorial application called the Pet Store.^[1] In the Pet Store, there was no attempt to focus on performance. In a marketing coup in early 2001, Microsoft took the badly performing basic Pet Store application and reimplemented and optimized it in .NET, using the results to "show" that .NET was over 20 times faster than J2EE. (The .NET optimizations appear mostly to have been SQL optimizations together with moving much of the application server logic to database-stored procedures.) A few weeks later, Oracle took the original Pet Store code, keeping it in J2EE, and optimized the application.^[2] The resulting optimized J2EE application performed over 20 times faster than the .NET implementation.

^[1] See http://java.sun.com/blueprints/code/index.html#java_pet_store_demo.

^[2] Oracle's Pet Store benchmark report is available at http://otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf. You may also want to check out the discussion of the Oracle improvements in the Server Side (http://www.theserverside.com/home/thread.jsp?thread_id=12753).

Here's how Oracle optimized the application:

Optimized lazy loading of data

The original Pet Store didn't try to optimize data handling. All information that might be needed is automatically loaded on the client. This is unrealistic in real-world applications that should minimize data transfers. Oracle changed the application to load only needed information. (Lazy loading is discussed in Chapter 4, Chapter 8, and Chapter 12.)

SQL query optimization

The Pet Store made no attempt to optimize the SQL queries. This lack of optimization is appropriate for a tutorial, where the most simple SQL is easier to understand. Oracle converted some SQL to more optimal statements. (Chapter 16 discusses SQL optimization.)

No unnecessary updates

Oracle changed the EJBs so they use isModified( ) to avoid unnecessary database updates. It is always good practice to avoid doing what doesn't need to be done. (This is a good example of using a dirty flag, discussed earlier in Section 18.1.7.)

Reduced contention to improve scalability

Some methods opened multiple database connections. These methods were rewritten to use only one connection at a time, reducing contention and increasing scalability. (SQL optimization is discussed in Chapter 16, and contention costs in Chapter 15.)

Limited number of items retrieved by queries

The Pet Store application default settings produced too much unnecessary data. Oracle used the Page-by-Page Iterator pattern with limited page size to improve performance and scalability.

Session data stored in session, not context

Session data was moved from the ServletContext to the HttpSession, and the JSP was modified to use the session rather than the context. Without this change, multiuser access to the Pet Store application was very limited, as all catalog access to the DB was forced through a single connection. (This topic is discussed briefly in Section 17.4.)

Connections shortened

Connection code was rewritten to keep the DB connections very short, as is optimal with connection pooling. (SQL optimization is discussed in Chapter 16, and transaction optimization in Section 18.1.7.)

String handling optimized

String-handling code was rewritten to use StringBuffer instead of String, removing unnecessary concatenations. (Chapter 5 discusses string optimizations.)

The combined effect of these optimizations from Oracle produced a greater than 400-fold improvement in performance.