Increasing the performance of EM console in Oracle SOA Suite 11g - Part2

Additional steps to improve the EM console performance.

DMS Spy Servlet to monitor/retrieve the metrics - Oracle SOA Suite platform

The DMS Spy Servlet is part of the DMS web application. The DMS web application's web archive file is dms.war, and can be found in the same directory as dms.jar: <ORACLE_HOME>/modules/oracle.dms_11.1.1/dms.war.

The DMS web application is deployed by default as part of a JRF-enabled server instance. The URL is: http://host:port/dms/Spy.

Only users who have Administrator role access can view this URL as access is controlled by standard Java EE elements in web.xml.

This can be used to monitor Oracle SOA Composites, SOA Components, JVM, Datasources and MDS etc..

How to get the metrics through wget command:

SOAWorkManager - Tuning the SOA Engine

• Request Classes - A request class expresses a scheduling guideline that WebLogic Server uses to allocate threads to requests. Request classes help ensure that high priority work is scheduled before less important work, even if the high priority work is submitted after the lower priority work.Request classes define a best effort. 
• max-threads-constraint—Limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. We can define a max-threads-constraint in terms of a the availability of the resource that requests depend upon, such as a connection pool.Once the constraint is reached the server does not schedule requests of this type until the number of concurrent executions falls below the limit. The server then schedules work based on the fair share or response time goal.
• min-threads-constraint—Guarantees the number of threads the server will allocate to affected requests to avoid deadlocks. 
• capacity—Causes the server to reject requests only when it has reached its capacity. The default is -1. Note that the capacity includes all requests, queued or executing, from the constrained work set. Work is rejected either when an individual capacity threshold is exceeded or if the global capacity is exceeded. 

WLST script to migrate default File Stores to JDBC store in weblogic servers

The persistent store provides a built-in, high-performance storage solution for WebLogic Server subsystems and services that require persistence. For example, it can store persistent JMS messages or temporarily store messages sent using the Store-and-Forward feature. The persistent store supports persistence to a file-based store or to a JDBC-enabled database.

By default, File store is used as a persistence store for weblogic servers

File stores are generally easier to configure and administer, and do not require that WebLogic subsystems depend on any external component.

File stores generate no network traffic; whereas, JDBC stores will generate network traffic if the database is on a different machine from WebLogic Server.

JDBC stores may make it easier to handle failure recovery since the JDBC interface can access the database from any machine on the same network. With the file store, the disk must be shared or migrated.

This tutorial explains the approach to migrate the default JMS file store to a DB store through WLST script.

Data Source

As a first step, create a schema in target database(beloSQL for Oracle database)

alter session set “_ORACLE_SCRIPT”=true;

create user JDBC_STORE_USER
identified by “jdbcstoreuser”
temporary tablespace temp
default tablespace users;

grant connect to JDBC_STORE_USER;
grant resource to JDBC_STORE_USER;
grant create session to JDBC_STORE_USER;

ALTER USER JDBC_STORE_USER quota unlimited on USERS;

Create a data source with name “JDBCStoreDataSource” to connect to the database

A JDBC store must use a JDBC data source that uses a non-XA JDBC driver and has Supports Global Transactions disabled.

Test the configurations and ensure the test connection successful

Target the data source to all the servers in the domain so the same data source can be used by all the servers to manage the JDBC stores(For demo i am targeting only to Admin Server)

Now the data source is ready and can be used for JDBC store configurations

WLST Script

The below wlst script migrate the existing File Store to JDBC Persistence store — my case the server is enabled with one persistence store(BAMMonitoringJMSFileStore) for JMS Server(BAMMonitoringServer) and targeted only to Admin Server so the script migrate the JMS store to JDBC store and target to Admin Server, modify the script based on the number of existing File store configuration

MigrateFileStoreToJDBSStore.py

import sysprint "@@@ Starting the script ..."from java.util import *
from javax.management import *#The directory of the domain configuration
#/app/oracle/products/11g/admin/domains
wlsDomain='C://Albin/SW/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain'
print "WLSDOMAIN="+wlsDomainadminURL='t3://localhost:7001'
adminUserName='weblogic'
adminPassword='weblogic1'
connect(adminUserName, adminPassword, adminURL)
edit()
startEdit()
############# JDBC stores for STANDALONE ADMINSERVER ## Enable and target unique JDBC Store for all the servers in the domain
cd('/')
cmo.createJDBCStore('BAMMonitoringJMSJDBCStore')
cd('/JDBCStores/BAMMonitoringJMSJDBCStore')
cmo.setDataSource(getMBean('/SystemResources/JDBCStoreDataSource'))
cmo.setPrefixName('bammonitoring')
set('Targets',jarray.array([ObjectName('com.bea:Name=AdminServer,Type=Server')], ObjectName))#### Add 
#### end of creating jdbc stores############Set Persistent Stores for the sub systems e.g JMS Serverscd('/JMSServers/BAMMonitoringServer')
cmo.setPersistentStore(getMBean('/JDBCStores/BAMMonitoringJMSJDBCStore'))#################DESTROY ALL THE EXISTING FILE STOREScd('/')
cmo.destroyFileStore(getMBean('/FileStores/BAMMonitoringJMSFileStore'))
 
save()
activate()

Script

techforum-repo/youttubedata

Contribute to techforum-repo/youttubedata development by creating an account on GitHub.

github.com

Before executing the script, change the configurations as required.

Execute the script — <<Oracle_Home>>\oracle_common\common\bin\wlst.cmd MigrateFileStoreToJDBSStore.py

The existing file store is deleted after enabling the JDBC store for the modules.

For clustered environment the same should be executed for all the servers in the cluster with unique JDBC store name(e.g BAMMonitoringJMSJDBCStore for server 1 and BAMMonitoringJMSJDBCStore2 for server 2).

Restart the servers, the required tables({PrefixName}WLStore) — BAMMonitoringWLStore will be created.

The config.xml file will be enabled with required JDBC store configurations as below.

The table with name “BAMMONITORINGWLSTORE” created in database

select object_name as table_name from user_objects where object_type = ‘TABLE’ order by object_name;

The required data now stored into the JDBC store

This concludes the migration of existing Default File Store to JDBC store. The File Store and JDBC store has its own merits and demerits, the stores should be selected based on the uses cases — File Store provides better performance but JDBC store provides better recovery support.