Monitoring SOA Suite while testing
In this recipe, we'll look at tying together running tests that generate larger loads with starting points for monitoring SOA composite performance.
Getting ready
You will need to install Oracle SOA Suite 11g for this recipe with the Enterprise Manager Fusion Middleware Control console.
You'll need to complete the Installing Apache JMeter recipe, deploy the test composite available from the book website to a SOA Suite server, have a working test plan as in the Creating a web service test using JMeter recipe, and have access to the Enterprise Manager and WebLogic web consoles.
How to do it…
These steps will show you some basic monitoring that can be performed on SOA Suite while tests are running:
- Load the sample JMeter for this chapter (or create your own). In the JMeter test, select Test Users Thread Group. Set Number of users (Threads) to a higher value than
1
. As a guide, if the host running this test is powerful, then try100
, otherwise start with a value around50
. We only want a small value to start with. - Set Ramp-Up Period (in seconds) to a value similar to the number of users. Set Loop Count to a value of around
50
, so that threads will loop and generate a sustained load. - Log in to Enterprise Manager on
http://admin-server-host:<admin-port>/em
(the default port is7001
). - In the toolbar on the left of the screen, expand the Weblogic Domain folder, expand the domain running your composite, and right-click on the server under test. Select Performance Summary.
- Click on the Show Metric Palette button, and select metrics to monitor. Good starting candidates are JVM Heap, Memory Usage, SOA Composite Errors, and Incoming Message Throughput. Finally, in the Server Overview folder, there is a summation of the JDBC connections Open JDBC Connections.
- In another tab, log in to the WebLogic Administration Console http://admin-server-host:<admin-port>/console and under Environment | Servers | SOA Server to monitor | Monitoring | JDBC, you'll see a breakdown view of the JDBC connections. Click on Customize this table, and ensure that Prep Stmt Cache Current Size and Active Connections Current Count are added to the chosen list.
- Now, run the test JMeter load test a few times, gradually increasing the number of users (thread) in each test, and monitor the output in Enterprise Manager and the WebLogic admin console.
- Try to observe any limiting factors within the SOA suite server being monitored. In the following screenshot, we can see that we're approaching a large amount of CPU consumption on this host, but the throughput is steady and the JDBC connection pools are not yet at capacity:
- Use the WebLogic console to monitor the breakdown of connections:
How it works…
In this recipe, we looked at the main way to control and vary user load in JMeter; by controlling the thread group that represents concurrent user load. There are other ways to form this load by using looping controllers that we did not explore here.
We looked at the results in a new JMeter listener. Whilst JMeter can give us information on the interaction profile with our SOA composites, the view of results it presents ends at the entry point of our SOA infrastructure.
We need to combine the information in Chapter 2, Monitoring Oracle SOA Suite, to guide us on where to begin analyzing the SOA Suite components, to identify bottlenecks and candidates for tuning.
In this section, we looked at creating an overview page in the Enterprise Manager Fusion Middleware Control tool available with SOA Suite. This tool gives us a short term component metric view; not every system will have the same performance choke points, so the dashboard components we've used in this recipe should be altered to the needs of the system under test.
We also leveraged the WebLogic tool to give us a further breakdown of the internal metrics for the WebLogic SOA Server's JDBC connection pool. We can use this to further decompose points of contention in our system.
There's more…
Unfortunately, Enterprise Manager Fusion Middleware Control only allows for a short window of monitoring until the browser session times out. It is good practice to record metrics in a permanent store of information, for posterity and tallying of test results with system changes. Chapter 2, Monitoring Oracle SOA Suite, contains many recipes to set up monitoring of your Oracle SOA Suite application. If you configure this monitoring in your testing environment, you will have a large amount of monitoring data available to work with.
See also
- The Monitoring JVM memory usage and Monitoring platform CPU usage recipes in Chapter 2, Monitoring Oracle SOA Suite