If you receive an error when running the project, revisit the setup instructions, which describe how to prepare the database and establish connectivity between the IDE, GlassFish, and MySQL. If you want to log into the project’s administration console (not required in this tutorial unit), you’ll need to create a user named nbuser on the GlassFish server. This task is described in Unit 11, Securing the Application: Create Users and/or Groups on the Server.

You require an Internet connection to download the selected plugins.

The installer downloads, verifies, and installs the plugins. When installation has successfully completed, click Finish to exit the installer, then click Close to close the Plugins Manager.

If you open the Files window (Ctrl-2; ⌘-2 on Mac), you’ll see a new jmeter folder added to the project. (Recall that the Files window provides a directory-based view of projects, i.e., it displays the folder structure of projects as they exist on your computer’s file system.) The jmeter folder corresponds to the Project window’s Load Generator Scripts node, and will contain any load scripts that you later add to the project.

To demonstrate how to create a test plan in JMeter, we’ll base our plan on the tutorial use-case, which was presented in Designing the Application. A list of user-initiated requests to the server, based on the given use-case, might look something like the following:

Let’s proceed by creating a JMeter test plan that follows the above list of requests.

Instead of scrolling to the bottom of the list, simply begin typing ‘load’. As shown in the image below, the Load Testing Scripts category displays.

Note: The NetBeans template plan includes various user-defined variables, as shown in the above image. Usage of several of these variables will become clear as we work with the test plan. For more information, see the Apache JMeter User’s Manual: 18.4.13 User Defined Variables.

Let’s begin recording requests for the test plan. To do so, we’ll use JMeter’s HTTP Proxy Server. Instead of entering test plan requests manually, we’ll run the proxy server and have it record requests sent from the browser. For large test plans this technique is invaluable.

Note that the 'Use Recording Controller' option is selected by default for the Target Controller field. When you begin recording requests, they will be stored in the Recording Controller that is listed in the left column.

If you have previously configured your browser’s proxy, remember your settings so that you may be able to reenter them after completing this exercise.

In Firefox, you can do this from the Options window (Preferences window on Mac). * Choose Tools > Options (Firefox > Preferences on Mac). * Select the Advanced > Network tabs. * Under the Connection heading, click Settings. * Select the 'Manual proxy configuration' option, then type in localhost and 9090 for the HTTP Proxy and Port fields, respectively. * Remove the 127.0.0.1 and localhost entries in the 'No Proxy for' field.

In Firefox, you can do this by pressing Ctrl-Shift-Del (⌘-Shift-Del on Mac) to open the Clear Recent History dialog. Under 'Time range to clear', ensure that you’ve selected a range that extends to the first time the browser accessed the Affable Bean website. Select Cache, then click Clear Now.

The reason this is recommended is that JMeter automatically inserts user-defined variables throughout the test plan, wherever their values occur. So, for example, when the URL for /AffableBean/js/jquery-1.4.2.js is encountered, it will be recorded as: AffableBean/js/jquery-1.4.${nb.users}.js. Later, when we modify the value and rerun the test plan, URLs such as this will also change, which is not desired behavior. Here, we enter a random value (99), since we don’t expect it to occur in the URLs that we are about to record.

If you inspect the /AffableBean/ node, you’ll note that it is a Simple Controller. Although dubbed a "Controller", the Simple Controller doesn’t offer any functionality beyond enabling you to group elements together - as demonstrated here.

The elements within the Recording Controller will look as follows.

Recall that the AffableBean application relies on a session-tracking mechanism (i.e., cookies or URL-rewriting) to remember which shopping cart belongs to which request. Therefore, we need to account for this in the test plan. JMeter acts as the client when sending requests to the server, however unlike a browser, it doesn’t have cookies "enabled by default." We apply the HTTP Cookie Manager to the thread group so that the JSESSIONID cookie can be passed between client and server.

Note: If you want to employ URL rewriting as the session-tracking mechanism, you would need to add the HTTP URL Re-writing Modifier to the thread group.

When you finish, the final six Simple Controllers and their contents will look as follows.

Load testing a web application involves making concurrent requests for resources, typically by simulating multiple users, and then examining the server’s behavior. We can use the test plan we created for this purpose, and make adjustments to the number of users and other settings to determine how the server behaves under the given work load.

Load testing should be performed with specific goals in mind, such as determining the throughput for the anticipated average and peak numbers of users. It is also worthwhile to assess the response time for requests, to ensure that site customers are not having to wait too long to be served. In order to measure the response time, you need to take into account the time during which data spends traveling over the Internet. One way to do this is to compare test results between a local server, where network travel time is nearly non-existent, and results from testing the production server remotely. The following example demonstrates how you can perform tests using your local development server. Once you migrate an application to the production server, you can simply change the value for the server variable set under the test plan’s User Defined Variables.

The results recorded in this and the following sections were arrived at by running tests on a computer with a 2.4 GHz Intel Core 2 Duo processor and 4 GB of memory. Naturally, the results you get depend on your computer’s performance, and will likely not match those displayed here.

When you run load tests, you should be careful not to overload your computer. If you set too many threads (i.e., users), do not place adequate delay between individual requests, or continuously loop through the test plan, there is a chance that JMeter will expend your computer’s processing capacity or memory. JMeter will then become unresponsive and you may need to "force quit" the tool using your computer’s task manager. It is therefore recommended that you open the task manager in order to monitor the computer’s CPU and memory levels while the test is running. This will allow you to gauge the limits of your computer in terms of running the test plan.

Note: If you did not create the JMeter test plan in the previous sub-section, you can download the complete `useCaseTest.jmx` file and add it to your project. To add it to the AffableBean project, copy it from your computer’s file system (Ctrl-C; ⌘-C on Mac), then in the IDE, open the Files window (Ctrl-2; ⌘-2 on Mac), right-click the jmeter folder and choose Paste.

The test plan runs for approximately 50 seconds. Note that request samples are taken every three seconds, during which you can watch as results are added and updated. Note that values for the Average, Min, and Max columns are represented in milliseconds.

From the results displayed in the above image, we can observe that:

For further information, see the official jQuery documentation: CDN Hosted jQuery.

The green ( ) icons indicate an HTTP status response of 200. In the above image, under 'Sampler result' in the right panel, note that the Thread Name for the selected sample is 'AffableBean Users 1-1'. The second '1' represents the thread (i.e., user) number. When testing multiple threads, you can use View Results Tree listener to pinpoint exactly when each thread makes a request within the test. Finally, in the image above, note that the 'HTML (download embedded resources)' option is selected in the lower left corner. When you select the 'Response data' tab in the right panel, JMeter attempts to render the response as it would display in a browser.

Note: Red warning ( ) icons indicate that requests are not being handled properly (i.e., HTTP 404 status messages are being sent). While this begins to happen when a server reaches its performance capacity, 404 status messages under a normal load suggest that the application is not functionally stable. You should then check the server log to determine why requests are failing, and make changes to your application.

In the coming steps, we’ll add an increasing number of users to the test, and examine the server’s overall throughput.

In the tests we’ve so far conducted, the throughput for a single user was calculated at 41/min, and for 20 users it was 577/min. You can continue to increase the demand on the server to see if it’s possible to determine what the maximum throughput value can be, given your local setup. This is an example of stress testing, in which the system resources are purposely worked to their limits in order to arrive at a maximum capacity value.

You can adjust the User Defined Variables, then run the test plan and examine the results. For example, experiment by increasing the number of users, or decreasing the ramp-up period or delay between requests.

Important: When stress testing, you should monitor your computer’s CPU and memory levels. If you see that JMeter is not able to record results under a specific load and becomes unresponsive, you can try to stop the test by choosing Run > Stop (Ctrl-.; ⌘-. on Mac). Otherwise, if JMeter does not respond, you may need to kill the JMeter process from your computer’s task manager.

The following table lists results recorded in JMeter’s Summary Report, from increasing the number of users with each test run.

If the production server is on a machine that has resources similar to those of your development environment, and assuming your computer is not running other CPU-intensive processes while tests are conducted, you can get a rough idea of how many users can be served by examining your computer’s CPU usage during tests. For example, if it has been decided that CPU levels for normal and peak loads will be approximately 30% and 70%, respectively, you can watch the CPU monitor as you increase the number of users with each run of the test plan. The following images suggest 150 users could be served during a normal load, and 400 during a peak load.

Keep in mind that when running tests in this manner, your local server is competing with JMeter for the computer’s resources. Eventually, you’ll want to test your production server remotely to get more accurate results. See the following resources for more information:

In Java, memory leaks occur when objects continue to be referenced even after they are no longer needed. This prevents Java’s built-in garbage collection mechanism from destroying these objects, and consequently they remain in existence throughout the life of your application. When these objects are regularly created, the Java Virtual Machine (JVM) heap will continue to grow over time, ultimately resulting in an OutOfMemoryError when the heap is eventually exhausted.

The JVM heap represents memory that is dynamically allocated by the Virtual Machine during runtime. Because the GlassFish server runs on Java, it relies on the JVM heap for memory resources during execution. All applications that are deployed to the server can be perceived as extensions to this rule; in other words when your web application runs, it consumes resources from the JVM heap.

When building web applications, you need to be mindful of memory allocation. Aside from avoiding memory leaks in your code, you must ensure that the JVM heap is large enough to accommodate all user sessions at a given time, and that your system is able to support the maximum heap size set by your server.

The following example aims to familiarize you with the Profiler’s interface, and demonstrates how you can utilize its functionality to ensure that the AffableBean application will continue to perform efficiently after it has been serving client requests for some time. In this example, you download and add a new JMeter test plan, `useCaseTestRandom.jmx`, to the project. The new test plan is an advanced version of the one you created earlier in this unit. It makes use of JMeter’s conditional and random controllers to adapt a slightly more realistic simulation of the tutorial’s use-case.

Consider that only a small fraction of visits to an e-commerce site will result in a completed order. If you recall from units 8 and 9, Managing Sessions and Integrating Transactional Business Logic, the application terminates the user session upon a successfully completed order. In other words, with each completed order, the server is able to free up any resources that were previously tied to the session. Now, consider the far more common scenario of a user not completing an order, but simply navigating away from the site. Based on the session time-out which you specified in the application’s web deployment descriptor, the server will need to wait a period of time before it can free any resources tied to the session. The new load script, useCaseTestRandom.jmx, is configured so that on average one in ten user threads completes an order. Our goal by running this load script is to determine whether the application’s host environment (i.e., the GlassFish server running locally on your computer) has enough memory capacity to provide continuous, fast service for an extended period of time.

Note: Recall that in Managing Sessions: Handling Session Time-Outs, you set the AffableBean session time-out to 10 minutes.

NetBeans 6.8 note: The useCaseTestRandom.jmx script is not compatible with the JMeter Kit plugin for NetBeans 6.8. Because the script utilizes various logic controllers which unfortunately are not available in JMeter version 2.2, it will not run on the JMeter implementation in NetBeans 6.8. In order to become familiar with the Profiler, use useCaseTest.jmx in this exercise instead. If you use useCaseTest.jmx, you need to set the load script to run continuously. To do so, open the script in JMeter, select the AffableBeanUsers thread group, then in the main panel, select the 'Forever' checkbox for the Loop Count field.

Note: You can undo this action at a later point by choosing Profile > Advanced Commands > Unintegrate Profiler from the main menu. Alternatively, you can switch to the Files window, delete your project’s build.xml file, then rename the build-before-profiler.xml file to build.xml.

Note: If the profiler does not run the load script after starting the application in profile mode, you can invoke it yourself. From the Projects window, right-click the script and choose External Edit. Then, in JMeter, press Ctrl-R (⌘-R on Mac) to run the script. If the left-hand graph displayed by the VM Telemetry Overview depicts the purple area as remaining horizontal (shown below), you can be fairly certain that the load script is not running.

You can select the Enable Threads Monitoring option in the Profiler window (displayed above). This will trigger the Threads window to open by default when running the Profiler.

Similar to the VM Telemetry Overview, the VM Telemetry window provides views on the JVM heap, garbage collection (GC), as well as threads and loaded classes.

You can hover your cursor over the graph to view real-time measurements of the heap size versus the used heap.

Click the Scale to Fit ( ) button above the graph to maintain a continuous view of the entire monitoring session.

The image below shows the state of the heap after monitoring the server for approximately three hours while running the useTestCaseRandom.jmx script continuously with 150 simultaneous users. The AffableBean application running on the GlassFish server uses under 175 MB of the JVM heap.

The HeapWalker is a tool that is built into the NetBeans Profiler, which allows you to examine JVM heap contents. You can use it to browse classes and instances of classes on the heap, fields of each instance or class, and references to each instance.

The HeapWalker is particularly useful when locating the cause of memory leaks in your code. You can set the Profiler to automatically take a heap dump if an OutOfMemoryError occurs when you are profiling an application. You can then use the HeapWalker to inspect the heap dump and determine which objects were consuming the most memory.

This functionality is enabled by default, but you can view and modify Profiler settings from the IDE’s Options window (Tools > Options; NetBeans > Preferences on Mac). From the Options window, select Miscellaneous, then select the Profiler tab. In the On OutOfMemoryError field, note that 'Save heap dump to profiled project' option is selected.

For example, if the GlassFish server utilizes 512 MB of memory, and the JVM attempts to allocate more than 512 MB of memory to the JVM heap (represented by the pink area in the heap size graph of the VM Telemetry monitor, shown above), an OutOfMemoryError will occur, and the IDE will ask you if you would like to view the heap in the HeapWalker.

To take a heap dump while your application is being profiled, choose Profile > Take Heap Dump from the main menu.

The following example depicts a heap dump from running the useCaseTestRandom.jmx script at 500 users, ramp-up period at 100 seconds, and with a loop count of 5. The HeapWalker’s Summary provides an Inspect panel which enables you to locate the largest objects in the heap. Specify the number of objects you want to search for, then click Find.

In the above image, you can see that for the AffableBean application, the largest object in the heap dump is an instance of the org.apache.catalina.session.StandardManager class, with a retained size of nearly 79 MB.

Clicking the object name enables you to open the Instances view on the object. When you do so, you can see the instances of the class that exist on the heap (left column), the fields contained in the class, and their values (right column, top), and other objects on the heap referring to the instance (right column, bottom).

In the above image, it appears that 706 StandardSession objects were active on the heap, a result of the load script simulating multiple user sessions. The server must have sufficient memory resources to maintain session objects during periods of high traffic.

You can save (Ctrl-S; ⌘-S on Mac) heap dumps. When you do so, they become listed in the Profiler Control Panel under Saved Snapshots.

From Optimize GlassFish Performance in a Production Environment:

The GlassFish server (v3 and Open Source Edition 3.0.1) sets the heap to 512 MB by default. If you wanted to increase the heap size to 1 GB, you would enter ‘-Xmx1024m’, click the Save button in the upper right corner, and then restart the server.

From the Sun Java System Application Server 9.1 Performance Tuning Guide:

In practice, clients frequently connect to the server and then do not complete their requests. In these cases, the server waits a length of time specified by the Idle Thread Timeout parameter._ [900 seconds, i.e., 15 minutes, is the default entry for GlassFish v3 and Open Source Edition 3.0.1.]

_Also, some sites do heavyweight transactions that take minutes to complete. Both of these factors add to the maximum simultaneous requests that are required. If your site is processing many requests that take many seconds, you might need to increase the number of maximum simultaneous requests.

Adjust the thread count value based on your load and the length of time for an average request. In general, increase this number if you have idle CPU time and requests that are pending; decrease it if the CPU becomes overloaded. If you have many HTTP 1.0 clients (or HTTP 1.1 clients that disconnect frequently), adjust the timeout value to reduce the time a connection is kept open.

Suitable Request Thread Count values range from 100 to 500, depending on the load. If your system has extra CPU cycles, keep incrementally increasing thread count and monitor performance after each incremental increase. When performance saturates (stops improving), then stop increasing thread count._

The GlassFish server provides two thread pools by default. The http-thread-pool thread pool is configured for use by network listeners, while thread-pool-1 is configured for use by the ORB (object request broker) for RMI/IIOP requests. (A stand-alone web application deployed over a non-distributed environment, such as the AffableBean application, relies on the http-thread-pool by default.)

From Optimize GlassFish Performance in a Production Environment:

Connection pool settings can also be specified in the sun-resources.xml descriptor: