A Portal Composite Pattern Using WebSphere Portal V5

228 A Portal Composite Pattern Using WebSphere Portal V5

way to disable the parallel mode is to use the -Xgcthreads parameter to change

the number of garbage collection helper threads being started.

When using concurrent mode, a background thread is started by the JVM

(independently from the garbage collection helper threads), and some part of the

work is done in the background while the application threads are active. The

background thread tries to complete part of the garbage collection work

concurrently with the application, so that when garbage collection does kick in,

the resulting STW pause will be reduced.

In some cases, though, concurrent processing can have a negative impact on

performance, especially for CPU-intensive applications.

Use the -verbosegc command line parameter to track your garbage collection

operations. Enabling verbosegc can have a performance impact on an

application. If such impact is unacceptable, a test system should be used to

collect the verbosegc logs. It is common for server applications to keep

verbosegc enabled at all times. This can be a good way to monitor the overall

health of the JVM, and can be invaluable in post-mortem if an OutOfMemory

error occurs.

For more information on garbage collection, see:

򐂰 WebSphere Application Server InfoCenter

http://www-3.ibm.com/software/webservers/appserv/infocenter.html

򐂰 “Fine-tuning Java garbage collection performance,” by Sumit Chawla,

Technical Lead, eServer Java Enablement, IBM

http://www-106.ibm.com/developerworks/ibm/library/i-gctroub/

8.8 Performance guidelines

In this section we present a conceptual overview on caching and object pooling

strategies. Both can help you to build scalable and well-performing portlet

applications. In addition, we point out some common performance pitfalls in

portlet coding.

8.8.1 Caching

Caching is a vital part of any Web application when you are trying to optimize

performance, but caching can also be very difficult to implement.

Chapter 8. Portal application design and development guidelines 229

As a solution and application designer, you should consider the caching

possibilities as early as possible in your designs. There are two important forms

of caching.

Product-delivered caching

The standard products that are typically used in Web applications often offer

different caching mechanisms that can be used. It is important to understand

which products in the operational model offer caching, and how they can be

combined.

򐂰 HTTP servers

HTTP servers typically offer caching of static content, like images, static html

files, javascript, and css files. It is generally a good idea to have the HTTP

server serve these items instead of the application server. For more

information on IBM HTTP Server caching, see:

http://www-3.ibm.com/software/webservers/httpservers/

򐂰 Application servers

Application servers like WebSphere Application Server have servlet caching

for caching content delivered by the Web applications running at the server.

They also deliver prepared statement caching for optimizing access towards

the used database. For more information on WebSphere Application Server

caching:

http://www-3.ibm.com/software/webservers/appserv/infocenter.html

򐂰 Portal server

WebSphere Portal has different cache settings, which you can tune in order to

gain performance improvements. These cache settings are stored in property

files in the WP_ROOT/shared/app/config/ directory.

There are no particular settings to gain the most performance; instead, the

settings have to be in sync with the non-functional requirements of your

solution.

As an example, you should consider how long your unpersonalized pages are

to be cached. By default, WebSphere Portal only caches them for 60

seconds. If you are not creating, updating, or deleting pages several times an

hour on your production system, you might want to consider increasing this

setting. On the other hand, you do not want to wait hours to see a change

take effect.

Another example is the caching of the user’s access rights. Often the user’s

access rights are based on the group of which he is a member. Consider the

time that access rights are to be cached, based on the relative stability or

volatility of your access group memberships and individual access rights

changes.