SOA Datasource Monitoring Steps

One of the things that can cause poor application performance is not having enough connections to the database available. Since Oracle SOA Suite is a heavily database intensive application, it can cause significant performance problems. , particularly if using lots of transient SOA BPEL processes.Due to this SOA datasource monitoring is very important for optimum performance evaluations.

1. Connect to the WebLogic administration console at http://localhost:7001/ console; replace localhost and 7001 with the hostname and port of the server if it is not running locally on 7001. If this is the first time you have accessed the WebLogic console since starting the server, WebLogic will first deploy the console application, which may take a few minutes.

2. Log in to the console by using your administration credentials.

3. Open the Services category on the left-hand navigation pane, and select Data Sources.

4. This will display a list of all the data sources in the main panel.

5. Select the first of these data sources, which will load its properties page. Select the Monitoring tab and the Statistics subtab.

6. This will display the statistics for the data source. If you see nothing on this page, then it is likely that none of the servers on which this data source exists are running.

7. Click on the Customise this table button, and add the following columns to the view: Active Connections Current Count, Active Connections High Count, Current Capacity, Number Available, Waiting for Connection Current Count, and Waiting For Connection High Count. Click on Apply.

8. Now, when you view the Statistics panel, it should show the following new statistics:

9. Check the statistics for any problems, see the How it Works… secion of this recipe for more details about what to look for.

10. Repeat steps from 5 through 9 for each data source.

 

The Oracle WebLogic application server exposes management and monitoring metrics using the JMX standard, and the Oracle WebLogic console makes use of these to display information on components such as the database connection pool sizes. It is worth noting that most connection pools have an initial size of zero. So if you view the pool size before the application has been used, then you will see zero for all of the statistics we are monitoring. If this is the case, then you should run some load through your application and check back again.

 

These connection pools are used by SOA Suite components to talk to the database for many purposes including storing process instance state, restoring state, storing logging information, and so on. If WebLogic runs out of these connections, then requests have to queue, waiting for a connection to become available, eventually timing out if no connection becomes available. By monitoring the number of connections in use, you can increase the maximum number of connections in the pool, if you notice that they are running out.

We are looking for a number of different things in the connection statistics:

1. Active Connections Current Count equal to Current Capacity, which indicates that every connection from the pool is currently in use. This means that there are no free connections. If the Current Capacity is the maximum number of connections that the pool will hold, then new requests will have to wait for connections.

2. Active Connections High Count equal to Current Capacity, which indicates that at some point, every connection from the pool was in use. Active Connections High Count gives the highest value that Active Connections Current Count has had since the server was restarted (or the statistics reset), so can be useful for diagnosing the cause of performance problems that happened in the past, and the system has now recovered.

3. Number Available equal to zero, which indicates that the pool is empty (unless the pool has not been initialized yet). This will usually occur when all the other conditions are true.

4. Waiting for Connection Current Count or Waiting for Connection High Count not equal to zero, indicating that at some point there have been threads waiting to get a connection from the pool. As threads will only wait for connections if there are none in the pool, then we would expect to only see this if all of the other conditions are also true.

These are all indicators of the same underlying problem, which is that there are insufficient available connections to the database. This is usually caused by one of three things—either a sudden burst of traffic has used up more than normal, the database is running slower than normal, or there is a connection leak in the application. To find out which of these is the case, you should look at the output of the thread dumps and database statistics.

 

 

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.