JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 043 contents

http://www.hwcs.com/products/diagnosys/enews/20040519.asp
Developing a performance strategy (Page last updated June 2004, Added 2004-06-30, Author H&W, Publisher H&W). Tips:

• Software defects found in production cost 100 times more to fix than those found early in the application lifecycle.
• More than 60 percent of enterprise system performance problems are related to application design.
• Use appropriate tools to identify performance problems.
• Use realistic test loads.
• Assign responsibilities for various performance tasks so that nothing slips through the cracks.
• Identifying performance problems before they impact users saves time and improves the company's reputation.
• Set up an automated performance analysis process that alerts people to potential performance problems.

http://www.stpmag.com/stp001.htm
Defining and Building High-Performance Software (Page last updated March 2004, Added 2004-06-30, Author Adam Neat, Publisher STPmag). Tips:

• Architects normally sets, or agrees with the customer, the performance targets and service level agreements for the application.
• Stress and volume testing should be done in production-like environment, before deploying the application and whenever there are changes to the application or infrastructure.
• Benchmarking measures performance for specific sets of functionality.
• All key transaction workflows should be performance tested.

http://www-106.ibm.com/developerworks/xml/library/x-trans1.html
Improve XML transport performance, Part 1 (Page last updated June 2004, Added 2004-06-30, Author Dennis M. Sosnoski, Publisher IBM). Tips:

• Preserve the structure of XML but use non-text representations for greater efficiency.
• XML text representation is generally larger than the binary representation of the same data.
• For XML, much of the overhead involved in communications processing is based on data volume.
• XMill is an XML transformation that's designed to reduce document size in combination with gzip compression.
• XBIS is an XML transformation focused on processing speed, which also gives a substantial size reduction as compared to text.

http://www-106.ibm.com/developerworks/xml/library/x-trans2/index.html
Improve XML transport performance, Part 2 (Page last updated June 2004, Added 2004-06-30, Author Dennis M. Sosnoski, Publisher IBM). Tips:

• Testing XML plain text, XBIS encoding, and gzip'd XML text shows you can reduce both processing time and document size using XBIS encoding, or vastly reduce document size but with increased processing time using gzip compression.

http://www.devx.com/Java/Article/20891
Connection Pools for JDBC (Page last updated April 2004, Added 2004-06-30, Author Alexey Prohorenko and Alexander Prohorenko, Publisher devX). Tips:

• Using a limited number of pre-connected database connections improves Web server productivity and eases the load on your database.
• Connection pools help you manage database connections efficiently.
• [Article discusses a connection pool implementation. Don't create your own, use a pre-existing one, there are several open source ones].

http://www.informit.com/articles/article.asp?p=174099
Understanding Tuning TCP (Page last updated May 2004, Added 2004-06-30, Author Deepak Kakadia, Publisher Prentice Hall). Tips:

• TCP flow control and congestion control mechanisms can interfere with each other, so proper tuning is critical for high-performance networks.
• TCP/IP Abort intervals (in the 3-way TCP handshake): too short and you can drop valid clients [I've seen many sites do this when I use dialup], too long leads to kernel resources being overused.
• TCP/IP time_wait_interval (waiting for client to shutdown): too high, the socket holds up resources, and if it is a busy server, the port and memory may be desperately needed; too short and lingering packets might be lost.
• Change the ramp up rate for sending packets according to your network connection capability; the default TCP/IP parameters uses a conservative slow start rate.
• TCP congestion and flow control should be tuned for the network capability and latency of communications. [Article describes several scenarios].

http://weblogs.java.net/pub/wlg/1393
Message acknowledgment and redelivery with message-driven beans (Page last updated June 2004, Added 2004-06-30, Author Simon Brown, Publisher java.net). Tips:

• Message-Driven beans proceed differently in the cases of container-managed (CMT) and bean-managed transactions (BMT): commit is handled the same for both; but with rollback of a CMT the container will not acknowldge the message on the JMS, thus making JMS attempt to redeliver the message; and with rollback of a BMT, the container will nevertheless acknowldge the message on the JMS, thus stopping JMS from attempting to redeliver the message.
• You should not be doing business logic when acknowledgng receipt of a message.
• Message-Driven beans probably should not be in a transaction to receive messages; instead they should take receipt, acknowledge, and queue the message for processing in a transaction.
• Throwing an exception in response to a message can cause the container to try and re-deliver that message, causing a continual or long lasting inefficient loop.

http://www.onjava.com/pub/a/onjava/2004/03/31/clustering.html
Clustering and Load Balancing in Tomcat 5, Part 1 (Page last updated March 2004, Added 2004-06-30, Author Srini Penchikala, Publisher OnJava). Tips:

• Scalability is the system's ability to support increasing numbers of users by adding additional servers to the cluster. High availability is basically providing redundancy in the system.
• Deploying a server in a cluster environment gives us the ability to achieve scalability, reliability, and high availability.
• To scale, you should include additional machines within the cluster and to minimize downtime, you should make sure every component of the cluster is redundant.
• JavaGroups is a popular choice for adding clustering capabilities in open source servlet containers and application servers.
• Most of the J2EE application servers (such as JBoss, Oracle, WebLogic, and Borland) all use IP multicast communication to send state/updates/heartbeats to one another in the cluster.
• Session management in clusters are one of two alternatives: sticky sessions (the user session lives entirely on one server); or replicated sessions (each cluster member is completely aware of session state in other cluster members, with the session state periodically propagated to all cluster members).
• There are three ways to implement session persistence: Memory-to-memory replication; File System session persistence, where session information is written to and read from a centralized file system; Database session persistence, where session data is stored in a JDBC data store.
• In memory session replication, the individual objects in the HttpSession are serialized to a backup server as they change,
• In database session persistence, the objects in the session are serialized together when any one of them changes.
• Database and file system session persistence is limited scalability when storing large or numerous objects in the HttpSession, as every time a user adds an object to the HttpSession, all of the objects in the session are serialized and written to the database or shared file system.

http://www.javaworld.com/javaworld/jw-05-2004/jw-0517-optimization.html
J2EE application performance optimization (Page last updated May 2004, Added 2004-06-30, Author Rahul Kuchhal, Publisher JavaWorld). Tips:

• For maximum performance, all the components - operating system, Web server, application server, and so on ? need to be optimized.
• Before you begin tuning your J2EE application's performance, set a goal. Typical goals include the concurrent users and the request response times.
• Once the performance goal is set, try to make changes that are expected to have the biggest impact on performance. Your time is better spent tuning a method that takes 10 seconds but gets called 100 times than tuning a method that takes one minute but gets called only once.
• Test one change at a time, stress-test it, and if the change results in positive impact, make it permanent.
• Identifying bottlenecks is an iterative process. You need stress tools that generate load for your applicationand monitoring tools that collect data for various performance indicators.
• Important stress test tool features include: Support for a large number of concurrent Web users; Ability to record test scripts automatically from browser; Support for cookies, HTTP request parameters, HTTP authentication mechanisms, and HTTP over SSL (Secure Socket Layer); Option to simulate requests from multiple client IP addresses; Flexible test scheduling and reporting.
• OS statistics to monitor include: processor run queue; processor percent utilization; percent priviliged (kernel/system) time; paging; available RAM; disk queue size; percent utilization of disk; network output queue size; network transfer rate (compared to the available network capacity).
• Use OS statistics to isolate where the bottleneck is: on the application server, Web server, or database server.
• Web server and application server configuration tuning options include: thread pool size; eliminating reverse DNS lookups; minimizing logging; JVM heap size; JVM vendor/version; not loading unnecessary resources; avoid auto-reload and auto-deploy features (they are normally for development).
• Database tuning options include: Running on a separate machine; separating application and temporary data on dfferent disks;
• Application level bottlenecks are best identified: by using a Java profiler; adding targeted configurable logging.
• Avoid using synchronized blocks in your code as much as possible.
• Use a logging mechanism that lets you switch off logging in the production environment.
• Use resource pools for costly resources, e.g JDBC connections and threads;
• Try to minimize the objects you store in HttpSession.
• Use RequestDispatcher.forward() instead of HttpServletResponse.sendRedirect().
• Don't use SingleThreadModel.
• Use OutputStream in place of PrintWriter.
• Reduce the default session timeout.
• Try not to use ServletRequest.getRemoteHost(), (this is a reverse DNS lookup).
• Add directive <%@ page session="false"%> to JSP pages where you do not need a session.
• Minimize use of custom tags.
• Use the database vendor performance monitoring tools to identify inefficient SQL.
• Consider adding indexes to those columns causing full-table scans.
• Keep database transactions as short as possible.
• Do not use SQL DISTINCT clauses unnecessarily.
• Instead of SELECT *, use SELECT col1,col2,... to get exactly the data you need.
• Try to avoid SQL string functions or operators like SUBSTRING, LOWER, UPPER, and LIKE.

http://www-106.ibm.com/developerworks/java/library/j-jtp02244.html
Fixing the Java Memory Model, Part 1 (Page last updated February 2004, Added 2004-06-30, Author Brian Goetz, Publisher IBM). Tips:

• In the absence of synchronization, memory operations can appear to happen in different orders from the perspective of different threads.
• Synchronization enforces mutual exclusion of multiple threads entering a block protected by a particular monitor. Synchronization also enforces memory visibility rules: memory caches are flushed on exit of synchronized blocks and invalidated on entry.
• volatile fields can be updated (prior to 1.5 or some 1.4 versions) out-of-order with respect to other writes in the same code block, hence volatile fields can be updated earlier (or later) than expected from the code context.

http://www-106.ibm.com/developerworks/java/library/j-jtp03304/
Fixing the Java Memory Model, Part 2 (Page last updated March 2004, Added 2004-06-30, Author Brian Goetz, Publisher IBM). Tips:

• Synchronization also enforces memory visibility rules: memory caches are flushed on exit of synchronized blocks and invalidated on entry.
• The new JMM requires that volatile reads and writes cannot be reordered by the compiler with respect to other reads and writes.

Jack Shirazi

Back to newsletter 043 contents