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