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 020 contents

http://www.onjava.com/pub/a/onjava/2002/07/10/jboss.html
Clustering with JBoss (Page last updated July 2002, Added 2002-07-24, Authors Bill Burke, Sacha Labourey). Tips:

• A hardware- or software-based HTTP load-balancer usually sits in front of the application servers within a cluster. The load balancer can decrypt HTTPS requests and distribute load.
• HTTP session replication is expensive for a J2EE application server. If you can live with forcing a user to log in again after a server failure, then an HTTP load-balancer probably provides all of the fail-over and load-balancing functionality you need.
• If you are storing things other than EJB Home references in your JNDI tree, then you may need clustered JNDI.
• 24/7 availability needs the ability to hot-deploy and undeploy new applications and new versions, and to apply patches, without bringing down the application server for maintenance.
• Smart proxies can be used to implement load-balancing and fail-over for EJB remote clients. These proxies manage a list of available RMI connections one of which it will use to service an invocation.

http://wireless.java.sun.com/midp/ttips/memory/
MIDP memory tuning (Page last updated June 2002, Added 2002-07-24, Author Jonathan Knudsen). Tips:

• Use an obfuscator to minimize the size of classes.
• Minimize resource sizes by using as few images as possible, and using fewer colors in the images you do use.
• Use as few objects as possible.
• Dereference objects (set them to null) when they're no longer useful so they will be garbage-collected.
• Catch OutOfMemoryErrors on all allocations, or at least the large ones. Don't let an OutOfMemoryError take your application by surprise.
• MIDlets use three types of memory: program memory, heap, and persistent storage. Each of these may be scarce and they should all be treated with respect.

http://www.informit.com/content/index.asp?product_id={11E331A5-5A08-4FFD-B018-2A7E24D0359B}
Application performance tuning (Page last updated July 2002, Added 2002-07-24, Author Baya Pavliashvili and Kevin Kline). Tips:

• Application performance problems can be caused and mitigated with any combination of the following areas: Network topology and throughput; Server hardware configuration; client application code; middle-tier components; database communication code; database configuration settings; logical and physical database design; operating system settings; client hardware; overall application architecture.
• Monitor the application. Primary statistics worth analyzing are: the number of concurrent users; number of transactions per unit of time; duration of the longest and shortest transactions; and the average response time.
• Specify the performance targets.
• Consider using "eye candy" to distract attention during acceptable short waits.
• Identify which application tier contains the bottleneck and fix that. It might be hardware or software; low-level or architecture.
• Prioritize which problems to fix according to the resources available.

http://www.sys-con.com/weblogic/article.cfm?id=101
HTTP sessions vs. stateful EJB (Page last updated July 2002, Added 2002-07-24, Author Peter Zadrozny). Tips:

• The comparative costs of storing data in an HTTP session object are roughly the same as storing the same data in a stateful session bean.
• Failure to remove an EJB that should have been removed (from the HTTP session) carries a very high performance price: the EJB will be passivated which is a very expensive operation.

http://www.sys-con.com/weblogic/article.cfm?id=102
Precompiling JSPs (Page last updated July 2002, Added 2002-07-24, Author Steve Mueller, Scot Weber). Tips:

• Precompile your JSPs one way or another to avoid the first user having a slow experience.

http://www7b.boulder.ibm.com/dmdd/library/techarticle/0204pooloth/0204pooloth.html
High performance inserts with DB2 and JDBC (Page last updated April 2002, Added 2002-07-24, Author Krishnakumar Pooloth). Tips:

• Use SQLJ to get the use of buffered inserts, and modify the code generated from SQLJ to reuse the RTStatement object.

http://javazoid.com/OptimizingSqlView.html
Optimizing padded string display (Page last updated June 2002, Added 2002-07-24, Author Gervase Gallant). Tips:

• Avoid copying individual string characters. Use the same underlying char array, by using methods like String.substring().

http://www.onjava.com/pub/a/onjava/2002/07/17/web.html
High load web servlets (Page last updated July 2002, Added 2002-07-24, Author Pier Fumagalli). Tips:

• Hand off requests for static resources directly to the web server by specifying the URL, not by redirecting from the servlet.
• Use separate webservers to deliver static and dynamic content.
• Cache as much as possible. Make sure you know exactly how much RAM you can spare for caches, and have the right tools for measuring memory.
• Load balance the Java application using multiple JVMs.
• Use ulimit to monitor the number of file descriptors available to the processes. Make sure this is high enough.
• Logging is more important than the performance saved by not logging.
• Monitor resources and prepare for spikes.

http://cin.earthweb.com/public/article/0,,10493_1145241,00.html
Website usability metrics (Page last updated May 2002, Added 2002-07-24, Author Sharon Gaudin). Tips:

• A website must be easy to navigate and have a quick display and response time.
• Bad navigation metrics include: abandoned shopping carts; first time visitors look at one or two pages and disappear; dead ends require the "back" button; less than 5% buy something; any broken links.
• Good navigation metrics include: three pages or less from wesbite entry to desired information; no streaming video or Flash introductions; multiple ways to reach the required information; up to date search engines; basic compancy and contact info one click away from the homepage.

http://itmanagement.earthweb.com/ecom/article/0,,11952_1370691,00.html
Common issues affecting Web performance (Page last updated June 2002, Added 2002-07-24, Author Drew Robb). Tips:

• Symptoms of network problems include slow response times, excessive database table scans, database deadlocks, pages not available, memory leaks and high CPU usage.
• Causes of performance problems can include the application design, incorrect database tuning, internal and external network bottlenecks, undersized or non-performing hardware or Web and application server configuration errors.
• Root causes of performance problems come equally from four main areas: databases, Web servers, application servers and the network, with each area typically causing about a quarter of the problems.
• The most common database problems are insufficient indexing, fragmented databases, out-of-date statistics and faulty application design. Solutions include tuning the index, compacting the database, updating the database and rewriting the application so that the database server controls the query process.
• The most common network problems are undersized, misconfigured or incompatible routers, switches, firewalls and load balancers, and inadequate bandwidth somewhere along he communication route.
• The most common application server problems are poor cache management, unoptimized database queries, incorrect software configuration and poor concurrent handling of client requests.
• The most common web server problems are poor design algorithms, incorrect configurations, poorly written code, memory problems and overloaded CPUs.
• Having a testing environment that mirrors the expected real-world environment is very important in achieving good performance.
• The deployed system needs to be tested and continually monitored.

http://developer.java.sun.com/developer/JDCTechTips/2002/tt0709.html
LinkedHashMap and RandomAccess (Page last updated July 2002, Added 2002-07-24, Author Glen McCluskey). Tips:

• LinkedHashMap preserves various ordering information, optionally including access ordering which makes LinkedHashMap appropriate for a least recently used (LRU) cache.
• ArrayList has fast random access of elements, LinkedList has slow random access of elements. List classes that implement the RandomAccess interface have fast random access and using get() to iterate their elements is efficient. If RandomAccess is not implemented, use an Iterator to iterate the elements.

http://www.sys-con.com/java/article.cfm?id=1534
Emulating another system (a ZX Spectrum) (Page last updated July 2002, Added 2002-07-24, Author Razvan Surdulescu). Tips:

• Painting pixel by pixel by repeatedly calling fillRect() is slow. Instead create the offscreen image as a decorator for a java.awt.image.MemoryImageSource object containing a byte array in RGB format with the pixel data. The rendering code updates the byte array and then calls MemoryImage-Source.newPixels() to notify the object that the data has been updated.
• Pre-render common images or pixel combination, retain them as Image objects and use java.awt.Graphics.drawImage() (Java 1) or java.awt.image.BufferedImage.setRGB() (Java 2) to render the image to the graphics buffer.

http://www.sys-con.com/java/article.cfm?id=1533
The smallest "Hello World" (Page last updated July 2002, Added 2002-07-24, Author Norman Richards). Tips:

• [Brilliantly amusing search to make the smallest "Hello World" program.]
• Use the -g:none option to strip debugging bytes from classfiles.
• Most bytes in Java class files are from the constant pool, then the method declarations. The constant pool includes class and method names as well as strings.
• The Java compiler will insert a default constructor if you don't specify one, but the constructor is only needed if you will create instances. You can remove the constructor if you will not be creating instances.
• Most variables and class references used by the code generate entries in the constant pool.
• Reusing already existing constant pool entries for class/method/variable names reduces the class file size.

http://java.ittoolbox.com/pub/SC071902/httprevealer_servlets_itx.htm
Speeding web page downloads using compression (Page last updated July 2002, Added 2002-07-24, Author Steven Chau, Publication HttpRevealer.com). Tips:

• Browsers sending "Accept-Encoding: gzip" will accept gziped compressed pages. Return the page compressed with "Content-Encoding: gzip" using GZIPOutputStream.
• Use a servlet filter to transparently compress pages to browsers that accept compressed pages.

http://www.javaworld.com/javaworld/jw-07-2002/jw-0703-service.html
The Verified Service Locator pattern (Page last updated July 2002, Added 2002-07-24, Author Paulo Caroli, Publication JavaWorld). Tips:

• The Service Locator pattern improves performance by caching service objects that have a high-lookup cost.
• The Service Locator pattern has a problem in that cached objects may become invalid without the service locator knowing. The Verified Service Locator pattern periodically tests the validity of the caches objects to avoid providing invalid service objects to requestors.

http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html
Runtime.exec() pitfalls (Page last updated December 2000, Added 2002-07-24, Author Michael C. Daconta). Tips:

• Runtime.waitFor blocks until the spawned process terminates.
• Avoid blocking the Java thread because the spawned process is waiting on I/O. Make sure you read and write the spawned process's I/O as required.

http://www.theserverside.com/resources/article.jsp?l=J2EEPerformance
Improving J2EE performance (Page last updated May 2002, Added 2002-07-24, Author Scott Marlow). Tips:

• Set performance goals before development starts.
• If supporting clients with slow connections, consider compressing data for network communication.
• Minimize the number of network round trips required by the application.
• For applications to scale to many users, minimize the amount of shared memory that requires updating.
• Cache data to minimize lookup time, though this can reduce scalability if locks are required to access the cache.
• If there are more accesses than updates to a cache, share the access lock amongst all the accessors, though be aware that this reduces the window for updators to lock the cache.
• For optimum performance, zero shared memory provides a cache per user.
• Be methodical to ensure that changes for performance do actually improve performance.
• Eliminate memory leaks before tuning execution speed.
• Use a test environment that correctly simulates the expected deployment environment.
• Simulate the expected client activity, and compare the performance against your expected goals.
• Consider which metrics to measure, such as: Max response time under heavy load; CPU utilization under heavy load; How the application scales as additional users are added.
• Profile the application to find the bottlenecks. Correct bottlenecks by making one change at a time and testing for improvement.
• Generate stack traces to look for bottlenecks which are multi-thread conflicts (waiting for locks).
• Improving the performance of a method that is called 1000 times and takes a tenth of a second on average each call, is better than improving the performance of a method that is only called 10 times but takes 1 second each call.
• Don?t cache data unless you know how and when to invalidate the cached entries.

http://www.theserverside.com/resources/article.jsp?l=Building-Sclable-Recoverable-Applications
Scalable recoverable applications (Page last updated May 2002, Added 2002-07-24, Author Billy Newport). Tips:

• [Article describes several approaches to building a scalable recoverable system]
• Split the application into a transactional part and a non-transactional part. The non-transactional part can be replicated.
• Using a single machine limits both reliability and scalability. Scalability is completely dependent on how powerful the single machine can become.
• Multiple front-end machines with http request load balancing is more reliable, but the database machine is still a single point of failure.
• A database caching layer in the servlet helps performance. An EJB caching layer is difficult to achieve.
• Oracle 9i includes queryable snapshots of the main database which can offload the query to run against the clients local snapshot.
• An in-memory database (such as TimesTen) is very, very fast and can act as a queryable cache for a back end database.
• Database instances on each machine, with replication increases reliability and access speed. But updates now need to be handled differently. Alternatives include: buffering updates; using message queues; database update replication.
• Partitioning the database across multiple machines adds scalability, but must be done with care.
• If you want very reliable systems then everything has to be controlled.
• A load balancing message queue may be needed for a high rate of messages (>500/sec).
• Note that reliable systems should ensure that all duplicated data have no single points of failure in the software or hardware chain behind the data (different controllers, UPSs, etc).

http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl0515.html
Sun Community chat on Java BluePrints (Page last updated May 2002, Added 2002-07-24, Author Edward Ort, Publication Sun Developer). Tips:

• For very large transactions, use transaction attribute TX_REQUIRED for EJB methods to have all the method calls in a call chain use the same transaction.
• Make tightly coupled components local to each other. Put remote beans primarily as facades across subsystems.
• The page-by-page pattern is designed to handle cases where the result set is large, and the end-user is not interested in seeing all of the results. There is really no upper threshold for the size of result set in the pattern.

Jack Shirazi Back to newsletter 020 contents