Back to newsletter 061 contents

http://www.jivesoftware.org/wildfire/article_optimization.jsp
Optimizing Wildfire (Page last updated December 2005, Added 2005-12-30, Author Gaston Dombiak and Matt Tucker, Publisher Jive Software). Tips:

• Never optimize before it's needed.
• Easily understood code is better than a 0.5% performance improvement.
• Profilers can lie.
• Avoid creating objects that don't need to be created (e.g. many object copies).
• Initialize StringBuilder objects with the proper size.
• The underlying TCP/IP layer doesn't always inform Java about dead sockets. Rather wait forever in a socket flush or write operations, force sockets closed if write operations take too long.
• Exceptions should not be thrown as part of normal application logic (they should be thrown only for exceptional cases)

http://java.sun.com/performance/reference/whitepapers/tuning.html
Java Tuning White Paper (Page last updated December 2005, Added 2005-12-30, Author Sun, Publisher Sun). Tips:

• System activities and other applications can introduce significant variance into the measurements of any application's performance. Try to minimize/eliminate any resource contention that may interfere with your measurements.
• Simplify application behavior as much as possible and change only one variable at a time (i.e. operating system tunable parameter, Java command line option, application argument, etc.) for tests.
• The modern JVM has adaptable performance, so microbenchmarks can be very misleading. There are many subtle issues to consider, so beware of any artificial tests you run. Always try to reach a steady state before taking measurements.
• System.currentTimeMillis() has an effective 15 ms granularity on some Windows platforms, this can confuse measurements for short tests.
• You should use System.nanoTime() in preference to System.currentTimeMillis().
• Use averages, variances and statistical signficance to determine how performance has changed across tests.
• Use a benchmark harness, e.g. a script that launches the test, captures the output log files, and extracts measurements.
• Note from JVM 1.5+ the JVM uses "ergonomics" to use different defaults for different systems. For example server-class default to using -server, -XX:+UseParallelGC, -Xms of 1/64th of the machine's physical memory, and -Xmx of 1/4th of the machine's physical memory (up to 1 GB max).
• The sum of the Java heaps should be sized below the physical RAM less the RAM needed by the system processes and any other processes. Sizing the heaps so that they exceed a system's physical memory is likely to result in paging of virtual memory to disk, quite likely during garbage collection operations, leading to significant performance issues.
• After sizing the heap, the next most important Java memory tunable is the size of if the young generation (NewSize).
• Common GC options for large server applications are -XX:+UseParallelGC or -XX:+UseConcMarkSweepGC
• The command line options -XX:+UseLargePages (on by default for Solaris) and -XX:LargePageSizeInBytes give the best efficiency out of the memory management system of your server. (Note larger page sizes may cause larger space sizes for the Permanent Generation and the Code Cache, which in turn can force you to reduce the size of your Java heap. This tends to be a concern with 256 MB page sizes).
• Use -Xmn to configure a sufficiently large young generation heap. Larger young generations prevent short lived objects from being prematurely promoted to the old generation, where garbage collection is more expensiv
• Use -Xss (e.g. -Xss128k) to reduces the default maximum thread stack size, allowing more of the process' virtual memory address space to be used by the Java heap.
• When using -XX:+UseParallelGC you may want to set -XX:ParallelGCThreads=N where N is less than the number of CPUs - the default would be equal to the processor count, which would probably be unnecessarily high on a 32 thread capable system.
• Try -XX:+UseParallelOldGC, the parallel old generation collector. Certain phases of an old generation collection can be performed in parallel, speeding up a old generation collection.
• -XX:+UseBiasedLocking - An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain speedups with this flag enabled (don't use by default, could easily slow down the multithreaded apps)
• -XX:SurvivorRatio=N sets survivor space ratio to 1:N. The smaller the ratio, the larger the space, larger survivor spaces allow short lived objects a longer time period to die in the young generation.
• -XX:TargetSurvivorRatio=90 allows 90% of the survivor spaces to be occupied instead of the default 50%, allowing better utilization of the survivor space memory.
• Increasing -XX:MaxTenuringThreshold allows short lived objects a longer time period to die in the young generation (and hence, avoid promotion); but minor GC times can increase due to additional objects to copy; has no effect if the objects are getting promoted due to lack of space in the survivor spaces.

http://java.sun.com/developer/JDCTechTips/2005/tt1214.html#2
Deques (double ended queues) (Page last updated December 2005, Added 2005-12-30, Author John Zukowski, Publisher Sun). Tips:

• ArrayDeque is has no capacity restrictionsand offers a wraparound index implementation to keep performance at its peak.
• Deque.offer*() methods allow you to try and add an element to a deque without throwing an exception if the deque is full and unable to grow.
• Deque.poll*() methods allow you to try and remove an element from a deque without throwing an exception if the deque is empty.

http://javaboutique.internet.com/tutorials/tuning/
Performance Tuning with JSP and Servlets (Page last updated December 2005, Added 2005-12-30, Author Sridhar M S, Publisher JavaBoutique). Tips:

• The include directive is better and faster than the include action, because the page does not get compiled during run-time and hence does not require any server side processing.
• Use the smallest scope for a bean (scope="request|page|session|application", default is page) as this will minimize the lifetime of objects.
• Use the init() method of HttpServlet for data caching.
• Disable auto-reloading of servlets and JSPs.
• If you don't need a session for a page, use <%@ page session="false"%> to disable the creation of an HttpSession.
• Set a low session time-out.
• Explicitly call HttpSession.invalidate() when you know you have finished with the session.
• Use gzip cCompression if(encoding.indexOf("gzip") != -1){httpServletResponse.setHeader("Content-Encoding" , "gzip");out = new GZIPOutputStream(httpServletResponse.getOutputStream());}

http://www.javaworld.com/javaworld/jw-12-2005/jw-1226-jee.html
Improve availability in Java enterprise applications (Page last updated December 2005, Added 2005-12-30, Author Ajay Raina, John Jimenez, Govind Nishar, Ning Yan, Publisher JavaWorld). Tips:

• Availability in the infrastructure is typically achieved by building redundancies at all levels.
• Certain application design choices that would work well in a simple environment may not be as effective in a highly available environment.
• High availability hosting environment is characterised by: No single point of failure; and Failover of any point of failure.
• Use read-only JVM caches or real-time synchronized caches to ensure failover leaves data consistent.
• To enable failover, replicate session data in real time.
• Implement failover of communications so that alternative source/destinations can be used transparently to the application.
• Consider the test scenarios like these and similar: Does your application handle a shut down of one of the databases? shutdown of any other failover component? etc.
• Automate the reload of all externalized resources, without requiring shutting down or restarting the application.
• A resource manager should reload resources to a running system: by polling for changes; by being triggered in some way from externally; reloads should be thread-safe.
• Monitor the application's health in some way.

http://jdj.sys-con.com/read/163230.htm
Managing Java Performance (Page last updated December 2005, Added 2005-12-30, Author John Reichard, Publisher JDJ). Tips:

• to develop, deploy and maintain high-performing applications, organizations must integrate performance into their application life cycles.
• Performance-related life-cycle activities should include: Performance objectives and requirements definition; Architecture and design reviews for performance; Performance testing, tuning, and optimization in development; Test case and test suite timing analysis in QA; Preproduction load testing and performance baselining; Application service-level specification and monitoring; Production-level application performance management.
• Define application needs and objectives in terms of business processes and functions. For example: "maximum response time of two seconds for a customer lookup transaction"; "must be able to support 1,200 internal users and up to 30,000 external users simultaneously"; or "must be able to process 85,000 point-of-sale transactions per minute from 2,100 retail locations."
• If a three-tier architecture is proposed, the requirement for a two-second customer lookup transaction must be broken down into design criteria for the presentation layer, business logic, and database access.
• Performance tuning an application is a good development practice for ensuring that code executes quickly with no significant bottlenecks.
• Memory profiling an application in development is effective for ensuring correct and efficient use of memory resources.
• Thread synchronization analysis can help optimize runtime performance and avoid potentially fatal thread deadlocks and race conditions.
• Without a reasonable set of guidelines, it is possible to spend too much time tuning and optimizing during the development cycle.
• In a three-tier J2EE application, all of the presentation-layer components can and should be tuned with precision by the time the code is feature-complete.
• Applications that are exposed as Web services need additional optimization during development, particularly in the marshaling, unmarshaling, and transformation of XML.
• Typical QA wall clock timing easily generate false or misleading results due to system and environmental variability.
• A proper solution for accurate timing of code under test is to combine a performance analysis tool with an automated testing solution to produce highly accurate and repeatable timing data.
• Load testing a feature-complete application in a preproduction environment is one of the best predictors of real-world application performance.
• Your production application monitoring tools and procedures should: Measure end-user experience of application availability and response times; Prioritize performance issues based on their business impact; Systematically resolve problems via accurate analysis of performance issues; Monitor and analyze application performance automatically and continuously across the client, network, server, and database tiers; Capture performance analysis information at the time of service-level exceptions; Integrate all monitoring and measurements into useful, management-level reports that expedite service and support, and reduce confusion and delay.

Jack Shirazi Back to newsletter 061 contents