With the release of 12.2.1 we get access to so-called Integration Workload Statistics. Once IWS is activated a snapshot of system resource usage, composite SOA metrics such as statistics and endpoint statistics is periodically triggered. These statistics are written to the database. The metrics of a specified time period can be retrieved at any time. These metrics can be used to analyze problems now and in the past.
IWS provides quite a bit of load on the database and is thus disabled by default. In order to use IWS it must first be enabled, as shown in the following three pictures.
Select Configure in the top right corner of the IWS Reports page to change the data collection settings.
Using the snapshot interval and the data collection level it is possible to set how many/often metrics will be stored in the database.
After some time, and multiple snapshots are created, it is possible to generate a IWS report. This can be done from the IWS Reports page. There may be a CSV, HTML or XML report be generated. After selecting an output format and specifying a start and end date the report is generated.
The IWS report includes information on:
- on what snapshots the report indicates
- time of snapshots
- system information such as host, domain, server, os, #cpu’s
- utilization metrics of system resources like
- avg CPU load
- avg memory
- avg number of DB connections used
- avg number of threads which are active for the various work managers
- queue statistics
- endpoint and wire statistics
- statistics are collected for every service, reference, wire, EDN publish and subscribe.
- also for internal queues and endpoints, aggregates across the whole composite are shown, so that you can drill down starting from a composite down to an individual endpoint/queue.
During the OFM Summer Camps in Lisbon last August, I had the opportunity to experiment with IWS. Looks very very promising. A lot of valuable data that have so far remained hidden in the soainfra can now be explored. Lots of new insights come within reach, like: IWS makes insightful what the slowest composite endpoints (inbound and outbound) are. The number of times that a hydration and dehydration of a composites takes place. The time required for this on average. Which activities are the most time consuming.
With this information a different level of process improvement comes within easy reach. Developers can get already during developing gain insight into bottlenecks. In case of performance problems there is more detailed and more specific information available.
p.s. as mention before IWS causes quite some load on the database, which also has implications for the overall performance. So it is not recommended to keep IWS running continuous in a production environment, but only at those times that circumstances give rise to do so. And to turn it off afterwards.