NetBeans Profiler Introductory Demo and Feature Tour
This demo script is part of the NetBeans World Tour 2008 session #8, Integrated Profiling Tools. Refer to the top-level demo scripts page for additional information.
Main Points to Hit
- The NetBeans Profiler has a variety of powerful and easy to use capabilities to help you track down performance problems.
- Using root method selection you can limit the overhead imposed by the profiler to only those parts of an application that you suspect have a problem.
- With its tight integration into the developer work flow, it is easy to select which parts of your application should be profiled and to start/stop profiling sessions.
- JDK5 or JDK6
- NetBeans 5.5 (or higher) - until 6.0 ships it is best to do this demo with 5.5 to show features that are available now :-)
- Download and unzip this Java2D project. It is from the JDK sample programs. If you're on OS X, grab this Java2D_OSX_ProfilerIntroDemoAndTour.zip.
- Open the Java2D project
- Profile the Java2D project at least once so that the profiler can modify the build.xml file
- Right before starting the demo, run the Java2D project at least once - this makes subsequent startups a bit quicker
Profile the Entire Application
- Run the Java2D project with the Run command (no profiling). Suggested Comment (SC): "This is a sample application from the JDK. Notice how fast it starts up."
- Shutdown the Java2D application. SC: "For those of you who missed it, I will do this again. Watch closely as I click Run... we get a progress meter and then we're up and running."
- Click on a few of the tabs in the application. Click on the Colors tab last. SC: "This part of the application looks interesting - the animation at the bottom has some statistics that look interesting, for example Frames Per Second (FPS)."
- Shutdown the Java2D application. SC: "One of the problems we are trying to solve with the NetBeans profiler is that we want you to be able to profile only the parts of your application that are really of interest. Now you can, if you want, profile the entire application, but that can have a big impact on performance."
- Right-click the Java2D project and choose Profile Project
- Click the large Analyze Performance button to expand it (if it is not already expanded)
- Select Entire Application
- Select Profile All Classes for the filter. SC: "Just to show you the impact, I will profile all methods of all classes - so this is everything in the application itself and all libraries that it uses. Watch what happens when I click Run."
- Click the Run button. A couple of dialogs go by for the profiler. Eventually the application's progress meter appears. SC: "The profiler gets started and then eventually it starts the application. Notice the difference in how long we wait for the progress meter to complete... and we wait. And we wait some more." :-)
- Click a few of the tabs again. Click the Colors tab last. The animation will usually be a bit sluggish looking initially and then it smoothes out. SC: "We are seeing a bit of an impact on performance - the application took much longer to start and does not respond to mouse clicks as quickly."
- The FPS value might be different when doing profiling - it depends upon the version of the JDK you are using, the operating system's video driver, and your graphics card. If the value is consistently lower then point this out.
- Switch back over to the IDE. Scroll the Profile window until the Basic Telemetry information is visible. SC: "Notice the number of methods that are being profiled - over 20,000. And this is a small sample application. With a real-world application that number could be 10x or more."
- Click the Live Results button in the Profile window. Scroll through it to show how many rows it has. SC: "The other problem with profiling everything is that you end up with too much information to wade through in order to find the cause of performance problems."
- Select Profile > Stop SC: "I am going to shut this down and show you a better way. What some profiling tools force you to do is define filters of package and/or class names for what should or should not be instrumented by the profiler. The NetBeans Profiler supports filters, but it also has a more powerful feature: root methods."
Profiling Root Methods
- In NetBeans 5.5:
- In the Projects window expand the source packages under Java2D until you can see the render() and step() methods of the java2d.demos.Colors.Rotator3D class.
- Select both methods:
- Right-click and select Tools > Add as Profiling Root Method. SC: "If all I am interested in is checking the performance of the methods used to do that animation on the Colors tab then I can just navigate to those methods in the IDE (a key advantage of an integrated tool) and then select them as what the profiler calls root methods."
- In NetBeans 6.0:
- In the Projects window expand the source packages under Java2D until you can see the java2d.demos.Colors.Rotator3D class.
- Open the source file for java2d.demos.Colors.Rotator3D
- In the editor window, right-click the render() method and choose Profiling > Choose as Profiling Root Method. Do the same thing for the step() method. SC: "If all I am interested in is checking the performance of the methods used to do that animation on the Colors tab then I can just navigate to those methods in the IDE (a key advantage of an integrated tool) and then select them as what the profiler calls root methods."
- In the Setting Configuration dialog click Preset: Part of Application then click the OK button
- Right-click the Java2D project and choose Profile Project
- The Analyze Performance button should already be expanded. Click the Part of Application option - this will cause the dialog to display that 2 methods have been chosen as root methods.
- Click the Run button. Startup should be much faster. SC: "Now watch what happens when I profile only the part of the application for which I need information: startup is much faster - closer to what we saw with no profiling."
- Click some tabs. Click the Colors tab last.
- Switch back to the IDE. Scroll the Profile window until the Basic Telemetry information is visible. SC: "Now notice the number of methods that are being profiled - around 200. This is because the profiler examined the application, starting at the root methods that I selected. It instrumented those root methods and then examined the methods that they call and instrumented them and then it examined the methods that those methods call, etc. It does this until it has figured out the call graph that originates at the root methods - those are the only methods that get instrumented. Everything else runs at full speed."
- Click the Take Snapshot button in the Profile window. SC: "Even more important - with less instrumentation we have less data to wade through. We can easily see that the render() method is taking up much more time than step().
- Select Profile > View > Threads. Click the icon that is displayed in order to enable collection of thread information. SC: "The goal of this demo is provide a quick tour so let's look at some additional features. I can see thread state very easily; with the state information color-coded."
- Select a thread and then click the Thread (Details) tab. SC: "I can drill into a specific thread to see a break down of how much time it has spent in each state."
- Click the Details tab in the thread window to switch to the text view. SC: "I can see the state changes for a thread."
- Select Profile > Modify Profiling. Click the Monitor Application button and then click OK. SC: "One of the nicest features is that I can change the profiler settings on-the-fly, without having to restart my application. I have just switched to a monitor-only mode, so there is no instrumentation at all now - the entire application is running at full speed."
- Select Profile > Modify Profiling. Click the Analyze Code Fragment Performance button. SC: "This feature is a very lightweight approach that provides high-level CPU performance information. It does not do detailed instrumentation, instead it is the equivalent of inserting calls to System.currentTimeMillis(); in your code. It calculates the deltas as it passes those points in your code and reports the results." NOTE: This feature has been replaced in 6.0 with Stopwatch Profiling Points.
- Click the Analyze Memory Usage button. SC: "In addition to reporting CPU performance, the profiler can do detailed monitoring of your application's memory usage. This is especially helpful for tracking down memory leaks." (Note: a full demo of this feature is here).
- Click the Run Custom Profiling button. SC: "All of the profiling tasks shown thus far use preset configurations. This covers at least 80% of the cases, but if you want to fine-tune the profiler's settings you can do it by defining a custom configuration."
- Click the Cancel button to close the Modify Profiling dialog
- Select Profile > Stop SC: "It is important to note that while this demo was done with a desktop Java application, there are other types of applications that can easily be profiled with the NetBeans profiler."
Web Application Profiling
- Select File > New Project. Expand the Samples category and select Web. Then select the Tomcat Servlet Example and click Next. SC: "Let's create a project that contains the standard Tomcat servlet examples." Note this issue, Can't Profile Tomcat-targeted applications, on Mac OS X. Use GlassFish instead.
- Change the project name if you want and then click Finish.
- Right-click the Tomcat servlet project and choose Profile Project
- Click OK on the dialog that asks for permission to modify the build.xml. SC: "The default project system for Java projects in the NetBeans IDE is based on Ant. Here I will click on OK to allow the IDE to modify the build.xml in order to add a target for running the profiler."
- The Select Profiling Task dialog is displayed. Click the Analyze Performance button to expand it.
- Select the Entire Application option. The Profile application server startup option will be enabled, but is not checked by default. SC: "Again, the advantage of an integrated profiler... the profiler knows that this project is a web application and so in order to profile it we'll actually have to do instrumentation to Tomcat. By default if I were to select to profile the entire application the profiler will not bother to instrument the server's startup code."
- Click the Monitor Application button and then click Run. SC: "In the interest of time, let's just do some simple monitoring."
- Switch to the browser after it displays http://localhost:8084/servlets-examples/ and show that the application is running. SC: "So this was basically the same as running the application - the IDE started the server, started the browser, etc. Only now, we're profiling. :-) We have this same level of one-click profiling support for GlassFish and JBoss. For other servers, you can use the 'attach' feature."
- Select Profile > Stop
- Select Profile > Attach Profiler. The select profiling task dialog comes up. SC: "One last feature! While all this integration is nice, the profiler also supports just attaching to any JVM. It will even show you the JVM command-line flags that are needed and will edit a startup script for you if you want it to."
- Click the Attach Wizard button. Make selections and start going through the steps of the wizard. SC: "I can specify my application type, and server if I am using one, JDK version, etc. and the IDE will offer to edit my application's startup script or show me the changes that need to be made."
- Click the Cancel button. "If I had actually started the JVM for my application the JVM would see the command line flags and wait before proceeding. This is the same way that debuggers attach to a JVM, by the way. Once the JVM is waiting I can click the Attach button and start profiling."
- Click the Cancel button.
- (Optional) Undeploy and delete the Tomcat servlet application