Home > Articles > Programming > Java

Performance Advice for Beginning Java Programmers

Charlie Hunt, author of Java Performance LiveLessons, offers advice on how to be successful at meeting a Java application's performance expectations.
Like this article? We recommend

Over the years there have been countless times when I have been asked to offer performance tuning advice to Java programmers. Given the application they are developing, folks want to know how they can ensure meeting the application’s performance needs, as opposed to learning how to do Java performance tuning. In this article, I offer my advice on how to be successful at meeting an application’s performance expectations.


Many times it is the case that when a Java application is developed, or an existing one is enhanced with new feature capability, it is not able to meet performance expectations of those who use the application or have some stake in the application’s performance. There are cases where post development activities such as extensive JVM tuning or application performance tuning efforts are able to meet performance needs. However, these fire drills can be mitigated through proactive activities prior to or even during the implementation phase of the application or the enhancement.

In the following sections, you will learn how to avoid those last minute performance tuning fire drills.

Importance of Performance Requirements

For every Java application or for any enhancement to an existing Java application, there are always some front-end requirements that need to be defined and met. Most of the time these requirements are specific about the functional operations of the application or the enhancement. A good example of a functional requirement is the capabilities of the newly introduced feature. Often there is no mention of performance requirements, or the performance goals are incomplete or ambiguous. Moreover, the application’s performance measurement metrics, the description of the measurement of the metrics themselves, and even the performance qualification and performance testing descriptions are rarely discussed or documented. Any performance engineer will say performance requirements are very important to capture in the requirements phase of development. And the more detailed the requirements, the better.

The next several sections present questions that performance engineers commonly ask regarding the desired application performance, thus leading to better requirements and to an improved opportunity to meeting those performance requirements.

Key Performance Goals

When capturing performance requirements, there are times when the metrics (response time, throughput, footprint) are already summarized. So, with that as a starting point, ask further questions. This section describes those questions and areas that can form better performance requirements.

First, performance of an application should be expressed in the form of a requirement for each of following performance attributes:

  • Throughput performance (how quickly can the application do some well defined unit of work?)
  • Latency performance (how long does it take from the time of an input stimulus until a response is received?)
  • Memory footprint (how much memory does the application need?)

At a very minimum, answers to these questions should be known prior to transitioning into the implementation phase.

Throughput Performance

For a throughput performance requirement, you should expect to capture the essence of the requirements; something along the lines of “the application shall perform ‘X’ number of operations or transactions per some unit of time.” An example requirement of this form is “the application shall perform 120 transactions per second.” This is not necessarily a complete throughput requirement, but it is a good starting place.

Latency Performance

Similar to the throughput performance requirement, you should first try to capture the essence for a latency performance requirement. It could be along the lines of “the application shall respond to some type of external stimulus, or some kind of input, and return a response within a specified unit of time.” An example of a latency performance requirement is “the application shall produce a response to an incoming request within 50 milliseconds.” As was the case with the example throughput requirement, this is not necessarily a complete latency performance requirement.

Memory Footprint

Likewise for memory footprint requirements, a memory footprint requirement is one that communicates the amount of memory the application is allowed to use. An example of a memory footprint, or memory usage requirement, is the application shall not use more than 10 GB of Java heap. Again, for Java, this requirement leaves quite a large room for fine tuning the memory usage.

Clarifying Throughput Performance

Once you have a throughput performance goal for the application or feature under development, there are additional questions to ask. These questions are targeted toward fine tuning the throughput requirement and will help improve the chances of the application meeting or exceeding its performance expectations. Some additional questions to consider asking include:

  1. Should the performance goal be considered the peak performance goal? Or is the performance goal a throughput goal the application shall maintain at all times?
  2. What is the maximum load the application is expected to take on?For example, what is the expected number of concurrent or active users, or concurrent or active transactions?
  3. If load taken on by the application exceeds the expected load, can the throughput fall below the performance goal?
  4. If it can fall below the performance goal, how long can it fall below the performance goal? Or how long is the application expected to meet performance goals at peak, or at load levels higher than expected levels?
  5. In terms of CPU utilization, is there an expected amount of CPU, or a limit on the amount of CPU that can be used by the application at various load levels?
  6. If there is a limit of CPU consumption, can that amount of CPU be exceeded, and for how long is it acceptable to exceed that amount?
  7. How will throughput of the application be measured? And where will the computation of throughput be done?

The last question is a very important one. Getting clarity on how and where throughput will be measured can be very crucial to meeting the throughput performance goal. There may be differences amongst those who have a stake in the performance as to how and where throughput is measured. There might also be differences in opinions on the other questions listed here, too.

Clarifying Latency or Response Time Performance

Similar to the throughput performance goal, latency or response time performance goals should be documented and well understood. The first step is to define a response time goal or requirement as described earlier. A goal that simply captures an expected response time for requests is a good starting place. Once that initial performance goal is established, additional probing questions can be asked to further clarify what is expected in terms of response time and latency. Additional questions include:

  1. Is the response time goal a worst-case response time goal that should never be exceeded?
  2. Is the response time goal an average response time goal? Is it a percentile such as a 90th percentile, 95th percentile or 99th percentile response time?
  3. Can the response time goal ever be exceeded?
  4. If so, by how much can it be exceeded?
  5. And for how long can it be exceeded?
  6. How is response time going to be measured?
  7. Where will response time be measured?

The last two are very important questions and should be explored in detail. For example, if there is an external load driver program involved, it may have built-in facilities to measure response time latency. Should you decide to use those built-in facilities, if you have access to the source code, take a look at how the response time is computed and reported. As mentioned earlier, be leery of response times that report averages and standard deviations. Response times are not normally distributed. Hence, trying to use statistical methods that assume normally distributed data will lead to improper conclusions.

Ideally you should collect the response time data for each and every individual request and response. Then, plot the data and order it in a way that you can see percentiles of the response times including worst-case response time.

If response times are measured internally in the server application, you should immediately be suspicious if you are attempting to report response times as observed by someone who uses the application metrics as offered by the server application and not the system-wide or client-side metrics. Let’s delve deeper. Consider for the moment that you are interacting with the server application. You issue a request to the application. But before the request is fully read by the server application, suppose a garbage collection event occurs, which takes two seconds. Because the request you have issued has not been fully read by the application, the incoming request timestamp has not been computed by the application. As a result, the request you issued just experienced a two-second delay that will not be reported in response time latency. Hence, when response time latency is measured within a server, you should not use the data to represent response time latency as seen by a client application interacting with the server application. There can be queuing that occurs between the client and server that is not measured in the server’s response time computation. The response time measured within a server is really measuring the latency from the arrival timestamp (after the incoming request has been read) all the way through until the response timestamp is taken (typically after the transaction completes and a response to the request is written).

Although it was not mentioned earlier when discussing throughput, much of what is said in this section with respect to how response time latency should be measured is applicable to measuring throughput as well.

Clarifying Memory Footprint or Memory Usage

Similar to the fine tuning of the throughput and latency requirements, memory footprint requirements, or the amount of memory the application can use, should also be documented and well understood. As in the cases of throughput and latency, the first step is to define a memory footprint goal. In other words, how much memory is expected to be used or consumed? A goal that simply captures an expected Java heap usage is a good starting place. Once that initial goal is established, you can ask additional probing questions to further clarify what is expected. These additional questions could include:

  1. Does the requirement of the expected amount of memory to be used only include the amount of Java heap that it is expected to be used? Or does that amount also include native memory used by the application or the JVM?
  2. Can the amount of expected memory consumption never be exceeded?
  3. If expect memory consumption can be exceeded, then by how much can it be exceeded?
  4. And for how long can it be exceeded?
  5. How is memory consumption going to be measured? Will the metric include the resident memory size of the JVM process as reported by the operating system? Will it also include the amount of live data in the Java heap?
  6. When will memory consumption be measured? Will it be measured when the application is idle? When the application is running at steady state? When it is under peak load?

Asking these kinds of questions will proactively intercept some potential misunderstandings from various folks who have a stake in the application.


When developing a new application or enhancing an existing one, the chances of meeting its performance goals can greatly improve by investing some additional time to refine requirements for throughput, response time latency, and memory footprint requirements. By pulling in folks who have a stake in the application or the enhancement, and having discussions that probe deeper into the performance goals for the application or the enhancement, you will better communicate to everyone involved in the performance requirements, how performance will be measured, and how performance will be tested. In short, the more detailed the requirements for each of the three performance attributes, (throughput, latency and memory footprint), the better the clarity of the performance requirements document.

Also invest in developing a performance test plan at the same time as answers to the probing questions on throughput, latency and footprint are discussed. Then share the test plan with the folks who have a stake in the application. Include in the test plan how the performance test plan will be executed and how each of the performance metrics will be measured. You will often find that there will be a disparity amongst folks’ interpretation of a performance requirement, how performance will be measured, and how the performance test will be executed. Getting clarification on these at requirements definition time will greatly increase the chances of everyone being happy when the development is complete and the application is deployed.


I would like to thank Monica Beckwith for her insightful review and comments!

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020