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

http://weblogs.java.net/blog/caroljmcdonald/archive/2009/11/12/web-site-performance-tips-and-tools
Web Site Performance Tips and Tools (Page last updated November 2009, Added 2009-11-30, Author Carol McDonald, Publisher java.net). Tips:

• Minimize the number of components in a page that need separate HTTP requests
• Static components should set a far future expires header
• Dynamic components should use a cache-control header
• GZIP as much as possible
• Put stylesheets at the top of the page to display content quickly
• Put scripts at the bottom of the page (they slow down rendering)
• Avoid CSS expressions for dynamic properties
• Make JS and CSS external (the files are cached by the browser)
• Unique hostnames in URL lookups are done in parallel on a page - so more means more parallel downlaods, but more lookups too. Generally try to reduce lookups.
• Remove unnecessary characters (whitespace, comments) from scripts to reduce its size. (Minify JavaScript using JSMin or YUI Compressor)
• Avoid redirects
• Optimize images *
• Keep the size of cookies as small as possible
• [Excellent summary article listing many tips and tools for optimizing website performance].

http://www.hpts.ws/session9/shoup.pdf
eBay?s Challenges and Lessons (Page last updated October 2009, Added 2009-11-30, Author Randy Shoup, Publisher eBay). Tips:

• Partition everything so that you can scale it as necessary.
• Use asynchrony everywhere, connected through queues.
• Use recovery and reconciliation rather than synchronous transactions.
• Automate everything - components should automatically adjust and the system should learn and improve itself.
• Monitor everything, providing service failover for parts that fail.
• Avoid distributed transactions.
• Design for extensibility, deploy changes incrementally.
• Minimize and control dependencies, use abstract interfaces and virtualization, components should have an SLA.
• Save all (monitoring) data - this provides optimization opportunities, predictions, recommendations.
• Maximize the utilization of every resource.

http://www.javaspecialists.eu/archive/Issue177.html
Logging Part 3 of 3 (Page last updated October 2009, Added 2009-11-30, Author Dr. Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:

• Guard logging calls with a simple test that determines whether the log call will be used, thus avoiding extra creation of objects and execution of unnecessary code at runtime.
• Whenever you do any operation that could take significant time to complete, you should log the time it took to execute.
• Logging queue lengths helps tune the system. If the runnable queue of a thread pool gets too large, you know that you need more threads or cores to execute the work.
• Be careful that your logging does not become a bottleneck in itself.
• Use code guards in your logging systems so that When you turn off logging it should be completely silent, without creating any objects.
• When logging from several threads, log a unique thread identifer as part of your message.
• There is no way to get a unique thread id in Java across the lifetime of the program (Thread.getId() says that when a thread is terminated, this thread ID may be reused). You need to add an identifier to the thread ID to keep it unique.

http://blogs.sun.com/mobility_techtips/entry/simple_strategy_for_logging_and
Simple Strategy for Logging and Monitoring of MIDlets (Page last updated September 2009, Added 2009-11-30, Author Vikram Goyal, Publisher Sun). Tips:

• You have a variety of locations to log messages to in a MIDlet: Local store, Bluetooth device, Internet server, SMS. [Article shows implementations for these and recommendations for appropriate destination given message severity level.]

http://java.sun.com/developer/technicalArticles/javame/javame-logging/index.html
Powerful Logging in Java ME (Page last updated November 2009, Added 2009-11-30, Author Johan Karlsson, Publisher Sun). Tips:

• A suggested logging solution for JavaME is the Microlog open-source logging library - based on the well known Log4j but has been created from the ground up with Java ME limitations in mind. [Article provides and example of using Microlog and details the destinations, levels, options and some configurations available with it.]

http://java.dzone.com/news/performance-considerations
Performance Considerations in Distributed Applications (Page last updated September 2009, Added 2009-11-30, Author Alois Reitbauer, Publisher JavaLobby). Tips:

• Many distributed application performance issues stem inefficient serialization of objects (to send across the wire).
• Connection pooling can be an important performance improvement for many types of distributed communications (not just database communications).
• Asynchronous communication is more difficult to design and implement, but is usually more efficient for distributed communications.
• Making too many service calls from the client is a frequent source of performance problems.
• Using a more efficient communication protocol can make a huge difference to overall performance (Wrong Protocol Anti-pattern) - the overhead of SOAP compared to RMI-JRMP is significant. An inefficient protocol can cause a performance degradation by a factor of ten and significantly higher CPU and memory consumption.
• When building distributed applications, make as few remote calls as possible (Chatty Application Anti-pattern).
• Keep message size as small as possible, for example the overhead of serialisation is proportional to the size of the transferred objects (Big Messages Anti-pattern).
• With a high number of deployment units, the interaction of services become more and more difficult to understand. This can lead to a situation where two heavily-interacting services are deployed on different hardware resulting in a high number of remote calls. You need to analyze the frequency of interactions as well as data volume to structure deployment accordingly and avoid inefficent deployment configurations (Distributed Deployment Anti-pattern).

http://www.developer.com/java/data/article.php/10932_3847901_2/Implement-Java-Connection-Pooling-with-JDBC.htm
Implement Java Connection Pooling with JDBC (Page last updated November 2009, Added 2009-11-30, Author M S Sridhar, Publisher Gamelan). Tips:

• A connection object lifecycle is: Creation; Initialization; Ready for use; Use any number of times; Destruction; Garbage collection.
• The connection pool manager needs to: Create the pool; Create connections and add them to the pool; Keep track of connection usage; return the appropriate information connection users (e.g. no connections available); Allocate connections on request; De-allocate return connections to the pool when they are returned; Destroy connections and remove from the pool when necessary; Destroy the connection pool on shutdown;
• maximum number of connections in the pool should be an attribute that can be adjusted to suit the application.
• You may not want to start creating all the connections when the connection pool is created, four approaches are: initialize when the pool is created; initialize as a background task; initialize on first use; keep only one unused connection initialized.
• When a client requests a connection object, you should make additional checks to validate the connection object.
• Tune the maximum number of connections, every database connection is a resource-intensive object; maintaining and creating even hundreds of connections could literally kill your application by consuming massive amounts of memory.

Jack Shirazi Back to newsletter 108 contents