Background Information:

The Swing library provides graphical user interface components for Java SE applications. Multiple threads are used by the Swing library and the NetBeans Profiler is a powerful tool that can be used to understand the amount of processing that occurs on each thread. This understanding can be used to solve performance problems.

Steps to follow:

1. Choose File > Open Project. Navigate to the <tutorial_root>/netbeansprofiler/exercises folder. Select the exercise1 folder and click the Open Project Folder button.
2. In the Projects window right-click the exercise1 entry and choose Clean and Build Project. Then right-click the exercise1 entry again and choose Run Project. The program displays its window, shown below.

   

3. The Seconds Before Notification should be set to 30.
4. Click the Start! button. Notice that it does not redraw correctly.
5. Click the Exit button. Notice that it does not respond at all.
6. In order to see an additional problem, obstruct the view of the window by putting another window on top of part of it. When you move the other window away, notice that the sample application does not redraw its window correctly. An example is shown below.

   

7. After the thirty seconds eventually pass, the message box will be displayed, as shown below. Click the OK button on the message box.

   

8. The application window will begin to respond again. Click its Exit button to shut it down.
9. Choose Profile > Profile Main Project.
10. If a dialog box is displayed asking for permission to modify the project build script, click OK. An example is shown below.

    

11. The Select Profiling Task dialog is displayed. Click the large Monitor Application button.
12. The Enable Threads Monitoring checkbox should be checked.
13. Click the Run button.
14. If a dialog is displayed that informs you that the Profiler calibration information must first be collected, click its OK button. An example is shown below.

    

    The Profiler will display a dialog when calibration is complete; click its OK button. An example is shown below.

    

    To begin profiling, return to step 9, above.

15. The application starts and the IDE displays a Profiler Control Panel, as shown below.

    

16. The Profiler will display thread state in its main window; an example is below.

    

Color coding is used to display thread state.

• Green: the thread is either running or is ready to run.
• Purple: the thread is sleeping in Thread.sleep().
• Yellow: the thread is waiting in a call to Object.wait().
• Red: the thread is blocked while trying to enter a synchronized block or method.

17. Locate the sample Swing application's window (the NetBeans IDE window might be on top of it). Click the Start! button on the sample application and watch what happens to the thread labeled AWT-EventQueue-0. It will turn green and stay that way for a full thirty seconds, as shown in the sample below.

    

    This graph shows why the application is not responding. The thread labeled AWT-EventQueue-0 is the Event Dispatch Thread (EDT) used by Swing to process window events. In a well behaved Swing application, the EDT spends most of its time waiting and very little time running; it should only run for the brief amount of time required to dispatch an event. If the event handlers in the application do not return quickly, however, then the program will become unresponsive, just like in this example.

18. After the thirty seconds pass, the application's message box will be displayed. Locate that message box (the NetBeans IDE window might be on top of it) and click its OK button. Then click the sample application's Exit button to shut it down.
19. The Projects window shares space with the Profiler Control Panel; click the Projects tab to display the Projects window.
20. In the Projects window expand the exercise1 entry by double-clicking it and then expand the Source Packages and profilingthreads entries. Right click the DisplayForm.java entry and select Open.
21. In the Editor window that contains DisplayForm.java, uncomment the block of code that begins at line 132 and ends at line 157. Tip: If the editor is not configured to display line numbers, select View > Show Line Numbers.
22. In the Editor window that contains DisplayForm.java, remove (or comment out) the block of code that begins at line 122 and ends at line 128. It is shown highlighted in the illustration below.

    

23. Choose File > Save. You have just removed the code that was using the EDT improperly and replaced it with a more robust solution. The application should now be much more responsive.
24. Choose Build > Build Main Project (or press F11).
25. Choose Profile > Profile Main Project.
26. The Select Profiling Task dialog is displayed. Click the large Monitor Application button.
27. Make sure that Enable Threads Monitoring is checked.
28. Click the Run button.
29. When the sample program displays, click the Start! button. Notice how the Profiler's threads graph looks different this time; an example is below.

    

    The EDT is yellow and the thread created by the application, which is named "Our SwingWorker #1" is green. The EDT is not being used to do a time consuming task and as a result the buttons and other program controls remain responsive.

30. Click the Exit button on the sample program.
31. Right click the AWT-EventQueue-0 thread in the Profiler graph and then select Thread Details. The Profiler displays a pie chart showing time spent in each state; an example is below.

    

    This graph can help you determine if your program is spending the correct amount of time in each thread. The example shown is from after the code was repaired so it shows that the EDT spent most of its time waiting, which is exactly the behavior it should have.

32. In the Projects window right-click the exercise1 entry and then choose Close Project.

Summary:

In this exercise you learned how to use the Profiler to start an application and how to interpret the Profiler's thread information graphs in order to track down a performance problem in a Swing application.

return to the top

Background Information:

CPU performance problems are usually associated with specific features in an application. For example, in a reporting system one report might run more slowly than the others. Profiling just the portion of an application that is experiencing performance problems can dramatically reduce the overhead imposed by the profiler. In this exercise you will use the NetBeans Profiler to examine CPU usage in a web application. This sample web application is also used in exercise 3 to show how the Profiler can be used to find memory leaks.

Steps to follow:

1. Choose File > Open Project. Navigate to the <tutorial_root>/netbeansprofiler/exercises folder. Select the exercise2 folder and make sure Open As Main Project is checked. Click the Open Project Folder button.
2. Choose Build > Clean and Build Main Project from the menu.
3. Then choose Profile > Profile Main Project from the menu. If a dialog box is displayed asking for permission to modify the project build script, click OK.
4. Click the Analyze Performance button of the Select Profiling Task dialog.
5. Select the Part of Application radio button. Then click the Select button that is next to the Part of Application radio button. The Specify Root Methods window appears.
6. In the Specify Root Methods window, click the Add From Project... button to add a root method to profile. The Select Methods window appears.
7. In the Class Name text field, type demo.Performance and then press Enter.

   

8. Select the processRequest method by clicking on it in the list of Root Methods and then click the OK button. You have just selected demo.Performance.processRequest as the root method for performance analysis. This means that the demo.Performance.processRequest method and all methods that it calls, and all methods that they in turn call (and so on) will be profiled. Starting from demo.Performance.processRequest, the Profiler does analysis of the method call graph to determine which methods need profiling. Only those methods are profiled - the rest of your application will continue to run at full speed with no profiling overhead.
9. Click the OK button on the Specify Root Methods window.
10. In the Analyze Performance window, select Quick Filter from the Filter list and then click the "..." button next to the Quick Filter entry to specify methods that should not be profiled. The Set Quick Filter window appears. Verify that the Exclusive radio button is selected. Then enter org.apache into the Filter Value text field and click the OK button. All methods in the org.apache package (and child packages) will not be profiled - even if they are called from the root method that was selected. This reduces profiling overhead and filters out information that is not relevant.

    

11. In the Select Profiling Task window, click the Run button. If a dialog is displayed that asks for calibration information, click its OK button; after the Profiler displays a dialog indicating calibration is complete, click that dialog's OK button.
12. The IDE will start the bundled Tomcat server and display the web application's index.jsp page in a web browser window. At the same time, the Profiler will run in the background. Note: By default, the index.jsp page will be displayed in the browser window that has focus; you might want to open a separate browser window so that you can read these instructions while running the web application.
13. Since you have chosen demo.Performance.processRequest as a root method, you need to use the portion of the web application that causes that root method to run: In your web browser, click Performance Problems to go to the Performance demo page. On the Performance demo page, enter 123456 in the input text field. The optimized option should not be checked. Click the Submit Query button to calculate the largest prime number that is less than or equal to 123456.
14. It will take a couple of seconds before the response appears because the algorithm used for calculating the largest prime number has some performance problems. Also, the Profiler imposes some overhead when monitoring the performance of the processRequest method. After the result 123449 displays in your browser, click the button or choose Profile > Take Snapshot of Collected Results. Click the Combined tab at the bottom of the CPU usage snapshot. The Profiler displays the latest performance results, as illustrated below.

    

    The top window shows the complete method call graph beginning with the root method. The bottom window is a flatter depiction; it shows the Hot Spots in the application - those methods that took the most time to execute.

15. To examine and interpret the results, notice that the processRequest method ran for a total of 3745 milliseconds (ms). Note, however, that very little time was spent running the instructions of the processRequest method itself - the "self time" for processRequest is only 4.5 ms. The vast majority of the time was spent in methods called by processRequest. The Hot Spots displayed in the bottom window are sorted by "self time." By looking at that list you can see that the calculate method took up 97.8% of the execution time. This is not surprising given the amount of work the calculate method has been given to do.
16. To help you decide how your application can be optimized, the NetBeans Profiler helps you identify bottlenecks in your code that were not expected or that will prevent your application from scaling well. Click the calculate entry in the hot spot list to investigate exactly where the time went; this will update the call graph window so that calculate is shown. Since the calculate method does not call any other methods, right-click the calculate entry and choose Go To Source so that you can examine the source code. You will discover it uses a very inefficient algorithm that should be redesigned.
17. Choose Profile > Reset Collected Results to clear the Profiler's buffer. To compare calculate's runtime to an optimized algorithm calculate2, check the optimized option over in the web browser before clicking Submit Query. Wait for the result, then choose Profile > Take Snapshot of Collected Results again. Notice that the processRequest method ran for only 8.6ms and the calculate2 method needed only 6.49ms!

    

18. Note: The next exercise will pick up where this one left off, so do not close any windows.

Summary:

In this exercise you learned how to have the Profiler do performance analysis on a single method and all the methods it invokes.

return to the top

Steps to follow:

1. This exercise picks up where Exercise 2 left off, so be sure to follow the steps in Exercise 2.
2. Choose Profile > Modify Profiling from the menu.
3. In the Select Profiling Task dialog, click the large Monitor Application button.
4. Click the Run button. The IDE displays the Profiler Control Panel on the left. Click the button or choose Profile > View > Telemetry Overview. The NetBeans Profiler displays three graphs in the output window at the bottom, as illustrated below (click for full size).

   

   In the graph on the left the red shading indicates the allocated size of the JVM heap. The purple overlay indicates the amount of heap space actually in use. In the example above the allocated heap size at the last update was over 10 megabytes. Of that a little over 5 megabytes is actually being used to hold Java objects.

   The graph on the right shows the count of active threads in the JVM.

   The graph in the center shows two important heap statistics.

   • The blue line (which is at the very bottom of the graph in this example) is the percentage of execution time spent by the JVM doing garbage collection and is graphed against the y-axis on the right edge of the graph. Time spent by the JVM doing garbage collection is time that is not available for it to run your application. So if the blue line indicates a large percentage you may want to consider tuning the JVM by configuring a larger heap size (refer to the -Xmx parameter documentation) or perhaps switching to a different garbage collection algorithm.
   • The red line is surviving generations and is graphed against the y-axis scale on the left edge of the graph. The count of surviving generations is the number of different ages of all the Java objects on the JVM's heap, where "age" is defined as the number of garbage collections that an object has survived. When the value for surviving generations is low it indicates that most of the objects on the heap have been around about the same amount of time. If, however, the value for surviving generations is increasing at a high rate over time then it indicates your application is allocating new objects while maintaining references to many of the older objects it already allocated. If those older objects are in fact no longer being used by your application then your application is wasting (or "leaking") memory.

5. The Profiler can do detailed analysis (also referred to as instrumentation) of CPU performance or memory usage, but it cannot do both at the same time. To find out detailed information about the allocation and garbage collection of objects on the JVM's heap you will modify the Profiler's settings. Click the button or choose Profile > Modify Profiling.
6. Click the Analyze Memory Usage button.
7. Select the Record both object creation and garbage collection radio button.
8. Check the Record Stack Trace for Allocations check box.
9. Click the OK button.
10. Now that you have chosen to analyze memory usage you need to use the application in order to determine whether it is using memory efficiently. In your browser click the Back button until the application's index.jsp page is re-displayed. Then click the Memory Leak button to go to the MemoryLeak demo page.
11. On the MemoryLeak demo page, click Start Leaking.
12. Notice the spike in the Surviving Generations graph, as shown in the example below. This indicates a possible memory leak.

    

13. Choose Profile > View > Live Results. The Profiler will display a dynamic view of the objects allocated in the JVM heap. By default it is sorted by the number of bytes used by all instances of each class. Since a memory leak is suspected, click the Generations column to sort the display by the number of different object ages for each class. An example of the resulting display is shown below.

    

    The columns provide object allocation and memory usage information.

    • Allocated Objects (third column from the right) is the number of objects that the Profiler is monitoring. In this example, there are 23 instances of float[] that are being monitored. By default this number will be approximately ten percent of the objects actually allocated by your application. By monitoring only a subset of the created objects the Profiler is able to dramatically reduce the overhead it places on the JVM, which then allows your application to run at close to full speed.
    • Live Objects is the number of the Allocated Objects that are still on the JVM's heap and are therefore taking up memory.
    • The two Live Bytes columns show the amount of heap memory being used by the Live Objects. One column displays a graph, the other displays text.
    • The Avg. Age value is calculated using the Live Objects. The age of each object is the number of garbage collections that it has survived. The sum of the ages divided by the number of Live Objects is the Avg. Age.
    • The Generations value is calculated using the Live Objects. As with Avg. Age, the age of an object is the number of garbage collections it has survived. The Generations value is the number of different ages for the Live Objects.

14. As the program continues to run, the Profiler will update the display. Keep your eye on the entries for float[] and double[]. Notice how their generation values continue to increase. As a result, float[] and double[] continue to move higher in the list. Eventually they will be displayed at the top of the list, right under java.util.HashMap$Entry, which also has an increasing value for generations. As the application continues to run the generations value continues to increase for java.util.HashMap$Entry, float[], and double[], but not for any of the other classes. An example is shown below (click for full size).

    
    

15. To find out what is causing the generation values to keep increasing, choose Profile > Take Snapshot of Collected Results. Sort the resulting display by Generations. Right-click the entry for double[] and then choose Show Allocation Stack Traces. The Profiler displays all the methods that have allocated one or more double[] objects. An example is shown below (click for full size).

    

    Note that of the methods that have allocated double[] objects, only one method has created double[] objects that have a high generation value. That method is run(), in the aptly named demo.memoryleak.LeakThread class.

16. Right-click the entry for the run() method and choose Go To Source... The Profiler displays the source code, as shown below.

    

    Note that double[] and float[] objects are being allocated and then placed into a HashMap. They are never removed, however, which means the references held by the HashMap prevent the JVM from ever garbage collecting those objects. This is a pretty typical Java memory leak: objects are placed into a Map and then forgotten. Since the Map used in this example is a HashMap, the associated java.util.HashMap$Entry objects are also leaking.

17. Extra Credit: If you go back to the Memory Results tab and right-click the entry for java.util.HashMap$Entry and choose Show Allocation Stack Traces you will see a more interesting list of stack traces. Experiment with expanding nodes in the stack traces to see if you can easily find the call that was made by the run() method in the demo.memoryleak.LeakThread class.
18. End the profiling session by choosing Profile > Stop or click the button.
19. In the Projects window, select the exercise2 entry and then choose File > Close Project from the menu.

Summary:

In this exercise you learned how to use the Profiler to monitor the creation of objects by an application. You saw the types of information provided by the Profiler when an application has a memory leak.

return to the top

Background Information:

The NetBeans Profiler has specific support for profiling EJBs. This makes it easy to, for example, start a profiling session and then run a separate application that invokes the profiled EJBs. Since EJBs run in an application server, specific techniques are needed to minimize profiling overhead. Tools are also provided to help find the calls made to EJBs on separate threads.

Steps to follow:

1. Choose File > New Project.
2. Under Categories expand the entry for Samples. One of the entries under Samples is Enterprise - click the entry for Enterprise.
3. Under Projects click the entry for InterceptorStateless, then click the Next button.
4. For the Project Location field, specify a folder for the project files or accept the default. Click the Finish button.
5. The NetBeans IDE creates three projects from its catalog of sample projects. All three projects are displayed in the Projects window.

   

   InterceptorStateless-ejb is an EJB module project that produces a .jar file. InterceptorStateless-app-client is an enterprise application client project that produces a .jar file. InterceptorStateless is an enterprise application that produces an .ear file.
6. Right-click InterceptorStateless and choose Build Project from the context menu. Since InterceptorStateless is dependent on the other two projects, they will be built as well.
7. Right-click InterceptorStateless-ejb and choose Profile Project from the context menu. If a dialog box is displayed asking for a Java Platform to use, choose the default platform. If a dialog box is displayed asking for permission to modify the project build script, click OK.
8. In the Select Profiling Task dialog, click on the Analyze Performance button.
9. Click the Entire Application option. Verify that the Profile application server startup option is not selected.
10. Select Quick Filter from the Filter list and then click the "..." button next to the Quick Filter entry to specify a filter for the methods that should be profiled. The Set Quick Filter window appears. Select the Inclusive radio button. Then enter enterprise.interceptor_stateless_ejb into the Filter Value text field and click the OK button.

    All methods in the classes of the enterprise.interceptor_stateless_ejb package (and child packages) will be profiled - no other methods will be profiled. When profiling a large application or when profiling Java EE components such as EJBs, it is very important to specify a filter when profiling the entire application. Otherwise, the amount of overhead introduced by the profiler could have a significant impact on performance.

11. Click the Run button. If a dialog is displayed asking you to stop the bundled Tomcat server, click OK. It will take a moment for the IDE to start the application server in profiling mode, deploy the sample application, and then do the profiling instrumentation. Eventually you should see a BUILD SUCCESSFUL message in the IDE's Output window, as highlighted in the example below.
12. In the Projects window, right-click the entry for InterceptorStateless and choose Run Project from the context menu. The IDE will actually run the InterceptorStateless-client-app. It is a simple command line utility that calls a method on one of the EJBs and then reports the results, as shown below.
13. Choose Profile > Take Snapshot of Collected Results. The CPU results window will open, as shown below. The CPU results window lists threads; the exact names listed might vary from one run of an application server to the next.
14. The methods of an EJB are always invoked on a thread chosen from the application server's thread pool. So to see the top-level methods that are being invoked, expand one or more threads, as shown below (click for full size).

    This list of methods is particularly useful when you are profiling an application with which you are not very familiar. By specifying an inclusive filter that limited profiling to the packages of the application's EJBs you can easily see the top level methods that get invoked. In this example, the checkIfNull() method of the NullChecker class is a top level method, as are the constructors for the ArgumentsChecker, NullChecker, and StatelessSessionBean classes.

15. Note that the relative amount of time used by those constructors is very small, so further information on them is not interesting. It would be helpful, however, to investigate the time used by the checkIfNull() method. To learn more about how the time was spent in the checkIfNull() method, expand the entries under it; an example is shown below (click for full size).

    Because the filter was set to only include methods in the classes of package enterprise.interceptor_stateless_ejb (and sub-packages), there is some information missing from this display. Specifically, the amount of time spent in methods from other packages is not displayed.

16. Now that you know the top level (or "root") methods that are being invoked, you can modify the profiler's settings so that you get more information about those methods without imposing too much profiling overhead. Choose Navigate > Go to Class (or press Alt+Shift+O). In the Class Name field of the Go To Class dialog enter NullChecker and then press the Enter key.
17. The NullChecker.java file opens in the editor. Put the cursor anywhere on line 33, which is the first line of the checkIfNull() method.
18. Choose Tools > Add As Profiling Root Method. In the Select Settings Configuration Dialog, click the entry for Preset: Part of Application and then click the OK button.
19. Choose Profile > Modify Profiling
20. The Modify Profiling Task dialog is displayed. In its Analyze Performance section, click the Part of Application option.
21. Click the Select button that is next to the Part of Application option. The Specify Root Methods dialog should display and list only one method: checkIfNull().
22. Select Profile All Classes from the list of Filter options. The Analyze Performance section should now look like the example below. You have just changed the settings so that only a single root method is profiled. Note, however, that the NetBeans Profiler will analyze that root method and will also perform profiling of all methods that the root method calls. This analysis is done recursively, so that the entire call graph from the root method is profiled. Now that the profiling has been limited to just the methods that are really of interest, the filter is changed so that profiling is not limited to only those methods in the enterprise.interceptor_stateless_ejb package.
23. Click the OK button at the bottom of the Modify Profiling Task dialog
24. In the Projects window, right-click the entry for InterceptorStateless and choose Run Project from the context menu.
25. Choose Profile > Take Snapshot of Collected Results. A new CPU results window will open.
26. Click the Hot Spots tab at the bottom of the CPU results window. The result should look similar to the example below (click for full size). If you click on the tab for the window that contains the CPU results obtained earlier, you can compare the Hot Spots listed in each window. Because of the filter that was applied, the earlier snapshot only contains methods from the enterprise.interceptor_stateless_ejb package. It is important to note, however, that the filter used earlier was necessary in order to prevent introducing excessive profiling overhead - by using that filter you were able to identify the top level method of interest in the EJBs being profiled. With that method set as a root method and the filter removed, the profiler can provide complete details about where time is being spent - and in some cases that time is in methods that are outside of the enterprise.interceptor_stateless_ejb package.
27. In the newer CPU results window, click on the entry for the initUpperCase() method and then click on the Combined tab at the bottom of the window. The result should look something like the example below (click for full size). You can easily see the relationship between checkIfNull() which was selected as a root method, and the initUpperCase() method that is selected in the Hot Spots list. Notice that in the Hot Spots list, the initUpperCase() method was invoked two times. If you look at the Call Tree display, the initUpperCase() method was invoked only once. This disparity happens frequently when profiling code that is running in an application or web server - the Call Tree is displayed by thread. The Hot Spots are listed by method, with invocations across all threads aggregated. To find the other invocation of the initUpperCase() method, click the Find Next Occurence button in the Call Tree window. The Call Tree window will highlight the other invocation of initUpperCase(), even if it was on a different thread.
28. Choose Profile > Stop.

Summary:

In this exercise you learned how to use the Profiler to examine the performance of EJB methods. You learned how to identify a root method and then get detailed information about the methods invoked by that root method.