J2EE Performance

8/4/2019 J2EE Performance

1/79

J2EE Application Performance Design Considerations

Design Guidelines and PracticesDesign Guidelines and Practices

For J2EE Application PerformanceFor J2EE Application Performance

Prepared By: Akshay Hattangady

Reviewed By: Sudhakar Takke

Date: 11th August 2005

Document Version No: 1.0

Rev. # Author RevisionDate

RevisionDescription

1.0 Akshay Hattangady

18th April2005

Initial version

1.1 Akshay Hattangady

11th Aug2005

Modified after adding Sudhakarsfindings.

Patni Internal Page 1 of 79


2/79


Contents1 Overview ............................................................................................................................. ........4

2 Defining Performance ..................................................................................................................4

3 Design Patterns for Optimizing the Performance of J2EE Applications .................. ..... ..... ..... .....6

3.1 Fast Lane Reader ................................................................................................................ ..63.2 Page-by-Page Iterator.......................................................................................................... .7

3.3 Value Object/Data Transfer Object.......................................................................................8

3.4 Service Locator/EJB Home Factory.....................................................................................9

3.5 Session Facade....................................................................................................................10

3.6 Service Activator/Message Facade.....................................................................................11

3.7 Value Object Assembler/Value Object Factory..................................................................12

3.8 Value List Handler..............................................................................................................13

4 Anti-patterns that affect performance .........................................................................................15

4.1 Transparent Facade.............................................................................................................15

4.2 Message Driven Beans: Overloading Destinations.............................................................164.3 Excessive Layering.............................................................................................................16

4.4 Leak Collection...................................................................................................................174.5 Overstuffed Session............................................................................................................17

4.6 Everything is an EJB (Golden Hammer Anti-pattern)........................................................18

5 Design guidelines for JSPs ........................................................................................ ..... ..... .....19

5.1 STRUTS-EL.......................................................................................................................19

5.2 Tag Libraries......................................................................................................... .............19

5.3 Caching...............................................................................................................................19

5.4 Scoped Variables.............................................................................................................. ..20

5.5 Server Configuration and directives....................................................................................21

6 Design guidelines for Servlets ..................................................................................... ..... ..... ....23

6.1 Caching...............................................................................................................................23

6.2 General...............................................................................................................................23

7 Design guidelines for EJBs ...................................................................................................... ..24

7.1 To ejB or not to ejB? ..................................................................................................... .....24

7.2 Local and Remote EJBs......................................................................................................24

7.3 Transactions ........................................................................................................................24

7.4 CMP or BMP? ....................................................................................................................257.5 Tuning session bean instance size.......................................................................................25

8 Design guidelines for JDBC .......................................................................................................27

8.1 Datasources and Connections.............................................................................................27

8.2 Statement........................................................................................................................... .27

8.3 Resultset........................................................................................................................... ..28

8.4 Transactions........................................................................................................................29

8.5 Database Optimization........................................................................................................30

8.6 DAO.............................................................................................................................. .....31

9 XML ....................................................................................................................................... ..32

9.1 Validation...........................................................................................................................32

9.2 Canonicalization................................................................................................................ .32

9.3 Consider Element and Attribute Name Lengths .................................................................33

9.4 SAX and DOM ...................................................................................................................33

9.5 Partial Parsing with SAX ......................................................................................... ..... .....33

10 J2EE Object Caching Frameworks ......................................................................................... .34

10.1 Object Caching ............................................................................................................ .....34



3/79


10.2 Benefits of Caching .................................................................................................. ..... ..34

10.3 Liabilities of Caching ....................................................................................... ..... ..... ..... .35

10.4 Cache Rules! .................................................................................................................. ...35

10.5 Caching Frameworks........................................................................................................36

10.6 Case Study: Caching in a Web Portal Application............................................................3610.7 References for Object-Caching Frameworks....................................................................40

11 Java best practices for performance ........................................................................ ..... ..... ..... .4111.1 Memory Management.......................................................................................................41

11.2 Logging.................................................................................................................... ........41

11.2.1 Log4J .......................................................................................................................41

11.3 Collections........................................................................................................................43

11.4 Data types, objects, classes and methods..................................................................44

11.5 Loops ........................................................................................................................ ..47

11.6 Exceptions ..................................................................................................................47

11.7 General ............................................................................................................ ...........47

....................................................................................................................................................48

12 Project Execution Tips .......................................................................................................... ...49

13 Load Testing Tools ..................................................................................................... ..... ..... ...50

13.1 OpenSTA........................................................................................................................5013.1.1 The Commander Interface ................................................................................. ..... ...50

13.1.2 HTTP/S scripts..........................................................................................................51

13.1.2.1 Planning Your Scripts ........................................................................ ..... ..... ..... .52

13.1.3 Test Development Process ........................................................................................ .5213.1.4 Running Tests ......................................................................................................... ...52

13.1.5 Monitoring a Test-run ................................................................................................52

13.2 JMeter...............................................................................................................................53

13.3 JUnitPerf ...........................................................................................................................54

14 Profiling Tools ................................................................................................................... ..... .56

14.1 WSAD Profiler........................................................................................................... ......56

14.1.1 Installation .............................................................................................................. ...56

14.1.2 Process of Profiling an Application...........................................................................5814.2 Borland Optimizeit...........................................................................................................60

14.2.1 Integrating Optimizeit with WSAD 5.0 ............................................................. ..... .61

14.2.1.1 Configuring WebSphere with Optimizeit ................................................. ..... .....61

14.2.1.2 Starting WebSphere with Optimizeit..................................................................62

14.2.1.3 Attaching from Optimizeit ................................................................ ..... ..... ..... ..62

15 Alternatives .......................................................................................................................... ....64

15.1 Get better Hardware........................................................................................................64

15.2 OS/Platform Tuning ........................................................................................................64

15.3 JVM ................................................................................................................................64

16 Summary ..................................................................................................................................6616.1 The story so far ....................................................................................................... ....66

16.2 The J2EE Performance Tuning trade-off ................................................. ..... ..... ..... ....6617 Resources ............................................................................................................................... ..68

18 Appendixes ............................................................................................................................69

Appendix A: Methods GET and POST in HTML forms - what's the difference? ....................... 69

Appendix B: Client side vs. Server side scripting and validations .................................... ..... ..... .71

Appendix C: GoF Design Patterns that are related to Performance .............................................74

(a) Abstract Factory Design Pattern.........................................................................................74

(b): Factory Method Pattern.....................................................................................................75

(c) Flyweight ...........................................................................................................................76



4/79


(d) Prototype ............................................................................................................................77

(e) Singleton ............................................................................................................................78

1 Overview

The performance aspects of a system are often left to the end of the project.Developers just don't have time to consider response times when speed ofdelivery and functionality are the pressing goals. Performance bottlenecksmust be systematically identified and solved, which is no light task. Unless youconsider and factor performance into your user interfaces, designs, anddevelopment processes up front (including testing early and often), you'll likelyhit problems sooner or later.

The key to good performance is to understand your performance goals up front.Understand the number of concurrent users, target response times, usagepatterns, and data growth. Know how your application is going to be used:

which parts of the system are session-based and which are non-session orbatch-based. That way you can structure your architecture to meet your needs.The later in the development life cycle you address them, the more expensivethey become to fix. There are several best practices and patterns that haveevolved for J2EE application design that focus on performance. This documentcontains guidelines, hints and patterns that can be followed while designingJ2EE applications.

2 Defining Performance

Performance is more than just executing the maximum number of operations inthe shortest amount of time. We must have a thorough understanding of justwhat performance means to develop higher performance software. There arefive aspects of software performance to consider when embarking on a highperformance application lifecycle management process for Java:

Computational performance

RAM footprint

Startup time

Scalability

Perceived performance

Computational performanceComputational performance, as described by the classic volumes onprogramming written by Donald Knuth, focuses on algorithmic analysis (i.e.order(n), order(n2), etc.). In other words, performing an operation in the leastamount of time.

RAM footprint



5/79


6/79


3 Design Patterns for Optimizing the Performance of J2EEApplications

While designing applications keep the basics in mind:

1. Encapsulate what varies.2. Program to interfaces, not implementations. That way, if you want to

swap a class for a better and faster algorithm, you can do it withoutaffecting any other part of your application.

3. Favor composition over inheritance. A messy inheritance structurecauses maintenance problems and makes objects heavier to create.

4. The Open-Closed Principle: Classes should be open for extension andclosed for modification.

5. The Dependency-Inversion Principle: Depend on abstractions and not onconcrete implementations.

Design patterns are tried and tested solutions to common problems that havebeen implemented by developers throughout the world. Multi-tiered J2EEapplications consist of components communicating across tiers toaccess/change data. This often leads to remote calls between applicationclients/JSPs/servlets and EJBs or between EJBs. Such remote calls are costlyand affect the performance of the application as a whole. An increase in thenumber of such remote calls increases network traffic too. Moreover, for allthe advantages that EJBs offer, they come with a small price.

The following three design patterns suggest good solutions to minimize some ofthe performance costs in typical J2EE applications.

3.1 Fast Lane Reader

Problem Domain:Most Web applications need to display a list of data objects to the user. Fore.g. - A financial service organization that offers its service over the Web willhave to display its catalog of services to the customer who is visiting its Website. To display the catalog of services, typical designs might have an EJB thatrepresents the whole catalog. There might be a CatalogEJB that implements allrequired business logic related to the catalog, such as adding a new service,removing an existing service or giving a list of service, details to the requesting

component. This implementation method, while providing transactional accessfor the required list of objects, comes with the price of the overheads andremote calls associated with the use of the EJB. Given that the list of servicesis not going to change every second, the chances of the customer seeing staledata are low.



7/79


Pattern:Using the Data Access Object pattern, all database calls are encapsulated bythe DAO. In Fast Lane Reader, the action class (if you are using STRUTS)through the business delegate class directly calls the DAO methods. Bybypassing the EJB the overheads associated with remote calls, transaction

management, we can give a faster response to the customer. To avoidduplication of code, the business methods of the EJB themselves will also callthe DAO, but read-only calls for large data lists can bypass EJBs.

3.2 Page-by-Page Iterator.

Problem Domain:Now that we have seen an efficient way to access read-only data (that does notchange rapidly), how much of such data should we read? To put it in a moregeneral way, when we have to access a large remote list of objects, do we

transfer the entire list or only part of it? The answer to this question will havea tremendous performance effect on the application because transfer of largelists means extra load on the network. Moreover, if EJBs were used to readsuch large lists, the performance cost is even more because of the costsintroduced by the additional services provided by the EJB model.

Pattern:In finding a common and efficient solution, we should note that the user mightnot be interested in looking at the entire list. The transfer of large lists meansmore time, resulting in bad user experience. Moreover, the requesting clientmay have a small amount of memory or a small display; hence, such a client

may not be able to handle such large lists. Taking these into account, thesuggested pattern would be the Page-by-Page Iterator pattern. The use of thispattern will enable the client to request the list and also specify its size. Inresponse, the server will return a list of the requested size only.

The Data Access Object will have to be modified a little to make use of thePage-by-Page Iterator pattern while returning the list of services. Listing 1shows a sample class used for paginating large lists. This pattern can be used inconjunction with a custom Pagination tag library to simplify development.

The flipside of this pattern is that the number of server and database hits to

fetch the data will be more, but list pages generally also have a search/filtermechanism to get to the required data faster so this is not generally a problem.

PaginationVO.jav

Listing 1 Sample of class showing this pattern used in Market Metrics.



8/79


Attached is a document submitted to COR on a pagination tag library that canbe used with the page-by-page Iterator pattern.

PaginationTag.zip

Listing 2 Document on a custom pagination tag library submitted to COR.

3.3 Value Object/Data Transfer Object.

Problem Domain:More often than not, the data being transferred is collections of objects thathave their own identity. In the financial services sample application that wehave been discussing, the lists of services being returned from the server are

actually collections of objects. Each of these services will have its ownattributes, such as Service Name, Service Cost, Service Description, and Termsand Conditions. And, more often than not, a client requesting the list ofservices will also want to know about all the above-mentioned information thatbelongs to a service. Given these circumstances, when do we transfer thesefiner details? It is definitely not efficient for the client to get a list of servicenames and then contact the server to get the finer details of each servicename received. That would entail lots of remote calls and additional stress onthe network.

Pattern:While coming up with a common solution to this scenario, we have to keep inmind that:

The probability of the client asking for the finer details of a service is muchmore than the client asking for the complete list of services.

All the attributes associated with the requested object will most probably be inthe same database table and hence can be obtained in the same SQL call thatgets the list of service names. The suggested solution would be that wetransfer coarse-grained data (in this example, the list of service names alongwith all its attributes) rather than transferring fine-grained data (e.g.,requiring the client to make separate remote calls for each of the attributes,such as service name, cost, and terms). We can do this by using the ValueObject pattern. A value object is a lightweight, serializable (i.e. implementsjava.io.Serializable) object that structures group of data items into a singlelogical construct. See Listing 2.



9/79


ServiceInformatioava

Listing 3 Sample value object

3.4 Service Locator/EJB Home Factory.

Problem Domain:J2EE specification mandates the usage of JNDI (Java Naming and DirectoryInterface) to access different resources/services. J2EE compatible server bindsthese resources/services to the JNDI server so that the clients can lookup thoseresources/services through JNDI lookup process from anywhere in the network.The resources/services can be

1. EJBHome objects2. DataSource objects

3. JMS ConnectionFactory4. JMS Topic/Queue etc.

All these services need to bind to the JNDI services and the clients need tolookup JNDI to get those services. Clients have to go through JNDI lookupprocess every time to work with these services. JNDI lookup process isexpensive because clients need to get network connection to the JNDI server ifthe JNDI server is located on a different machine and need to go throughlookup process every time, this is redundant and expensive.

Pattern:The solutions for the redundant and expensive JNDI lookup process problem is

to cache those service objects when the client performs JNDI lookup first timeand reuse that service object from the cache second time onwards for otherclients. This technique maintains a cache of service objects and looks up theJNDI only first time for a service object. This technique reduces redundant andexpensive JNDI lookup process thus increasing performance significantly.Service Locator Pattern implements this technique by having a class to cacheservice objects, methods for JNDI lookup and methods for getting serviceobjects from the cache.

The Figure 1 below shows the ServiceLocator class intercepting the clientrequest and accessing JNDI once and only once for a service object.



10/79


Figure 1 Service Locator

Listing 3 shows the service locator used in Market Metrics.

ServiceLocator.jav

Listing 4 Service Locator used in Market Metrics

Listing 4 is a generic Service locator that stores references to other resourcesalso.

ServiceLocator.jav

Listing 5 Service Locator from J2EE blueprints for all types of resources.

@see:http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html

3.5 Session Facade.

Problem Domain:EJB clients like servlets, jsps, and action classes can access entity beansdirectly. To execute the business logic of a typical use-case, several methodsand server side objects (mostly session of entity beans) need to be accessed. Ifthe EJBs are remotely located, multiple fine-grained invocations add the

http://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ServiceLocator.html


11/79


overhead of network call in addition to making the code less maintainable andtightly coupling the web and ejb tiers.

Pattern:The solution for avoiding number of network calls due to directly accessing

multiple entity beans is to wrap entity beans with session bean (Facade). TheEJB client accesses session bean (Facade) instead of entity beans throughcoarse grained method call to accomplish a business process.The following figure illustrates how the session facade (session bean) acts as aninterceptor between client and entity beans:

Figure 2 Session Facade

@see:http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html

3.6 Service Activator/Message Facade.

Problem Domain:Session bean and entity bean methods execute synchronously that means themethod caller has to wait till a value is returned. In some situations likesending hundred's of mails or firing a batch process or updating processes, theclient does not have to bother about return value. If you use synchronoussession and entity beans in such situations, they take a long time to processmethods and clients have to wait till the method returns a value.

Pattern:To avoid blocking of a client, use asynchronous message driven beans, so thatclient does not have to wait for a return value. If the client request involves



12/79


processing several methods on entity beans, session beans, abstract thesemultiple operation by providing a single faade. Use cases can thus beexecuted in once call and transaction. See Figure 3.

Figure 3 Message Facade

@see:http://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.html

3.7 Value Object Assembler/Value Object Factory.

Problem Domain:Data transfer objects or value objects have a tendency to change often.Domain VOs change whenever the domain objects change; e.g. adding a newattribute, etc. Custom VOs are just use-case specific data holders fortransporting data across a network; they change as often as your applicationspresentation view. There may be several VOs in your application, eachrequiring custom logic to create it. For a single request, a client might need toaccess multiple server side components such as different session beans andentity beans. In such situations, the client accesses multiple components overthe network; this increases the network traffic and has an impact on theperformance.

Pattern:We place the logic for creating and consuming value transfer objects in a valueobject factory. A value object factory separates the logic related to datatransfer objects (part of the application domain) from the other componentssuch as entity beans/data access objects (part of the business domain). TheValue object factory can also be fronted by a session faade that handles thebusiness logic (invoking different methods in different beans/DAOs) while the

http://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ServiceActivator.html


13/79


factory itself manages the construction of the composite value object. Thefollowing figure illustrates how ValueObjectFactory intercepts client requestand delegates to different components to respond to a client request:

Figure 4 Value Object Factory

@see: http://java.sun.com/j2ee/patterns/ValueObjectAssembler.html

3.8 Value List Handler.

Problem Domain:The problem statement here is similar to the one for the page-by-page Iteratorpattern.

Pattern:Use a Value List Handler to control the search, cache the results, and providethe results to the client in a result set whose size and traversal meets theclient's requirements. The ValueListHandler executes the required query whenrequested by the client through the DAO. The ValueListHandler obtains thequery results, which it manages in a privately held collection represented bythe ValueList object. The ValueListHandler creates and manipulates the

ValueList collection. When the client requests the results, the ValueListHandlerobtains the Transfer Objects from the cached ValueList, creates a newcollection of Transfer Objects, serializes the collection, and sends it back tothe client. The ValueListHandler also tracks the current index and size of thelist. Caching can be done using a stateful session bean for the list handler orhttp-based caching (session scope) depending on whether the ValueListHandleris fronted by a Session bean or a used in a non-EJB application.

http://java.sun.com/j2ee/patterns/ValueObjectAssembler.htmlhttp://java.sun.com/j2ee/patterns/ValueObjectAssembler.html


14/79


Listing 6 shows code samples of this pattern. Figure 5 shows the class diagram.

ProjectDAO.java ProjectListHandler.va

ValueListHandler.ja

ValueListIterator.jaa

Listing 6 Value list handler pattern code samples.

Figure 5 Value List Handler

@see:http://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.html

http://valuelist.sourceforge.net/(Free) Implementation of the Core J2EE Patterns - Value List Handler

http://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.htmlhttp://valuelist.sourceforge.net/http://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.htmlhttp://developer.java.sun.com/developer/restricted/patterns/ValueListHandler.htmlhttp://valuelist.sourceforge.net/


15/79


4 Anti-patterns that affect performance

Anti-patterns are a natural extension to design patterns. Anti-patterns arenegative solutions that present more problems than they address. Anti-patternsbridge the gap between architectural concepts and real-world

implementations. Major causes of anti-patterns: Inexperience

Unreadable code

Cut-and-paste development

4.1 Transparent Facade.

General Form:In this anti-pattern, the session faade directly delegates to the underlyingentity. It doesnt provide the right level of coarse-grained calls to the entity

bean/DAO/business object. Clients still make fine-grained calls to fetch data.Return data is not effective encapsulated in a data transfer object.

Symptoms and Consequences:Increased maintenance, poor performance and increased coupling betweensession and entity.

Refactoring:Right size session faade.


Client

Facade

getA()

getB()

getC()

Entity

getA()

getB()

getC()

Client

Facade

getVO()

Entity

getA()getB()

getC()


16/79


4.2 Message Driven Beans: Overloading Destinations.

General Form:Message driven bean that processes more than one type of message in itsonMessage method.

Symptoms and Consequences:

Increased maintenance, poor performance and code bloat over time.

Refactoring:Introduce a new bean for each message type. Refactor clients to use the newbeans. Also change the topic/queues posted to.

4.3 Excessive Layering.

General Form:Design patterns add layers to a J2EE application. Adding excessive layers where

they are not needed proves to be expensive.

Symptoms and Consequences:Increased maintenance, poor performance and code bloat over time.

Refactoring:A general problem with highly modular and dynamic software architectures isthat excessive layering often leads to inefficient implementations. Runtime


M1

M2

M3

Topic/Queue

Message

Driven Bean

M1

M2

M3

Topic2/Queue2Message

Driven Bean 2

Topic1/Queue1

Topic3/Queue3

Message

Driven Bean 1

Message Driven

Bean 3


17/79


costs are paid each time a programs control flow crosses an abstractionboundary, which has been enforced for the sake of information hiding and ahigh degree of modularity.

For small applications where the entire model, view, and controller always live

on the same server (like a single-function intranet application), reduce layersas much as possible. Generally, this will mean condensing the business tier,often using DAO and business delegate objects that interact directly with anunderlying database through JDBC. In the presentation tier, you should stick toa simple servlet/JSP model.

4.4 Leak Collection.

General Form:Whenever we have a collection with a long life cycle that has the potential to

contain objects that arent removed, we have the possibility of a memory leak.For e.g. a singleton hash table serving as a cache, session state, ejb container.

Symptoms and Consequences:The program grows indefinitely, slows as free memory runs out.

Refactoring:

Examine objects with long life cycles. Try to make sure references totransient objects are removed.

Make sure and add into a collection has a corresponding delete or weakreferences that allows garbage collection. Refer Resources section for

information on Weak References. Examine static objects and collections to make sure that references to

transient objects are removed and commented.

Use soft references for caches.

Use a finally block for cleanup code.

4.5 Overstuffed Session.

General Form:Putting too much data or the wrong kind of data into the session leads to theOverstuffed Session antipattern.

Symptoms and Consequences:The program slows as free memory runs out. Consider this code in an actionclass:

//get user profile from LDAP by firing a search query.userProfile = LDAPSearchHelper.queryLDAP(ssoID);



18/79


//setting the UserInfo object in the sessionsetSessionObject(aRequest, GLOBAL_USERINFO_KEY,userInfo);

If the UserInfo object contains unwanted information like addresses,

telephone, fax number that are never used and if multiple users are connectedtogether, there will be a memory leak.

Refactoring:

If you use Struts or a similar web application framework, pay particularattention to this issue. The default Form Bean scoping in Struts is to thesession, rather than to the request, so its easy to end up with a largenumber of extra objects in memory for each active user. In the struts-config.xml file, the scope of the bean has to be explicitly set to request.In spite of doing this it has been observed that the forms are still insession scope sometimes. This can be avoided by putting

scope=request in the tag in the jsp. Long-lived data can be migrated to the business tier.

4.6 Everything is an EJB (Golden Hammer Anti-pattern).

General Form:Developersespecially developers with a history of database developmenttend to see entity EJBs as the solution to every problem.

Symptoms and Consequences:

Large number of entity and session beans proliferating throughout theapplication. Performance overheads of EJB container added to tasks that dontneed transaction management, security, and persistence.

Refactoring:For small applications, Plain Old Java Objects (POJOs) can be as a replacementby implementing design patterns like Command, Business Delegate and DAO.For more complex applications persistence frameworks like JDO, I-Batis orHibernate may be used. Session beans/JDO/I-BATIS can also be combined withstateless session beans (faade) to get the best of both worlds.



19/79


5 Design guidelines for JSPs

Since JSPs are compiled into servlets, most of the points for JSP andServlet tuning apply to the other also.

5.1 STRUTS-EL.One of the most significant advancements for JSP developers has been theintroduction and adoption of JSTL or the JSP Standard Tag Library. JSTLprovides custom tags for basic functionality, such as managing scoped variablesand interacting with URLs, as well as for fundamental operations like iterationand conditional logic.

The Struts-EL tag library is a contributed library in the Struts distribution. Itrepresents an integration of the Struts tag library with the Java Server PagesStandard Tag Library, or at least the "expression evaluation" engine that is usedby the JSTL. Refer http://struts.apache.org/faqs/struts-el.html. While

developing JSP pages, use JSTL tags instead of the equivalent struts tags. JSTLtags might offer better performance when compared with their correspondingSTRUTS tags. For e.g.:

Use c:if, c:when with EL, instead of logic:equals

Use c:for instead of logic:iterate, and so on.STRUTS specific tags, like have no equivalent in JSTL so they have to beused as is.

5.2 Tag Libraries.

JSP Engine has to look at descriptor file to figure out tag handler classand execute that handler. All these operations do not come for free. Itreduces performance and it is proportional to the number of taghandlers you use in JSP. So don't use custom tags unless you are sure ofits reusability.

The display tag library (http://displaytag.sourceforge.net/) is an opensource suite of custom tags that provide high-level web presentationpatterns used for displaying tables in web pages, which will work in anMVC model. The library provides a significant amount of functionalitywhile still being easy to use. If the web page shows a lot of data intabular form, use STRUTS/JSTL tags to iterate over a collection ofobjects and create the table instead of using the display tag for betterperformance.

5.3 Caching.

It is well known that HTTPSession and application scope should bejudiciously used. Store read-only data that is rarely updated. For e.g.dropdowns that occur in several pages, commonly used information like

http://struts.apache.org/faqs/struts-el.htmlhttp://displaytag.sourceforge.net/http://struts.apache.org/faqs/struts-el.htmlhttp://displaytag.sourceforge.net/


20/79


maximum records displayable per page, access-control or securityinformation.

If the volume of data is a lot, consider creating a pseudo-session wherethe data is actually stored in a temporary database table, but accessorsto this data are built into your application framework in such a way that

there is no difference in accessing this data and the actual HTTPSessiondata (maybe with overloaded method(s) in a base action class). With thisapproach, you will have to have an additional mechanism for cleaningthe table at regular intervals (maybe a nightly job or by usingHTTPSessionBindingListener to delete data just before httpsession isdestroyed), but the advantage of this approach in certain cases justifiesthis extra work. This approach scales particularly well.

The cost of storing data in an HTTP session object is basically the sameas using a stateful session bean, assuming the bean is removed in aproper way at the time the session terminates. Not doing so will have anegative impact on the performance of the application.

Do not store large object graphs in javax.servlet.http.HttpSession.Servlets may need to serialize and deserialize HttpSession objects forpersistent sessions, and making them large produces a large serializationoverhead.

Use the tag "" to avoid creating HttpSessionsin JSPs. Use this only if you dont want to use sessions at all.

Remove HttpSession objects explicitly in your program whenever youfinish the session.

Web server caching can help your Web site load faster, and save load onyour server and Internet link. This is a specialized technique. Referhttp://www.mnot.net/cache_docs/ for details.

By default the size of out (implicit object of JSPWriter) object is 8kb.You can increase the size if you are sending a large amount of data.

so set There are some third party open-source caching solutions available like

OSCache, JCS that can provide fast in-memory caching within yourexisting JSPs. Refer http://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache_p.html for an example.

@see http://www.opensymphony.com/oscache/

5.4 Scoped Variables.

When you want to create a bean using useBean action tag you can setscope for that bean default value is 'page' for any bean if you don't specify the scopeexplicitly. By defining scope attribute, you are defining the life timeof that object, when it has to be created and when its life time ends.To be precise, you are defining the availability of that object to a

http://www.mnot.net/cache_docs/http://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache_p.htmlhttp://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache_p.htmlhttp://www.opensymphony.com/oscache/http://www.mnot.net/cache_docs/http://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache_p.htmlhttp://www.javaworld.com/javaworld/jw-05-2001/jw-0504-cache_p.htmlhttp://www.opensymphony.com/oscache/


21/79


page, request, session (that is across multiple requests to a user) orapplication (across multiple users ). Here the scope effects theperformance if you don't specify exact scope as per yourrequirement. What will happen if you set a session scope for anobject, which is, needed only a request? The object will unnecessary

reside in the memory even after your work is done. When using thesession or application scope object you have to explicitly remove itafter you are done. Otherwise the session object will be there in thememory till you explicitly remove the object or your server removesit after a configured time limit ( typically it is 30 minutes). It reducesthe performance by imposing overhead on memory and garbagecollector. The same is the problem with the application scopeobjects. So set exact scope for an object and also remove thosescope objects immediately whenever you are done with them.

When using JSTL, in the Expression Language, identifiers not

associated with implicit objects are assumed to name objects storedin the four JSP scopes. Any such identifier is first checked againstpage scope, then request scope, then session scope, and finallyapplication scope, successively testing whether the name of theidentifier matches the name of an object stored in that scope. Thefirst such match is returned as the value of the EL identifier. Soalways give the proper scope of the object in order to help theengine locate it quickly.

5.5 Server Configuration and directives.

Most of the application servers/JSP engines have the capability ofloading JSP's servlets dynamically that means you need not restartyour server whenever you change the JSP content. Applicationserver/JSP engine loads the JSP's servlet every time when youconfigure that JSP's servlet. For example, if you configure autoreload time as 1 second, then JSP engine loads that JSP's servletafter every 1 second. This feature is good at development timebecause it reduces the development time by avoiding restart of theserver after every change in JSP. But it gives poor performance in theproduction due unnecessary loading and burden on class loader. Soturn off your auto-reloading feature in the configuration file to

improve performance.

JSP engine creates the thread pool with some default size dependingupon configuration parameters of the configuration file for that pool.The pool will have minimum and maximum number of threads andyou can configure these numbers in the configuration file of your JSPengine. The number of maximum and minimum threads in pooldepends on concurrent users for your application. You have to



22/79


estimate number of concurrent users for your application and givethe thread pool size based on that. Obviously there is a limit onthread pool, which depends upon your hard ware resources. Bysetting thread pool size correctly, the performance of JSP increasessignificantly. Your application server/ JSP engine may not give the

facility to configure thread pool. Tomcat's JSP Engine gives thefacility to configure thread pool. Look at your application server /JSP engine documentation for the information about thread pool.

The include directive () is fasterthan the include action ().

redirects are slower thanforwards because the browser has to makea new request.



23/79


6 Design guidelines for Servlets

6.1 Caching.

Use the servlet init() method to cache static data, and release themin the destroy() method.

Implement the getLastModified() method to use the browser cacheand the server cache.

Use the application server's caching facility.

Session mechanisms from fastest to slowest are: HttpSession, Hiddenfields, Cookies, URL rewriting, the persistency mechanism.

Remove HttpSession objects explicitly in your program whenever youfinish the session.

Set the session time-out value as low as possible. The session objectmay be checked and manipulated in a servlet filter (interceptingfilter pattern) or RequestProcessor (if youre using STRUTS).

6.2 General.

Use the print() method rather than the println() method.

Use a ServletOutputStream rather than a PrintWriter to send binarydata.

Initialize the PrintWriter with the optimal size for pages you write.

Flush the data in sections so that the user can see partial pages morequickly.

Minimize the synchronized block in the service method.

Use transient variables to reduce serialization overheads.

Disable the servlet auto-reloading feature.

Tune the thread pool size.



24/79


7 Design guidelines for EJBs

Also refer to the design patterns section.

7.1 To ejB or not to ejB?

This is a question that is often asked at the start of a project. There areobject-relational-mapping (ORM) alternatives to EJB available like iBATIS,Hibernate, JDO, etc.

Rules for choosing EJB

Choose EJB when you know your application will need to scalebeyond initial low usage levels and support multiple, concurrentusers.

Choose EJB if you need transaction management. For onlinecatalogues or read-only systems with low user numbers, you probablydon't need EJB. For financial systems or any system where you mustpreserve the ACID (atomicity, consistency, isolation, and durability)

properties, EJBs are a must. Choose EJB if you need a comprehensive security model.

Rules for not choosing EJB

Do not use EJB when you find no need for scalability, transactionmanagement, or security and anticipate low numbers of read-onlyusers.

Don't choose EJB if you don't need platform independence and don'tmind being locked into one particular vendor.

Do not choose EJB if your team possesses no EJB experience (and youdon't plan on ramping up or importing such experience).

7.2 Local and Remote EJBs.

Once you decide to use an EJB application the first thing that you have todecide is choosing between local/remote EJB. EJB 2.0 introduced theconcept of local interfaces, which work as local EJB without distributedcomputing capability (RMI/RMI-IIOP) while EJB 1.1 supports only remoteEJBs.if you want to deploy your EJB client and EJB in the same server/JVM thenyou don't need the remote EJB but can use the local EJB .The local EJB doesnot use RMI/RMI-IIOP for communication, it bypasses this overhead and uses

pass-by-reference as normal java mechanism and hence is faster andefficient when compared to remote EJBs.

7.3 Transactions

In EJB, You can use transactions either declaratively or programmatically.The declarative transactions in EJB are at method level that meanstransaction starts (begins) when method starts and transaction ends



25/79


(commits) when method ends. And also transaction propagates into the submethods if the parent method uses these sub methods.

By default, most developers deploy EJBs with the transaction isolation levelset to TRANSACTION_SERIALIZABLE. This is the default in IBM VisualAge Java

- Enterprise Edition and other EJB deployment tools. It is also the mostrestrictive and protected transaction isolation level incurring the mostoverhead. Some workloads do not require the isolation level and protectionafforded by TRANSACTION_SERIALIZABLE. A given application might neverupdate the underlying data or be run with other concurrent updaters. Inthat case, the application would not have to be concerned with dirty, non-repeatable, or phantom reads. TRANSACTION_READ_UNCOMMITTED wouldprobably be sufficient.

You can divide a bean's methods into transactional methods and non-transactional methods and assign transaction attributes to only

transactional methods, assign 'NotSupported' or 'Never' to non-transactionalmethods so that you avoid transaction propagation. But note that'NotSupported' or 'Never' attributes can't be used for entity beans becauseentity beans need to involve in transaction to commit data, so use theseattributes for session bean's non transactional methods. In this process youare controlling transaction propagation if any method uses other sessionbeans but you have to be careful whether sub beans need a transaction ornot.

7.4 CMP or BMP?

Use CMP except in specific cases when BMP is necessary: fields usestored procedures; persistence is not simple JDBC (e.g. JDO); Onebean maps to multiple tables; non-standard SQL is used.

CMP can make many optimizations: optimal locking; optimistictransactions; efficient lazy loading; efficiently combining multiplequeries to the same table (i.e. multiple beans of the same type canbe handled together); optimized multi-row deletion to handledeletion of beans and their dependents.

CMP optimizations:o Lazy Loading: Deferring loading of any data until it is accessed

o Dirty Writes: Only updating data which has been changed in

the database

7.5 Tuning session bean instance size.

The creation and destruction of beans is expensive. To reduce this cost, TheEJB Container/Server creates pool of beans that depending upon vendorspecific configuration, you need to give a proper value for this pool size toincrease performance. As we discussed above, configure pool size, for



26/79


example weblogic's weblogic-ejb-jar.xml has an element and JBossserver's jboss.xml has an element . see your vendordocumentation for configuring your EJB server pool size.The number of maximum beans in pool impacts performance. If this isless, then the Container has to put the clients in the queue when the

number of clients accessing is more than the maximum pool size. Thisdegrades the performance and clients take more time to execute. For bestperformance, give maximum beans as equal to number of maximum clientsaccesses. This applies to stateful and stateless session, entity as well asmessage beans.



27/79


8 Design guidelines for JDBC

On an average, a typical web request performs 4 database queries.Experience has shown that database calls are a major performancebottleneck. BAD JDBC can overwhelm the database.

8.1 Datasources and Connections.

Use a connection pool mechanism whenever possible.

Connection.setReadOnly(true) to optimize read-only databaseinteractions.

Close connections after use in a finally block. If you are not using stored procedures or triggers, turn off

autocommit. All transaction levels operate faster with autocommitturned off, and doing this means you must code commits. Codingcommits while leaving autocommit on will result in extra commits

being done for every db operation. Cache datasources after initial JNDI lookup. Declare them as static

and use a singleton-like pattern to return the connection from thesame datasource.See code Listing 1 for a sample class that obtains connections.

SQLConnectionHaner.java

Listing 1 Sample class .

8.2 Statement.

SQL statements in JAVA code have to be recompiled in the database eachtime they are used. There are three types of Statement interfaces in JDBCto represent the SQL query and execute that query; they are Statement,PreparedStatement and CallableStatement.

Statement is used for static SQL statement with no input and outputparameters, PreparedStatement is used for dynamic SQL statementwith input parameters and CallableStatement is used for dynamic SQLstatement with both input and output parameters, but

PreparedStatement and CallableStatement can be used for static SQLstatements as well. CallableStatement is mainly meant for storedprocedures.

PreparedStatement gives better performance when compared toStatement because it is pre-parsed and pre-compiled by the databaseonce for the first time and then onwards it reuses the parsed andcompiled statement. Because of this feature, it significantly improves



28/79


performance when a statement executes repeatedly, It reduces theoverload incurred by parsing and compiling.

CallableStatement gives better performance when compared toPreparedStatement and Statement when there is a requirement forsingle request to process multiple complex statements. It parses and

stores the stored procedures in the database and does all the work atdatabase itself that in turn improves performance. But we loose javaportability and we have to depend up on database specific storedprocedures.

You can send multiple queries to the database at a time using batchupdate feature of statement objects this reduces the number of JDBCcalls and improves performance. Here is an example of how you cando batch update,statement.addBatch( "sql query1");statement.addBatch(" sql query2");statement.addBatch(" sql query3");

statement.executeBatch();All three types of statements have these methods to do batchupdate.

Close statement object in a finally block after use to give garbagecollector a chance to recollect memory.

8.3 Resultset.

Always close Resultset objects after use in a finally block.

ResultSet interface also provides batch retrieval facility like

Statement as mentioned above. It overrides the Statement behavior.Initially find the default size by usingResultSet.getFetchSize(); and then set the size as per requirementResultSet.setFetchSize(50);This feature significantly improves performance when you are dealingwith retrieval of large number of rows like search functionality.

ResultSet has the capability of setting the direction in which youwant to process the results, it has three constants for this purpose,they areFETCH_FORWARD, FETCH_REVERSE, FETCH_UNKNOWNInitially find the direction by usingResultSet.getFetchDirection(); and then set the direction accordinglyResultSet.setFetchDirection(FETCH_REVERSE);

ResultSet interface provides lot of getxxx() methods to get andconvert database data types to java data types and is flexible inconverting non feasible data types. For example,getString(String columnName) returns java String object.



29/79


columnName is recommended to be a VARCHAR OR CHAR type ofdatabase but it can also be a NUMERIC, DATE etc.If you give non-recommended parameters, it needs to cast it toproper java data type that is expensive. For example consider thatyou select a product's id from huge database, which returns millions

of records from search functionality, it needs to convert all theserecords that is very expensive.So always use proper getxxx() methods according to JDBCrecommendations.

CachedRowSet provides cached result sets that do not requirecontinuous connection to the database, allowing connections to bereused more efficiently.

o Using CachedRowSet lets you batch updates, and execute

them asynchronously.o CachedRowSet also supports offline work, which is later

synchronized.

o CachedRowSet is probably not appropriate for managing largedatasets.

@see: http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html

8.4 Transactions.

DB obtains necessary locks on rows and tables, uses and releases them inone step. Depending on transaction type, separate statements and commitscan result in more DB calls and hold DB locks longer. Following are the

Single-batch Transaction Types, which give significantly different effects:java.sql.ConnectionTRANSACTION_READ_COMMITTEDTRANSACTION_READ_UNCOMMITTEDTRANSACTION_REPEATABLE_READTRANSACTION_SERIALIZABLE

Dont have transaction span user input:-1. Application sends BEGIN TRAN and SQL, locking rows or tables for

update.2. Application waits for user to press key before committing transaction.

Use Optimistic Locking instead where you can detect stale data using: Timestamps

Version count State comparison

Refer http://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.html for some more insights into these with a working example.

http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.htmlhttp://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.htmlhttp://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.htmlhttp://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.htmlhttp://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.htmlhttp://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.htmlhttp://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.htmlhttp://www.javaworld.com/javaworld/jw-07-2001/jw-0713-optimism_p.html


30/79


8.5 Database Optimization.

Database optimization is a vast topic that is outside the scope of thisdocument. But performance of your application can often be significantly

improved by tuning the database and its objects. Poor DBMS performance canarise from a mismatch between the data-model, entity-bean design, and itsusage. If your most frequent user request joins 10 different tables and returnsfive entities of which you use only one, then this is a design flaw. Align yourDBMS access to support your usage patterns. Write a query to return only theone piece of data that you need.Doc 1 has some tips on optimizing SQL Server. Doc 2 has tips on optimizingOracle and general tips on optimizing queries.

Use stored procedures when they can be created in a standardmanner. Do watch out for DB specific SP definitions that can cause

migration headaches. Make your queries as smart as possible, i.e. as precise as possible to

minimize the data transferred to just that subset that is required.

Select only required columns rather than using select * fromTablexyz.

Process as much data as possible within the database.

Use Indexed Views (SQL Server) or Materialized Views (Oracle) forquerying large sets of data.

Some applications store operational data in the same table ashistorical data. Over time and with accumulation of this historicaldata, all operational queries have to read through lots of useless (on

a day-to-day basis) data to get to the more current data. Move non-current data to other tables and do joins to these tables for the rarerhistorical queries. If this can't be done, index and cluster your tableso that the most frequently used data is logically and physicallylocalized.

Case study: In Market metrics, several financial reports based onhistorical data were required. These reports were trends of amountspaid by or received by GE Corporate Insurance and other GEBusinesses over last 5-6 years. These reports presented the amountsdistributed over the years in different ways, either splitproportionately over the years/dates of their payments or totallyallocated to specific years for reporting purposes. To convert thebase amounts into the new forms while joining a large number oftables would have been time-consuming and complex, slowing downthe reports considerably. The solution adopted was to pre-calculatethe data in the different formats and store into special historicaltables that were de-normalized and indexed.. The database used was



31/79


SQL Server. This could not be accomplished with Indexed Viewsbecause a lot of joins, unions and other operations had to be carriedout in order to transform the data into a reportable format andIndexed Views have limitations that prevented this. If the databaseused was Oracle, this might probably have been easier. Another

advantage of this was that if a new way of apportioning amountscame up, the change would be decoupled from the main tables andonly the reporting tables would have to be enhanced with a new type.A disadvantage of this approach was that the report tables have to bemanually updated when the master tables are updated. Triggers couldhave been used for this purpose, but they are not recommended forperformance reasons.

"CHECK LIST For SQuery.doc"

efficientSql.pdf

Doc 1 SQL Server tips for optimization.

Doc 2 Oracle tips for optimization.

8.6 DAO.

The Data Access Object design pattern is used to abstract and encapsulateall access to the data source. The DAO manages the connection with the

data source to obtain and store data. The following are recommendedpractices for DAO:

Design your DAO so that it can be tailored to return only what youneed.

Design your DAO so that it can limit the number of rows returned.

Use finally clauses to ensure that all JDBC resources are closed whenyou're finished with them. This ensures that you don't hog or consumeconnections and cursors.

Query against DBMS views to make your DAOs more reusable andportable. If you need to make a change to a query, make a change tothe view instead.

With a DAO you can take advantage directly of the features provided bythe JDBC API, including:

PreparedStatements to pre-compile frequently executed SQLstatements



32/79


Batch methods on the Statement class (addBatch() andexectuteBatch()) to batch up multiple SQL calls into one hit to thedatabase

Row limiting (The Statement and ResultSet classes provide methods(setMaxRows() and setFetchSize()) to limit the number of rows

returned and set hints for ResultSet fetch sizes.)@see:http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

9 XML

9.1 Validation.

When you use a DomDocument class to load a large document thatcontains errors because the format is not correct, you waste memoryand CPU resources. Consider validating the input XML if there is arereasonable chances that the XML is invalid. In a closed environment,

you might consider validation an unnecessary overhead, but thedecision to use or not use validation is a design decision you need toconsider.

Documents exchanged within the components of the system may notrequire validation. Performance is therefore better.

Do not validate the same document more than once.

9.2 Canonicalization.

Any document can be converted in an equivalent (with some limitations)to a DTD-less document through a process named XML Canonicalization.The generated document is called a Canonical XML document. The XMLcanonicalization process results in some changes from the originaldocument, among others:

Encoding of the document in UTF-8.

Normalization of line breaks to #xA.

Normalization of the attribute values.

Substitution of character and parsed entities.

Removing of the XML declaration.

Removing of the document type declaration.

Addition of the default attributes.

Although canonicalization is not primarily meant for this purpose, we canuse it to improve performance.Unfortunately, so far, there is no standard XSL output method, whichcould be used with the identity transformer (presented above) togenerate a canonical form of a source document. To generate thecanonical form of a document you may have to write a custom SAX2ContentHandler. The Xerces distribution includes sample programs



33/79


(sax.SAX2Writer or sax.Writer for example), which generate canonicalXML.Canonicalization may be switched on in production only, when looking forthe best performance.

9.3 Consider Element and Attribute Name Lengths

Consider the length of the element names and the length of the attributenames that you use. These names are included as metadata in your XMLdocuments. Therefore, the length of an element or attribute name affectsthe document size. You need to balance size issues with ease of humaninterpretation and future maintenance. Try to use names that are shortand meaningful.

9.4 SAX and DOM

DOM gives you access to the information stored in your XMLdocument as a hierarchical object model. DOM creates a tree ofnodes (based on the structure and information in your XMLdocument) and you can access your information by interacting withthis tree of nodes. The textual information in your XML documentgets turned into a bunch of tree nodes.

SAX chooses to give you access to the information in your XMLdocument, not as a tree of nodes, but as a sequence of events! Youask, how is this useful? The answer is that SAX chooses not tocreate a default Java object model on top of your XML document(like DOM does). This makes SAX faster, and also necessitates the

following things:o creation of your own custom object model

o creation of a class that listens to SAX events and properly

creates your object model.

If your data is in tree form use DOM. If your data is like java objectproperties use SAX. For e.g., use SAX instead of DOM to read theLDAP details and get user profile.

SSOXMLHandler.ja SSOSAXXMLHandle

ava

UserProfile.java

9.5 Partial Parsing with SAX

If you can use SAX, and the information you want to extract from thedocument is located at the beginning or at least not located at the veryend, you may have better performance if you can interrupt the parsing assoon as all the information has been extracted. You can achieve this by



34/79


throwing a SAX exception. This may be especially useful when a documentis wrapped inside another document (the envelope) and you need to getsome information like the recipient to be able to route it. You may onlywant to extract information from the envelope without parsing thecontained document, which may be much bigger.

10 J2EE Object Caching Frameworks

10.1 Object Caching

The best definition of object caching can be found in the functionalspecification document for Object Caching Service for Java (OCS4J),which says:

A server must manage information and executable objects that fall intothree basic categories: objects that never change, objects that aredifferent with every request, and everything in between. Java is wellequipped to handle the first two cases but offers little help for the third.If the object never changes, we create a static object when the server isinitialized. If the object is unique to every request, we create a newobject each time. For everything in between, objects or information thatcan change and are shared across requests, between users or betweenprocesses, there is the "Object Caching Service." Basically, object cachingis all about avoiding the expensive re-acquisition of objects by notreleasing the objects immediately after their use. Instead, the objects are

stored in memory and are reused for any subsequent client requests.When the data is retrieved from the data source for the first time, it istemporarily stored in a memory buffer called cache. When the same dataneeds to be accessed again, the object is fetched from the cache insteadof acquiring it again from the data source. Finally, the cached data isreleased from the memory when it's no longer needed. Defining areasonable expiration time after which data stored in the object becomesinvalid, from web application standpoint, controls when a specific objectcan be released from memory.

10.2 Benefits of CachingOne of the main benefits of object caching is the significantimprovement in application performance. In a multi-tiered application,data access is an expensive operation, compared to any other task. Bykeeping the frequently accessed data around and not releasing it after thefirst use, we can avoid the cost and time required for the reacquisitionand release of the data. This results in greatly improved web application

http://www.jcp.org/aboutJava/communityprocess/jsr/cacheFS.pdfhttp://www.jcp.org/aboutJava/communityprocess/jsr/cacheFS.pdfhttp://www.jcp.org/aboutJava/communityprocess/jsr/cacheFS.pdf


35/79


performance, since we won't be hitting the database every time we needthe data.

Scalability is another benefit of using object caching. Since cached data isaccessed across multiple sessions and web applications, object caching

can become a big part of a scalable web application design. Objectcaching, just like object pooling, can help avoid the cost of acquiring andreleasing the objects.

10.3 Liabilities of Caching

Synchronization complexity: Depending on the kind of data, complexityincreases, because consistency between the state of the cached data andthe original data in the data source needs to be ensured. Otherwise, thecached data can get out of sync with the actual data, which will lead todata inaccuracies.

Durability: Changes to the cached data can be lost when the servercrashes. This problem can be avoided if a synchronized cache is used.Memory size: JVM memory size can get unacceptably huge if there is lotof unused data in the cache and the data is not released from memory atregular intervals

10.4 Cache Rules!

What can be cached?

Any data that does not change frequently and takes longer times to

retrieve from the data source.o Lookup data, code and description lists, common search

results with pagination. Data Transfer Objects if the data doesnt change often.

What should not be cached?

Secure information that can be accessed by other users on the website.

User profile information.

Personal information, such as Social Security Number or credit carddetails.

Business information that changes frequently and causes problemsif not up to date and accurate.

Session-specific data that may not be intended to be accessed byother users.



36/79


37/79




38/79


Example of a web application using caching.Listed below are the Java classes that a web application needs to know touse the caching functionality.

ICacheManager



39/79


This is the main interface (contract) that a client program uses to handleall of the operations related to caching (i.e., storing, accessing, andreleasing the data in the cache). The client program can be a JSP, StrutsAction class, or a POJO (Plain Old Java Object). This interface wascreated to hide all of the caching implementation details from the client

so if we need to switch to a different third-party caching API in thefuture, we wouldn't need to change any of the client code.

BaseCacheManagerThis is the main class in web portal caching framework. It's the baseimplementation of the ICacheManager interface. BaseCacheManager wascreated to centralize all of the cache-related methods in a single class.It's designed as a singleton to ensure that there is one and only oneinstance ofICacheManager created in the servlet container's JVM. In a clusteredenvironment where multiple web server/servlet container instances are

accepting the web requests, there will be a separate ICacheManagerinstance created in each JVM. If you switch to a different caching API inthe future, this is the only class that needs to be modified to work withthe new cache API. If you switch to a JCache-compliant cachingimplementation, the required changes in the cache manager should beminimal.

ICacheLoaderThis interface is used to implement the actual data access logic in theweb client. All of the client programs that need to use the cachingmechanism must implement this interface. It has a single method called

loadCacheObject() and takes two input parameters: a String to specify thecache region name and an Object to specify the cache key. This way, thecache manager will know which client program to use (to execute theloadCacheObject method) to reload the object in the cache when thecached data is expired after the specified "time to live" is elapsed.

ICacheKeyThe ICacheKey interface was created to hide the specific logic used tocreate a cache key. Sometimes the cache key may not be a simple string.It may be as complex as the combination of multiple objects, and gettingthese values from the data source involves several lookup methods

instead of one single method. In this case, the ICacheKey interface can beused to define all of the complex logic involved in creating the cache key.This way, the cache-key creation logic will be defined in a separate class.

CacheRegionsA cache region is defined as an organizational namespace for holding acollection of cache objects. You need to define the cache regions in theconfiguration file to store the data in separate memory spaces in the



40/79


cache to manage controlled expiration of the cached data. Objects withsimilar characteristics (such as time to live and business use) should becached in the same cache region so that they can all be invalidated at thesame time, if needed. Separate cache regions can be defined to store thelookup data and rate revision data. To eliminate any synchronization

issues that could cause poor performance, a separate instance of Cache(JCS) for each cache region can be used.CacheElementInfoThis class is used to encapsulate all of the caching statistics (such as hitcount, miss count, hit rate, etc.) that can be used to monitor theeffectiveness of caching each object in the web application.

10.7 References for Object-Caching Frameworks.

Java Performance Tuning, Jack Shirazi, O'Reilly JCS Home Page

JCache API OSCache SpiritCache Commons Collections Coherence Object Caching Service for Java

http://www.oreilly.com/catalog/javapt/http://jakarta.apache.org/turbine/jcs/index.htmlhttp://sourceforge.net/projects/jcachehttp://sourceforge.net/projects/jcachehttp://www.opensymphony.com/oscache/http://www.spiritsoft.com/products/cache/introducing.shtmlhttp://jakarta.apache.org/commons/collections.htmlhttp://www.tangosol.com/coherence.jsphttp://www.jcp.org/aboutJava/communityprocess/jsr/cacheFS.pdfhttp://www.oreilly.com/catalog/javapt/http://jakarta.apache.org/turbine/jcs/index.htmlhttp://sourceforge.net/projects/jcachehttp://www.opensymphony.com/oscache/http://www.spiritsoft.com/products/cache/introducing.shtmlhttp://jakarta.apache.org/commons/collections.htmlhttp://www.tangosol.com/coherence.jsphttp://www.jcp.org/aboutJava/communityprocess/jsr/cacheFS.pdf


41/79


11 Java best practices for performance

These are various tips to optimize performance. Practically speaking it is notpossible for developers to follow all of these, nor should they do it. These are

just points to be kept at the back of ones mind and used whenever the needarises. They are just hints and will not alone guarantee better performancebecause the impact of each of these points depends heavily on the JVM or theversion of JDK used.

11.1 Memory Management.

Memory leaks in Java occur in code that retains references to objects that arenot needed. Javas garbage collector periodically frees memory associated withnon-referenceable variables.

A variable described as static can easily cause a memory leak because

the reference ends when the JVM is stopped or the reference isspecifically nulled out.

Memory leaks in J2EE applications are frequently caused by staticallydefined collections. For instance, its common to define an applicationProperties object to store configuration details or language resources as:

public class PropertyFileReader{private static PropertyFileReader propertyFileReader = new

PropertyFileReader(); //singletonprivate static PropertyResourceBundle prBundle;

private static PropertyResourceBundle prMessageBundle;

}Any values stored in these property objects are referenceable.

11.2 Logging.

The application should not have System.out.println statements for logginginformation. Use log4J or Java logging API. When you deploy onproduction/staging reduce logging level to ERROR to reduce the number of I/O.

11.2.1 Log4J

One of the often-cited arguments against logging is its computational cost. Thisis a legitimate concern as even moderately sized applications can generatethousands of log requests. Much effort was spent measuring and tweakinglogging performance. Log4j claims to be fast and flexible: speed first,flexibility second.The user should be aware of the following performance issues.

1. Logging performance when logging is turned off.



42/79


When logging is turned off entirely or just for a set of levels, the cost of a logrequest consists of a method invocation plus an integer comparison. On a 233MHz Pentium II machine this cost is typically in the 5 to 50 nanosecond range.However, The method invocation involves the "hidden" cost of parameterconstruction.

For example, for some logger cat, writing,logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));incurs the cost of constructing the message parameter, i.e. converting bothinteger i and entry[i] to a String, and concatenating intermediate strings,regardless of whether the message will be logged or not. This cost ofparameter construction can be quite high and it depends on the size of theparameters involved.To avoid the parameter construction cost write:

if(logger.isDebugEnabled() {logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));

}This will not incur the cost of parameter construction if debugging is disabled.On the other hand, if the logger is debug-enabled, it will incur twice the costof evaluating whether the logger is enabled or not: once in debugEnabled andonce in debug. This is an insignificant overhead because evaluating a loggertakes about 1% of the time it takes to actually log.

In log4j, logging requests are made to instances of the Logger class. Logger is aclass and not an interface. This measurably reduces the cost of methodinvocation at the cost of some flexibility.

Certain users resort to preprocessing or compile-time techniques to compileout all log statements. This leads to perfect performance efficiency withrespect to logging. However, since the resulting application binary does notcontain any log statements, logging cannot be turned on for that binary. This isa disproportionate price to pay in exchange for a small performance gain.

2. The performance of deciding whether to log or not to log whenlogging is turned on.

This is essentially the performance of walking the logger hierarchy. Whenlogging is turned on, log4j still needs to compare the level of the log request

with the level of the request logger. However, loggers may not have anassigned level; they can inherit them from the logger hierarchy. Thus, beforeinheriting a level, the logger may need to search its ancestors.There has been a serious effort to make this hierarchy walk to be as fast aspossible. For example, child loggers link only to their existing ancestors. Butdevelopers can ensure that loggers are linked to the to the closest ancestorwith the required assigned levels. This significantly improves the speed of thewalk, especially in "sparse" hierarchies.

http://logging.apache.org/log4j/docs/api/org/apache/log4j/Hierarchy.html#setThreshold(java.lang.String)http://logging.apache.org/log4j/docs/api/org/apache/log4j/Hierarchy.html#setThreshold(java.lang.String)


43/79


The typical cost of walking the hierarchy is typically 3 times slower than whenlogging is turned off entirely.

3. Actually outputting log messages

This is the cost of formatting the log output and sending it to its targetdestination. Here again, a serious effort was made to make layouts(formatters) perform as quickly as possible. The same is true for appenders.The typical cost of actually logging is about 100 to 300 microseconds. Seeorg.apache.log4.performance.Logging for actual figures.

11.3 Collections.

ArrayList is faster than Vector except when there is no lock acquisitionrequired in HotSpot JVMs (when they have about the sameperformance).

Preset array capacity to as large as will be required. Vector and ArrayList implementations have excellent performance for

indexed access and update of elements, since there is no overheadbeyond range checking.

Adding elements to, or deleting elements from the end of a Vector orArrayList also gives excellent performance except when the capacity isexhausted and the internal array has to be expanded.

Inserting and deleting elements to Vectors and ArrayLists always requirean array copy (two copies when the internal array must be grown first).The number of elements to be copied is proportional to [size-index], i.e.to the distance between the insertion/deletion index and the last index

in the collection. The array copying overhead grows significantly as thesize of the collection increases, because the number of elements thatneed to be copied with each insertion increases.

For insertions to Vectors and ArrayLists, inserting to the front of thecollection (index 0) gives the worst performance, inserting at the end ofthe collection (after the last element) gives the best performance.

LinkedLists have a performance overhead for indexed access and updateof elements, since access to any index require