Performance « Design « Java Articles

Java achieves architectural independence by compiling its source code into its own intermediate representation, not the typical machine-specific op-codes of a particular hardware platform. The intermediate representation is called byte code. The byte code produced is designed to run in a stack-based architecture. Unlike the assembly-language representation of most modern machines that are register based, a stack-based machine has no registers. The JVM is an abstract computer architecture based on a dynamic stack that provides operations to push, pop, and manipulate data. The JVM's main function is to load classfiles and execute the resulting byte codes.

This article presents a ten point plan for ensuring that your application will perform adequately. It isn't restricted to Java (point 2 includes extra information for Java projects). I'm very grateful to Alex Rossi of Accenture for his valuable input in discussions about performance planning.

One question that frequently reaches the Java Performance Tuning site asks about the performance differences between these List classes. In this article I'll take a look at the performance differences between the LinkedList implementation and the Vector/ArrayList implementations.

In my book Java Performance Tuning, I considered efficient ways to convert numbers to strings, and I provided conversion algorithms that are faster than those released with the Java SDK (up to and including version 1.3). In this article, I'll consider how to format doubles using a variation of that conversion algorithm, and show that the conversion of numbers with formatting can be faster than the original unformatted conversion.

Eric D. Friedman wrote a high performance set of collections called Trove. Trove allows you to plug in their versions of certain containers (HashMap, HashSet, LinkedList), and use them just like you did with the standard versions. There are also ways to utilize primitive collections to gain even more performance. Don't you love open source?

The business people, however, wanted to play with this and didn't want to have to rely on a pool of Java programmers (boo), so we wrote a GUI a few years ago. In keeping with our love of high performance, the GUI generated code and the code can be compiled and jar'd with the binding and rules code.

Learn all about the best practices for performance engineering in J2EE Web applications. This chapter, excerpted from Wiley's "J2EE Best Practices: Java Design Patterns, Automation, and Performance", looks at the role of performance in the development process and discusses a number of techniques to optimize the architecture, design and code in your J2EE application components such as Entity Beans, Message-Driven Beans, and when processing XML.

Pro Java EE 5 Peformance Management and Optimization features proven methodology to guarantee top-performing Java EE 5 applications and explains how to measure performance in your specific environment. The book details performance integration points throughout the development and deployment lifecycles. For QA and preproduction stages, author Steven Haines guides the reader through testing and deploying Java EE 5 applications with a focus on assessing capacity and discovering saturation points. Haines also defines the concept and application of wait-based tuning.

In response, a growing number of teams are embracing Continuous Integration. This best practice advocates the habit of conducting code builds at least once - and if possible, several times - every day. Continuous Integration explicitly recognizes that development teams struggle with the odious task of ferreting out code conflicts and bugs each time the group contributes new code into a central repository. By maintaining shorter time frames between builds, teams find it easier to test code. They also can take advantage of natural breaks in which to identify and fix conflicts and bugs while the amount of fresh code is still manageable. Like so many best practices, Continuous Integration is brilliant in its simplicity, which has unquestionably helped with its adoption. And even busy Java programmers, many of whom resist procedural changes simply because they are initially disruptive, quickly detect the benefits of this developer-friendly approach to engineering software.

Performance improvements made based on these raw measurements should improve general server performance, however improving only code involved in the application hotspot(s) can be the most effective as time spent in other parts of the application are filtered out.

While the Java server was coming to be defined in the late '90s as a general purpose distributed server based around J2EE and implementing EJB containers, Grid computing was making its way out of the scientific world into commercial implementations. In recent years, a variety of methods that are somewhat 'grid like' have been making there way into the world of Java-centric computing. In different ways they address some limitations that J2EE exhibits when it is pushed higher into the realm of high-performance computing.

In response to the need for a realistic benchmark for J2EE servers, the ECperf benchmark and kit has been developed by the Java Community, through the Java Community Process. ECperf is the standard benchmark for J2EE Enterprise Application Servers. This article provides 8 reasons why ECperf is the right way to evaluate the performance of J2EE servers. It is an excerpt from a larger whitepaper on the subject provided by The Middleware Company, available in PDF .

Performance is important. For the types of large-scale multi-user applications that Java is commonly used to develop, it can be vital. Unfortunately, identifying performance problems before they occur is very difficult and fixing them afterwards is usually very costly. In this article I outline an approach to boosting the performance of Java code using the embedded compiler library Janino. It can be applied to some performance problems even after all other approaches have been exhausted.

In this article, we presented different performance improvement tips. The first question to ask when developing an XML-based application is "Should it be XML based?" If the answer is yes, then a sound and balanced architecture has to be designed, an architecture which only relies on XML for what it is good at: open inter-application communications, configuration descriptions, information sharing, or any domain for which a public XML schema may exist. It may not be the solution of choice for unexposed interfaces or for exchanges between components which should be otherwise tightly coupled. Should XML processing be just a pre or post-processing stage of the business logic or should it make sense for the application to have its core data structure represented as documents, the developer will have to choose between the different APIs and implementations considering not only their functionalities and their ease of use, but also their performance. Ultimately, Java XML-based applications are developed in Java, therefore any Java performance improvement rule will apply as well, especially, those regarding string processing and object creation.

Based on the Java Developer Connection presentation, Tips and Tricks for Java Developers given at JavaOne 1998, this article offers a variety of performance tuning and firewall tunneling techniques used by the Java Developer Connection (JDC) engineering team. These techniques are illustrated by source code that you can download.

This article discusses PerfAnal, a GUI-based tool for analyzing the performance of applications on the Java 2 Platform. You can use PerfAnal to identify performance problems in your code and locate code that needs tuning.

Bio: A Java Champion since September 2005, Kirk Pepperdine is a primary contributor to javaperformancetuning.com, which is widely regarded as the premier site for Java performance tuning information, and is the coauthor of Ant Developer's Handbook. He has been heavily involved in application performance since the beginning of his programming career and has tuned applications in a variety of languages: Cray Assembler, C, Smalltalk, and, since 1996, Java technology. He has also worked on building middleware for distributed applications. Pepperdine began his career in biochemical engineering and has researched high-performance liquid chromatography for Ottawa University and the National Research Council of Canada. He worked with Cray supercomputers at the Canadian Department of Defense, as a consultant at Florida Power & Light, and has been a senior consultant with GemStone Systems. He is currently an independent consultant and an editor at TheServerSide.com.

The GC Portal enables analysis and performance tuning of Java applications from a garbage collection (GC) perspective by mining the verbose:gc logs generated by the JVM. GC Portal is a one-stop page for GC issues and includes an extensive collection of whitepapers, case studies and other material. The Portal is intended to be used with HotSpot JVM from Sun Microsystems, distributed as part of Java 2, Standard Edition (J2SE). Use of the GC Portal enables developers to model application and JVM behaviors from a GC perspective. This article introduces the design and features of the GC Portal, to enable developers to use it as a tool for analyzing and tuning GC.

Last week I attended Mark Matthew's "Performance Tuning J2EE Applications deployed on MySQL" at the MySQL Conference (see Anthony's Review). Mark's presentation had a lot of tips and tricks with the MySQL JDBC Driver. I asked him to send me a copy - and he did. Below are a number of tips that you might be able to use in your apps. One thing that Mark forgot to mention (he did later over beers) was that MOST apps (with less than 50 tables) won't need this stuff. You should probably only performance tune your server (or JVM) if you *really* think it's not your app or database. The database, and its indexes, is the first thing to check for slow performance.

Let's take a look at what can be done to improve performance of CMP in Weblogic by enabling more aggressive than default caching strategies.

Bill Venners: So in this case it's not easier to change for adding new functionality, but for enhancing performance of existing functionality.

The third installment of the Artima JavaOne interview series visits with Steven Harris, Vice President of Oracle's Java Platform Group. In this interview, Harris challenges developers to re-think how they architect enterprise applications with a view to ensuring the long-term performance requirements of an application.

Have an opinion about the performance tuning techniques presented in this article? Discuss this article in the Articles Forum topic, Analyzing a Web-Based Performance Problem.

While the Astros team had no problem getting so many people to participate in their load test effort, testing your software the same way is unfathomable. It is not cost effective to do an exact production simulation load test on a pre-production or test environment, which has created a market for numerous software tools that perform simulated load tests. All the testing tools basically run automated tests, during which you can collect other vital operating system information to calculate your software's performance capacity.

In its most basic form, a coupling can be thought of as all of the references needed by a single object. By using the Java compiler, you can very easily see the results of coupling. Select an application, clean out its classes directory, and then pick a single source file and compile it from the command line. You'll see a set of class files appear in the target directory. If you're thinking "so what?", consider that each of these classes represents an entity that the original class is dependent upon, and a change in any of these classes could result in a bug appearing in the original class.

I promised you an article about benchmarks and performance measurement, but so far all you've gotten is a history lesson and a rehash of Sun's HotSpot white papers. The reason for this lengthy detour is that without understanding the dynamic compilation process, it's almost impossible to correctly write or interpret performance tests for Java classes. (Even with a deep understanding of dynamic compilation and JVM optimization, it's still pretty hard.)

When we ran our initial program, it failed to find any solutions in a reasonable amount of time. Let's try again with our improved algorithm and island-detection pruning. The code for this version of the program can be found in the package meteor.algorithm. When we launch it using java meteor.algorithm.Solver, we almost immediately see solutions popping up. Our test computer calculates all 2,098 possible solutions in 157 seconds. So we've made a gigantic performance improvement: from several hours per solution to less than one-tenth of a second. That's roughly 400,000 times as fast! As an aside, the initial algorithm combined with island detection pruning completes in 6,363 seconds. So the pruning optimization causes a 10,000-fold speedup, while the fill-up algorithm generates an extra 40-fold speedup. It clearly pays off to spend some time studying your algorithms and attempting to optimize them.

pureQuery introduces two new programming styles for SQL execution: the inline method programming style and the annotated method programming style. These styles simplify Java data access development by providing out-of-the-box support for storing and retrieving objects, such as Java beans and maps, to and from the database. The inline programming style also supports the use of customized user-defined result processing.

One of the most common questions asked on the performance lists is: "Is there a tool that can help me to stress test my J2EE application?" Before we can answer that, let's ask ourselves: what is stress testing, and why do these developers want to do it? (I'm sure quite a few of you have been in the stressful situation of absolutely needing to have your tests finished by yesterday, but that's not what we're talking about here.) Stress testing is aimed at discovering under what conditions your application's performance becomes unacceptable. You do this by changing the application inputs to place a heavier and heavier load on the application, measuring how performance changes with the variation in those inputs. This activity is also called load testing, though load testing usually describes a specific type of stress testing -- increasing the number of users to stress test your application.

Enhancements to the shared classes infrastructure, first introduced in Version 5 of the IBM JRE for the Java platform SE, improve performance for your Java applications in the areas of startup and memory footprint. In this article, we review the changes and provide examples demonstrating the benefits using Eclipse and Apache Tomcat as our client-and server-side operating environment. We provide some installation instructions so that you can try things out for yourself, but you should be familiar with both applications, as well as with IBM's class sharing. If you are not familiar with IBM's shared classes feature, we recommend that you start with the article "Java Technology, IBM style: Class sharing," which explains the basic concepts involved.

Applying the concepts in Part 1 can open new opportunities for code reuse. We'll start by presenting ways you can use Hibernate and polymorphism to incorporate behavior in the domain model. Next, we'll build on Part 1's discussion of the generic DAO. Once you incorporate and use a generic DAO in an application, you'll encounter more potential operations that are common across applications. We'll show how you can reduce code by incorporating paging of data and querying in the generic DAO. We finish with strategies for enhancing performance with the domain model. Without these strategies, incorrectly configured associations in the domain model can cause thousands of extra queries to be executed or can waste resources by retrieving records that are not needed.

The EWLM Report Data Analyzer fills this gap by providing a simple tooling to present the performance interpretation elements in a graphical way. Its purpose is to avoid the need to develop complex utilities before being able to start mining into performance data provided by EWLM. As such, using it should let you harness EWLM for performance data analysis and on understanding the figures and the interpretation aspect without losing time on the technical side.

In Part 1 and Part 2 of this three-article series, I presented techniques and patterns for monitoring Java applications, with a focus on the JVM and the application classes. In this final installment, I widen the focus to present techniques for gathering performance and availability data from the application's dependencies, such as the underlying operating system, the network, or the application's backing operational database. I'll conclude with a discussion of gathered-data management patterns, and methods for data reporting and visualization.

Although no Usenet discussion groups are dedicated purely to Java performance, there are many discussions about performance tuning and optimization. A good portion of these discussions rely on results obtained from micro performance benchmarks, so we're also going to talk about some of the benefits and pitfalls of microbenchmarking in this month's column.

Part 1 of this series addressed CPU, I/O, and threading issues as some of the pieces of the performance puzzle in Eclipse-based rich-client applications. Memory leaks are another possible cause of performance problems. This article explains how to monitor your application's memory usage, describes some of the kinds of leaks you'll experience when developing rich-client applications, and shares techniques for solving them.

This article focuses on the annotated method coding style, which evolved similarly to the inline coding style but with the additional goal of maximizing configurability and security for the resulting pureQuery application. Annotated method style is designed specifically to support both dynamic and static database access. It was developed in response to customer demand for a named query programming interface for data access that was similar to Java Persistence API (JPA) -- only simpler, quicker to code, and capable of supporting static execution when required.

In a typical application, at least two database calls would be required to generate this page: one to fetch all the products to show in the main catalog and another to fetch the most viewed products for highlighting on the right side of the screen. With pureQuery’s query over collections, you can improve your application performance by reusing the first result set which contains all the products for the selected category. pureQuery is able to execute a SQL statement on this existing result set, filtering only the products that have the status of bestseller.

As you know from Part 1 of this three-article series, it's important to monitor the availability and performance of Java applications and their dependencies in production to ensure problem detection and accelerate diagnosis and triage. Source-code-level instrumentation of classes you want to monitor can have the advantages I discuss in Part 1, but it's frequently not permissible or practical. For example, many of your interesting monitoring points might be in third-party components for which you don't have the source code. Here in Part 2, I focus on methods of instrumenting Java classes and resources without modifying the original source code.

Well, that's a nice bit of history, but what do you get from Trove? Lots and lots of efficient collections. Apart from many of those 81 versions of HashMap (for instance, TIntIntHashMap, TIntObjectHashMap, and so on), List and Set classes exist that can store primitives (for instance, TIntHashSet, TFloatArrayList, and so on). The architecture is even set up to allow you to plug in your own hashing strategy so that you can apply potentially more efficient (or more flexible) hashing to your own data sets. Of course, there is a performance tradeoff in supporting flexible hashing -- when a hash map is a bottleneck, it is often because it is being used intensely, which typically means that the hash function is being called many, many times. So every extra little bit of overhead in your hash function can be a bottleneck. (Having said that, if the hashing function is simple enough, the JIT compiler may be able to inline it, resulting in no extra overhead while still supporting a flexible hashing strategy -- a free lunch!)

Robert Berry joined IBM in 1987, a few years after receiving a Ph.D. in Computer Sciences from the University of Texas in Austin. He has been a part of performance-related research and development from his first years with the company, and became actively involved with Java performance around the time the Java language first emerged. He was appointed an IBM Distinguished Engineer in 2000, and is currently on assignment at IBM's Software Development Laboratory in Hursley, England, helping to grow the Java performance team. In this interview, I asked him about the process of refining Java performance, the history of performance improvements, and some of the current, hot areas of Java performance research at IBM. (Also, be sure to check out the sidebar "Evolving performance of the Java Virtual Machine," a timeline of performance improvements.)

While programming decisions -- such as a sub-optimal choice of algorithm or data representation, failure to reuse the results of previous calculations, or poor resource management -- are usually deemed to be the proximate cause of a performance problem, most performance problems also have a deeper cause: the failure to integrate performance management, goals, and measurement into the development process in the first place.

You might have heard of the 90/10 rule: 90% of the time is spent in executing 10% of the code. Optimizing 90% of the code will have little impact on overall performance. You need to pinpoint and improve performance bottlenecks -- the 10% of the code where 90% of the execution time is spent. IBM® Rational® Application Developer (IRAD) can help you in achieving that goal. It allows you to collect execution-time data for your Java? application with varying degrees of details, and provides effective visualization of the data so that you can quickly identify performance bottlenecks.

Last month I showed how you could use the AspectWerkz framework to implement a basic performance tracing aspect. This month I'm going to take this aspect further, first adding some convenience features and then applying it in the analysis of a complex real world body of code -- the Apache Axis Web services framework. You'll see both the benefits and the limitations of my aspect-oriented approach to performance tracing, and end up with what I see as the general usefulness of aspect-oriented programming (AOP) to logging and tracing in general.

Wait leaks are certainly a bug, but what we want to look at here is not the solution to the problem, but a way to identify the problem. In a complex application with tens or hundreds of threads, it can be difficult to spot a wait leak unless you have seen the symptoms before. Unlike a deadlock, there is no obvious telltale evidence like two threads waiting on each other's locked monitors. Instead, there are just lots of threads sitting in Object.wait() calls, which can otherwise be quite normal for many applications.

But even the best-architected applications will have performance bottlenecks, and you need tools and techniques for assessing and addressing them. Now you know how to measure RCP application performance, determine whether slowdowns are due to CPU or I/O bottlenecks, use some instrumentation techniques, keep the UI thread responsive, sidestep thread misuse by using Jobs, and improve startup performance. In the next installment, I'll share some techniques for understanding memory usage and chasing down memory leaks.

When a problem situation occurs, the objective is to collect as much information as possible that will either identify the cause of the issue, or provide a direction in understanding the cause. The issue could be the operating system (kernel/library), the JVM ( or JIT), other native code, or the Java application code. This section includes a collection of commands that will collect data from each area. Most of the commands listed must be executed as the root user.

Once the newMap has been assigned to currentMap, the contents never change. Effectively, the HashMap is immutable. This allows multiple get operations to run in parallel, which can be a major performance boost. According to Brian Goetz in section 3.5.4 of Java Concurrency in Practice (see Resources), "safely published effectively immutable objects can be used without additional synchronization." The safe publication is a result of the volatile reference.

Pop quiz: Which language boasts faster raw allocation performance, the Java language, or C/C++? The answer may surprise you -- allocation in modern JVMs is far faster than the best performing malloc implementations. The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources). And allocation performance is not a trivial component of overall performance -- benchmarks show that many real-world C and C++ programs, such as Perl and Ghostscript, spend 20 to 30 percent of their total execution time in malloc and free -- far more than the allocation and garbage collection overhead of a healthy Java application (Zorn; see Resources).

The benefits of being able to test Web-oriented applications under real-life stresses and situations should be evident at this point in the Internet revolution.

So what do you do if you have unintentional object retention? Well, first you need to determine which objects are being unintentionally retained, and then you need to find which objects are referencing them. Then you've got to figure out where they should be released. The easiest way to identify these objects is by using a profiler with the abilities to snapshot the heap, compare object numbers between snapshots, track objects, find back references to objects, and force garbage collections. With such a profiler, the procedure to follow is relatively straightforward:

To help DB2 DBAs avoid performance fires and achieve high performance on their own, I've summarized a troubleshooting process for our clients, customers, and fellow DB2 professionals. The top 10 performance tips for e-business OLTP applications in DB2 UDB for Unix, Windows, and OS/2 environments are explained in detail below -- and summarized at the end of this article.

This month, I'm going to look at several general statements about Java performance tuning that share many characteristics of urban legends. Some of them have some basis in fact, but all have been inappropriately promoted to the status of performance gospel.

This past month we spent a lot of time down at the JavaRanch's Big Moose Saloon to see what kind of performance questions the JavaRanch greenhorns are asking. Most are about J2SE and development procedures -- questions about the Java language, core classes, and how to improve their development processes.

So, as the example in Listing 3 shows, we cannot expect static compilers to perform transformation of tail recursion on Java code while preserving the semantics of the language. Instead, we must rely on dynamic compilation by the JIT. Depending on the JVM, the JIT may or may not do this.

This article covered the basic concept of how classes are dynamically loaded and how this relates to both performance and security. Dynamically loaded classes provide a very substantial performance boost to application development. However, as is often the case, there are some downsides as well; in this case, some security concerns need to be addressed.

Probably the most important aspect of performance tuning in integration or staging environments is ensuring that you are accurately reproducing the behavior of your users. This is referred to as balanced representative load testing. Each load scenario that you play against your environment needs to represent a real-world user interaction with your application, complete with accurate think times (that is, the wait time between requests). Furthermore, these representative actions must be balanced according to their observed percentage of occurrence.

However, note that the most recently released wave of Java rapid application development (RAD) tools is a big improvement over the first set of Java development tools. Other necessary complementary products such as testing tools are starting to become more prevalent as well. The lack of mature tools is not preventing corporations from using Java products, according to the survey. While 37% of respondents indicate they will wait until mature tools have gained wide industry acceptance, 42% are not waiting at all.

Learn the proven performance tuning methodology that I used to successfully tune the performance of Enterprise Java environments for companies ranging from small 10-person development teams to large-scale Fortune 500 companies.