22 Monitoring WebCenter Portal Performance

Monitor a range of performance metrics for WebCenter Portal through Fusion Middleware Control, and troubleshoot issues by analyzing information that is recorded in diagnostic log files.

Permissions:

To perform the tasks in this chapter, you must be granted the WebLogic Server Admin, Operator, or Monitor role through the Oracle WebLogic Server Administration Console.

Topics:

22.1 Understanding Oracle WebCenter Portal Performance Metrics

Through Fusion Middleware Control, administrators can monitor the performance and availability of all the components, tools, and services that make up WebCenter Portal, as well as the application as a whole. To access Oracle WebCenter Portal metrics through Fusion Middleware Control, see Viewing Performance Metrics Using Fusion Middleware Control.

To make best use of the information displayed it is important that you understand how performance metrics are calculated and what they mean. All Oracle WebCenter Portal's performance metrics are listed and described here for your reference. Some applications (such as Oracle WebCenter Portal) might use the full range of social networking, personal productivity, and collaboration metrics listed, while others may only use one or more of these features.

This section includes the following topics:

22.1.1 Understanding Oracle WebCenter Portal Metric Collection

Performance metrics are automatically enabled for Oracle WebCenter Portal and display in Fusion Middleware Control. You do not need to set options or perform any extra configuration to collect performance metrics for WebCenter Portal. If you encounter a problem, such as, an application running slowly or hanging, you can find out more about the problem by investigating performance metrics, in real-time, through Fusion Middleware Control.

This section describes the different ways Oracle WebCenter Portal collects and presents metric data:

22.1.1.1 Metric Collection: Since Startup

At any given time, real-time metrics are available for the duration for which the WebLogic Server hosting WebCenter Portal is up and running. Real-time metrics that are collected or aggregated since the startup of the container are displayed on Oracle WebCenter Portal metric pages under the heading Since Startup. These metrics provide data aggregated over the lifetime of the WebLogic Server. The aggregated data enables you to understand overall system performance and compare the performance of recent requests shown in Recent History.

For example, consider WebCenter Portal deployed on a managed server that was started 4 hours ago. During that time, WebCenter Portal serviced 10,000 portlet requests with a total response time of 500, 000 ms. For this scenario, Since Startup metrics for portlets show:

Since Startup: Invocations (count) - 10000
Since Startup: Average Time (ms) - 50

Note:

Metric collection starts afresh after the container is restarted. Data collected before the restart becomes unavailable.

22.1.1.2 Metric Collection: Recent History

In addition to Since Startup metrics, Oracle WebCenter Portal reports metrics for requests serviced in the last 10 to 15 minutes as Recent History metrics. To do this, Oracle WebCenter Portal takes regular snapshots of real time metrics at an internal frequency. These metric snapshots are used to calculate the "delta" time spent performing service requests in the last 10 to 15 minutes and this data displays as Recent History metrics. Since Recent History metrics only aggregate data for the last 10-15 minutes, this information is useful if you want to investigate ongoing performance/availability issues.

If you compare Recent Metrics to Since Startup metrics you can gauge how the system characteristics have changed, compared to overall system availability/performance.

For example, consider a system that has been up and running for 2 days. During that time, Oracle WebCenter Portal recorded that the total time spent servicing 100, 000 portlet requests was 5 000 000 ms. The system starts to experience performance issues, that is, in the last 10-15 minutes, 100 portlet requests took a total time of 3 000 000 ms. In this scenario, the average response time reported "Since Startup" is quite low and would not indicate a performance issue (5 000 000ms/100 000 = 50ms). However, the same Recent History metric is considerably higher (3000000ms/100 = 30 seconds) which immediately tells the administrator that performance degraded recently. A quick comparison of "Recent History" with the corresponding "Since Startup" metric can clearly show whether or not the recent metric data is normal and in this case shows there is currently a problem with the system.

Recent History metrics can also help you prioritize which areas to investigate and which areas you can ignore when performance issues arise. For example, if an ongoing performance issue is reported and Recent History metrics for a particular component shows a value of 0, it indicates that the component has not been used in the last 10-15 minutes. Similarly, if the "Average Response Time" value is small and the "Invocation" count is low, the component may not be contributing to the performance problem. In such cases, administrators can investigate other areas.

Typically, Recent History shows data for the most recent 10-15 minutes. However, there are situations when the data does not reflect the last 10-15 minutes:

If the WebLogic Server has just started up, and has been running for less than 10-15 minutes, then Recent History shows data for the duration for which the server has been up and running.
If one or more tools or services are not accessed for an extended period of time, then older metric snapshots slowly age out. In such cases, metric data is no longer available for the last 10-15 minutes so Recent History metrics cannot calculate the delta time spent in performing service requests that occurred in last 10-15 minutes. When this happens, the Recent History data can show the same values as the Since Startup metrics. When the tool or service is used again, metric snapshots for it resume. After enough recent data is available, the Recent History metrics again start to display metrics for the last 10-15 minutes.

Most live environments are not idle for extended periods, so recent metric collection is rarely suspended due to inactivity. However, if you have a test environment that is used intermittently or not used for a while, you might notice recent metric collection stop temporarily, as described here.

22.1.1.3 Metric Collection: Last 'N' Samples

Since Startup and Recent History metrics calculate performance over a specific duration, and show aggregated metrics for that duration. In addition to these, Oracle WebCenter Portal collects and reports per-request performance information for a range of key WebCenter Portal metrics. Such metrics allow you to look at the success and response time of each request individually, without considering previous requests. Out-of-the-box, the last 100 samples are used to calculate key metric performance/availability but you can increase or decrease the sample set to suit your installation.

For example, if 10 out of the last 100 page requests failed, page availability is calculated as 90%. If you reduce the sample set to 50 and 10 pages fail, page availability is reported to be 80%.

The examples show how the sample set size can effect the performance reports. The value you select is up to you but if you increase the number of samples, consider the additional memory requirements since the last 'N' metric samples are maintained in memory. Oracle recommends a few hundred samples at most.

To change the number of samples used to report key performance metrics in your installation, see Configuring the Number of Samples Used to Calculate Key Performance Metrics.

To find out more about Oracle WebCenter Portal's key performance metrics and thresholds, refer to Understanding the Key Performance Metrics.

22.1.2 Understanding the Key Performance Metrics

Diagnosing the availability and performance of WebCenter Portal typically requires that you look at various important metrics across multiple components such as the JVM, the WebLogic Server, as well as the application.

To help you quickly identity and diagnose issues that can impact WebCenter Portal performance, Oracle WebCenter Portal collects the last 'N' samples for a range of "key performance metrics" and exposes them in Fusion Middleware Control. To access key performance metric information for your application, see Viewing Performance Metrics Using Fusion Middleware Control.

Thresholds determine when a performance alert or warning is triggered. Allowing you to set threshold values that represent suitable boundaries for your Oracle WebCenter Portal system, ensures that you obtain relevant performance alerts in Enterprise Manager Fusion Middleware Control. When key performance metrics are "out of bounds" with respect to their configured thresholds they are easy to find in Fusion Middleware Control as they appear color-coded. For more information about thresholds, see Customizing Key Performance Metric Thresholds and Collection.

You do not need to specifically set thresholds for metrics, such as "availabilty", that report success or failure.

Oracle WebCenter Portal allows you to manage warning thresholds for the key performance metrics described in Table 22-1:

Table 22-1 Key Performance Metric Collection

Component	Key Performance Metric	Metric Sampling
WebCenter Portal	Active Sessions	1 sample every X minutes
WebCenter Portal - Pages	Page Response Time	Per Request
WebCenter Portal - Portlets	Portlet Response Time	Per Request
JVM	CPU Usage	1 sample every X minutes
JVM	Heap Usage	1 sample every X minutes
JVM	Garbage Collection Rate	1 sample every X minutes
JVM	Average Garbage Collection Time	1 sample every X minutes
WebLogic Server	Active Execute Threads	1 sample every X minutes
WebLogic Server	Execute Threads Idle Count	1 sample every X minutes
WebLogic Server	Hogging Execute Threads	1 sample every X minutes
WebLogic Server	Open JDBC Sessions	1 sample every X minutes

Oracle WebCenter Portal captures end-user requests for pages and portlets, and a metric sample is collected for each request. For example, if user A accesses page X, both the availability of page X (success/fail metric) and the response time of the request is captured by Oracle WebCenter Portal. Metric samples that take longer than a configured metric alert threshold or fail, show "red" in Fusion Middleware Control to immediately alert administrators when issues arise.

Other metrics, such as JVM and WebLogic Server metrics, are collected at a pre-defined frequency. Out-of-the-box, the sample frequency is 1 sample every 5 minutes but you can customize this value if required. For details, see Configuring the Frequency of WebLogic Server Health Checks.

The total number of samples that Oracle WebCenter Portal collects is configurable too, as described in Configuring the Number of Samples Used to Calculate Key Performance Metrics. The default sample set is 100 samples. Since there is a memory cost to maintain metric samples, do not specify an excessive number of samples; Oracle recommends a few hundred at most.

Oracle WebCenter Portal's key performance metrics are specifically selected to help administrators quickly identity and diagnose common issues that can impact WebCenter Portal performance. You can view all key performance metric data from your application's home page in Fusion Middleware Control.

22.1.3 Using Key Performance Metric Data to Analyze and Diagnose System Health

If you monitor WebCenter Portal regularly, you will learn to recognize trends as they develop and prevent performance problems in the future. The best place to start is your application's home page in Enterprise Manager Fusion Middleware Control. The home page displays status, performance, availability, and other key metrics for the various components, tools, and services that make up your application, as well as the WebLogic Server on which the application is deployed.

If you are new to Oracle WebCenter Portal, use the information in this section to better understand how to use the information displayed through Fusion Middleware Control to identify and diagnose issues.

Figure 22-1 presents high-level steps for monitoring the out-of-the-box application WebCenter Portal.

Figure 22-1 Analyzing System Health for WebCenter Portal - Main Steps

Description of "Figure 22-1 Analyzing System Health for WebCenter Portal - Main Steps"

Note:

Steps 4 applies only if your application utilizes the portlets feature.
Bar charts appear grey if a feature is not used.
Line charts require at least 3 data points before they start to show data.

Table 22-2 Analyzing System Health - Step by Step

Step	Description
Navigate to the home page for WebCenter Portal	Use Enterprise Manager Fusion Middleware Control to monitor the performance of your portal application. The best place to start is your application's home page. See Navigating to the Home Page for WebCenter Portal.
1 Check CPU and heap memory usage	Overall performance deteriorates when CPU or memory usage is too high so its important that you always look at the CPU and memory metrics before looking at any other Oracle WebCenter Portal-specific metric. Check the Recent CPU and Memory Usage charts to see the current usage trend: High CPU usage? Occasional spikes in CPU usage is normal but if CPU usage remains high (85-90%) over a long period of time, it normally indicates there is an issue with CPU. To troubleshoot CPU issues, see: Understanding WebLogic Server Metrics High memory usage? When the chart shows that memory is close to the maximum heap size and the trend is not downwards, take some memory dumps to further analyze the cause. To access maximum heap size information: 1. Log in to WebLogic Server Administration Console. 2. Navigate to: Environment> Servers> <managed_server name> 3. Click Monitoring> Performance tab. 4. Look at "Heap Size Max". See Troubleshooting Slow Requests Using JFR Recordings. Next Step: If the charts indicate that CPU and memory usages are normal, verify the health of the WebLogic Server.
2 Verify the health of WebLogic Server	Look in the WebLogic Server Metrics region: Health - The bar chart summarizes recent WebLogic Server health, as reported by the Oracle WebLogic Server self-health monitoring feature. For example, if 10 out of the last 100 WebLogic Server health checks fail (do not report OK), WebLogic Server health is shown as 90%. Click the Health link to navigate to more detail on the Recent WebLogic Server Metrics page. Incidents - The number of times WebLogic Server metrics, such as CPU usage, memory usage, thread count, number of JDBC connections, session metrics, and so on, exceed threshold settings. Click the Incidents link to diagnose incidents further. The actions you take next depend on the metric data. For example, if there are hogging threads, you can take thread dumps. If JDBC connections are exceeding limits, you can analyze further for connection leaks. If the garbage collection rate is exceeding limits, you can take heap dumps, an so on. For details, see Understanding WebLogic Server Metrics and Troubleshooting Oracle WebCenter Portal Performance Issues. Out-of-bound metrics show "red" in charts and "orange" in the Health Metrics table. Examine all occurrences of such situations by scanning the diagnostic logs. In-memory information is limited to "N" metric samples, but the logs store much more historical information about how often a problem is happening, as well as additional contextual information, such as which user. Here is sample message: [WC_Portal] [WARNING] [WCS-69252] [oracle.webcenter.system-management] [tid: oracle.webcenter.DefaultTimer] [ecid: 0000JhEX92mEgKG_Ix8Dyf1Ghz32000002,0] [APP: webcenter#11.1.1.4.0] wlsCpuUsage: 21.92100394175851 % of WebLogicServer is out-of-bounds Tip: You can use Fusion Middleware Control to locate all messages of this type by searching the message type, message code, and other string pattern details. See Viewing and Configuring Log Information. By default, a warning thresholds is only set for CPU Usage but you can configure thresholds for other key WebLogic Server metrics, such as Heap Memory Usage. See Configuring Thresholds for Key Metrics. Look at diagnostics logs for errors, failures, and any configuration or network issues. If an issue relates to another backend server, such as, WebCenter Content and SOA, verify the JVM/WebLogic Server health (CPU, heap, threads, and so on) for those managed servers too. Similarly, investigate WebLogic Server health for other managed servers in your WebCenter Portal installation such as `WC_Portlet` Next Step: If the charts indicate that WebLogic Server is performing within thresholds, verify the health of your WebCenter Portal application.
3 Monitor page performance	Look at the WebCenter Portal Metrics section at the top of the home page. Review the page availability/performance charts to see whether page requests are currently responding as expected. Drill down to more detail to investigate issues relating to recent page requests. Use the Sort Ascending/Descending arrows for the Time and Page Name columns to see whether a pattern is emerging for a specific page or set of pages, or whether performance spikes appear to be more random. Out-of-bound metrics show "red" in charts and "orange" in the Page Metrics table. For details, see Understanding Page Request Metrics. Examine all occurrences of such situations by scanning the diagnostic logs. In-memory information is limited to "N" metric samples, but the logs store much more historical information about how often a problem is happening, as well as additional contextual information, such as which user. Here is sample message: [WC_Portal] [WARNING] [WCS-69251] [oracle.webcenter.system-management] [tid: [ACTIVE].ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 6356ef0164cbad47:3fe105c5:13b4e847973:-8000-0000000000000031,0 ] [APP: webcenter#11.1.1.4.0] [DSID: 0000JhEYRT^EgKG_Ix8Dyf1Ghz32000005] pageResponseTime: 22223 ms of PersonalSpace/Activities is out-of-bounds Tip: You can use Fusion Middleware Control to locate all messages of this type by searching the message type, message code, and other string pattern details. See Viewing and Configuring Log Information. Identify individual pages that are not performing. For details, see How to Identify Slow Pages. Navigate to the "Overall Page Metrics" page to see how this page has performed historically (since startup, and last 10-15 minutes). Has it always been slow? For pages that are failing, see How to Troubleshoot Slow Page Requests.
4. Monitor portlet performance	Look at the WebCenter Portal Metrics section at the top of the home page. Review the portlet availability/performance charts to see whether portlets are currently performing as expected. Drill down to more detail to investigate issues relating to recent portlet requests. Out-of-bound metrics show "red" in charts and "orange" in the Portlet Metrics table. For details, see Understanding Portlet Producer Metrics. Out-of-bound conditions are also logged in managed server diagnostic logs so you can examine all historical events, that is, more that the most recent sample set that is held in memory. For example: [WC_Portal] [WARNING] [WCS-69253] [oracle.webcenter.system-management] [tid: pool-3-daemon-thread-1] [userId: weblogic] [ecid: 6356ef0164cbad47:3fe105c5:13b4e847973:-8000-0000000000000088,0 :16] [APP: webcenter#11.1.1.4.0] portletResponseTime: 20523 ms of Portlet: slowRenderingPortlet from Web Producer MyPortlets is out-of-bounds. Identify individual portlets or portlet producers that are not performing as expected. Navigate to the "Overall Service Metrics" page, and then select Portlet Producers or Portlets to see how these portlets/portlet producers have performed historically (since startup, and last 10-15 minutes). Has performance deteriorated recently or always been slow? If portlet performance is normally within thresholds: Verify JVM/WebLogic Server health for the managed server that is hosting the portlets (for example, `WC_Portlet`), that is, investigate CPU, heap, threads, and so on. Enter the portlet producer's URL in your browser to determine whether the producer is available. Review the portlet producer's connection configuration. Check for network connectivity issues between the WebCenter Portal application and the portlet producer. Simulate portlet operations in WebCenter Portal, that is, view, personalize, or interact with the portlet to verify whether the problem is pervasive or intermittent. Next Step: If the charts indicate that portlet requests are performing within thresholds, verify the performance of your LDAP server.
5. Monitor LDAP server performance	Look at the LDAP metrics in the Security section on the home page. When the server first starts up the cache hit ratio is zero and typically increases above 90% as the system warms up. For more information, see Understanding Security Metrics. Typically, the average LDAP lookup time is only a few milliseconds. If lookups are taking a long time there maybe a problem with the LDAP server or network relate issue. If you want to measure the response time from the LDAP server for a simple bind operation, run the command: `ldapbind -D "UserDN" -h ldaphost.example.com -p <port> -w <password>` If you are using Oracle Internet Directory, see Oracle Internet Directory Performance Tuning in Oracle Fusion Middleware Tuning Performance for advice on how to improve performance and avoid bottlenecks. For other LDAP servers, refer to the appropriate product documentation. Next Step: If your LDAP server is performing within thresholds, investigate other areas.
6. Monitor individual tools and services	Look at the WebCenter Portal Services section at the bottom of the home page. For details, see Understanding Tool and Service Metrics. Quickly see if a particular tool or service is "Down" or "Unknown". Refer to Troubleshooting Common Issues with Tools and Services for guidance on possible causes and actions. Sort the table by Average Time or Invocations to prioritize which tool or service to focus on. Click a name to navigate to the "Overall Service Metrics" page. Compare Since Startup and Recent History metrics to see if performance deteriorated recently or always been slow.

22.1.4 Understanding Some Common Performance Issues and Actions

If an Oracle WebCenter Portal metric is out-of-bounds, do the following:

Check system resources, such as memory, CPU, network, external processes, or other factors. See Troubleshooting Oracle WebCenter Portal.
Check other metrics to see if the problem is system-wide or only in a particular tool or service.
If the issue is related to a particular tool or component, then check if the back-end server is down or overloaded.
If the WebLogic Server has been running for a long time, compare the Since Startup metrics with the Recent History metrics to determine if performance has recently deteriorated, and if so, by how much.
When the status of a tool or service is Down or some operations do not work, then validate, test, and ping the back-end server through direct URLs. For details, refer to the "Testing Connection" section in the relevant chapter. For a list of chapters, see Administering Tools and Services.

When you reconfigure connections to tools and services you must always restart the managed server on which the WebCenter Portal application is deployed to pick up the changes. If key connection attributes change, such as a server's host/port details, connectivity to the server may be lost and the service may become unavailable until you reconfigure the connection and restart the managed server.

Note:

You can customize the threshold at which some key performance metrics trigger out-of-bound conditions. See Customizing Key Performance Metric Thresholds and Collection.

22.1.5 Understanding Page Request Metrics

You can monitor the availability and performance of page requests for WebCenter Portal through Fusion Middleware Control. You can monitor recent page data and historical (overall) page data.

This section includes the following information:

Note:

The page request metrics discussed in this section are different from the page operation metrics discussed in Page Operation Metrics. Page operation metrics monitor page related operations such as creating pages. Whereas the page request metrics described here monitor individual page view/display requests (do not include page edit operations).

22.1.5.1 Understanding Full Page and Partial Page Metrics

Performance data is collected for full page and partial page requests. Full page metrics do not include partial page metrics.

Partial page requests display only portions of the page. Therefore, you can monitor the performance of pages within a page. Partial page refresh behavior is called partial page rendering (PPR). PPR allows only certain components on a page to be rerendered without the need to refresh the entire page. A common scenario is when an output component displays what a user has chosen or entered in an input component. Similarly, a command link or button can cause another component on the page to be rerendered without refreshing the entire page.

Partial page rendering of individual components on a page only increases partial page metrics and does not cause any change in full page metrics. For example, a calendar refresh on a page increases partial page invocations by 1, but full page invocations remain unchanged.

For more information about PPR, see Rerendering Partial Page Content in Oracle Fusion Middleware Developing Web User Interfaces with Oracle ADF Faces.

22.1.5.2 Recent Page Metrics

Recent page availability and performance metrics are summarized on the home page for WebCenter Portal (Figure 22-2 and Table 22-3). The page availability/performance charts show at a glance if page requests are slower than expected or failing.

Note:

To access the home page, see Navigating to the Home Page for WebCenter Portal.

The Page Availability and Page Performance charts report availability and performance over the last 'N' page requests (by default, 'N' is 100). The time range starts with the earliest page/portlet request time and ends with the current time. See Configuring the Number of Samples Used to Calculate Key Performance Metrics.

The % value on the right shows the percentage of page requests that responded within a specific time limit. The percentage is calculated using information from the last 'N' page requests. For example, if 'N' is 100, and if 3 of the last 100 page requests exceeded the page response threshold, page performance is shown as 97%.

The bar chart status (green/red) does not change over time until the status changes, so the % performance value and the visual green/red ratio do not always match up. For example, consider a scenario where the first 5 page requests are "out of bounds", the system is idle (no page requests) for 9 hours, and then there are 95 "good" page requests within an hour. In this instance the chart displays 90% red (9 hours) and 10% green (1 hour) but the % performance value shows 95% ('N' is 100 and 95 samples out of 100 are "good"). The mismatch occurs because the bar charts plot uniformly over time, whereas page requests are not usually uniformly distributed over time.

Figure 22-2 Recent Page Summary on the WebCenter Portal Home Page

Description of "Figure 22-2 Recent Page Summary on the WebCenter Portal Home Page"

If the chart indicates issues or incidents, click the Page Availability or Page Performance link to navigate to more detailed information to diagnose the issue further (see Figure 22-3 and Table 22-3).

Use the information on the Recent Page Metrics page (Figure 22-3) to troubleshoot recent page performance issues. The page availability/performance charts at the top of the page show "red" if page requests are slower than expected or failing.

Note:

Out-of-the-box, the page response threshold is 10, 000ms so pages taking longer than 10, 000ms to respond show "red" in the chart. If this threshold is not suitable for your installation you can change the threshold value. See Customizing Key Performance Metric Thresholds and Collection.

Figure 22-3 Recent Page Metrics

Description of "Figure 22-3 Recent Page Metrics"

The charts report availability/performance over the last 'N' page requests. The time range starts with the earliest page request time and ends with the time of the last page request.

Use the information in the table to identify slow pages, that is, the name of the page and the portal to which the page belongs.

To diagnose page response issues, refer to the advice in "Step 3. Monitor page performance" in Table 22-2.

Table 22-3 Recent Page Request Metrics

Metric	Description
Availability	Indicates page availability over the last 'N' page requests: Green - Indicates successful page requests. Red - Indicates that a failure occurred during a page request. Look at the Status column in the table below to identify any page requests that fail. % - Percentage of page requests that succeeded. The percentage is calculated using status information from the last 'N' page requests. For example, if 'N' is 100 and 5 of the last 100 page requests failed, page availability is shown as 95%.
Performance	Indicates page performance over the last 'N' page requests: Green - Indicates acceptable page response times, that is, the time taken to respond is less than a predefined threshold. Red - Indicates page responses exceeding the limit set. For example, if your installation specifies the page response threshold to be 3, 000 ms, responses longer then 3, 000 ms trigger a warning message and an "out-of-bounds" condition is logged. Out-of-the-box, the page response threshold is 10, 000ms. Look at the Time column in the table below. Responses that exceed the threshold appear in orange. Click the Sort Descending arrow to identify the slowest pages. Open and examine slow pages to assess whether there is scope to improve page performance either by redesigning the page or modifying/removing page content. % - Percentage of page requests that responded within the time limit specified. The percentage is calculated using information from the last 'N' page requests. For example, if 'N' is 100, and 10 of the last 100 page requests exceeded the page response threshold, page performance is shown as 90%.
Date Time	Date and time page requested.
Page Name	Name of the page requested.
Portal Name	Name of the portal in which the page is stored.
Partial Page Refresh	Indicates whether the page request refreshed the whole page (`false`) or a part of the page (`true`).
Status	Indicates whether the page request was successful (Success) or failed (Failure). Failure displays in orange text.
Time (ms)	Time taken to refresh the page (full or partial), in milliseconds. If the time exceeds the predefined page response threshold, the value displays in "orange".

22.1.5.3 Overall Page Metrics

Historical performance metrics associated with page activity are also available as shown in Figure 22-4 and described in Table 22-4. This page displays metrics for both full and partial page requests and you can filter the data displayed to suit your requirements.

Note:

To access these metrics through Fusion Middleware Control, see Viewing Performance Metrics Using Fusion Middleware Control.

Figure 22-4 Overall Page Request Metrics

Description of "Figure 22-4 Overall Page Request Metrics"

The table at the top of this page summarizes the status and performance of individual pages. Use the table to quickly see which pages are available, and to review their individual and relative performances.

Statistics become available when a page is created and are updated every time someone accesses and uses the page.

Note:

Metrics for pages in the Home portal are not included.

Table 22-4 Page Request Metrics - Full Page and Partial Page

Field	Description
Display Options	Filter the data displayed in the table: Page Name Filter - Enter a full or partial search term, then click the Refresh icon to refresh the list with all pages for which a match is found in the page name. To display all pages, clear the search term and click Refresh again. Portal Name Filter - Enter a full or partial search term, then click the Refresh icon to refresh the list with all pages for which a match is found in the portal's display name. To display page metrics from all portals (previously referred to as spaces), clear the search term and click Refresh again. Maximum Rows - Restrict the total number of pages displayed in the table. Display - Display metrics for the most accessed pages, the slowest pages, or the pages experiencing the most errors. Depending on you selection, the table orders pages by: - Number of Invocations (Most Accessed Pages) - Average Page Processing Time (Slowest Pages) - Number of Errors (Pages with Most Errors) Duration - Display metric information collected since startup or in the last 15 minutes (Recent History). The top five pages display in the chart.
Page Name	Names of pages that match your filter criteria (if any). If you do not specify filter criteria, all the pages are listed.
Portal Name	Names of portals that match your filter criteria (if any). If you do not specify filter criteria, pages from all portals are listed.
Invocations	Total number of page invocations per minute (full or partial): - Since Startup - Last 15 Minutes
Average Time (ms)	Average time (in ms) to display the page (full or partial): - Since Startup - Last 15 Minutes
Maximum Time (ms)	Maximum time taken to display a page (full or partial):
Errors (Only for full page)	Number of errors that occurred for a page per minute.
Successful Invocations (Only for full page)	Percentage of page invocations that succeeded: - Since Startup - Last 15 Minutes If Successful Invocations (%) is below 100%, check the diagnostic logs to establish why page requests are failing. See Viewing and Configuring Log Information.
Pages per Minute	Number of times the page is accessed per minute, also referred to as page throughput: - Since Startup - Last 15 Minutes

Overall Page Request Metrics - Graphs

Use the graphs below the table to see, at a glance:

Invocations - Graph showing the most popular or least used pages, that is, pages recording the most or least invocations.
Page Throughput - Graph showing the average number of pages accessed per minute. Use this graph to identify pages with high (or low) hit rates.
Errors - Graph showing the number of errors. Use this graph to compare error rates.
Average Processing Time - Graph showing the average page response time (in milliseconds). Use this graph to identify pages with the best (or worst) performance.

To compare a different set of pages:

Specify the appropriate filtering criteria in the Page Name Filter.
Select one or more pages in the table, and then click Display in Chart.

22.1.6 Understanding Portlet Producer Metrics

You can monitor the availability and performance of all the portlets and portlet producers used by WebCenter Portal through Fusion Middleware Control. You can monitor recent and historical (overall) portlet data. The following topics describe the metrics that are available:

22.1.6.1 Recent Portlet Metrics

Recent portlet availability and performance metrics are summarized on the home page for WebCenter Portal (Figure 22-5 and Table 22-5). The portlet availability/performance charts show at a glance if portlet requests are slower than expected or failing.

Note:

To access the home page, see Navigating to the Home Page for WebCenter Portal.

The Portlet Availability and Portlet Performance charts report availability and performance over the last 'N' portlet requests (by default, 'N' is 100). The time range starts with the earliest page/portlet request time and ends with the current time. See Configuring the Number of Samples Used to Calculate Key Performance Metrics.

The % value on the right shows the percentage of portlet requests that responded within a specific time limit. The percentage is calculated using information from the last 'N' portlet requests. For example, if 'N' is 100, and if 25 of the last 100 portlet requests exceeded the portlet response threshold, portlet performance is shown as 75%. For more information, see Table 22-5.

The bar chart status (green/red) does not change over time until the status changes, so the % performance value and the visual green/red ratio do not always match up. An explanation for this is provided in Recent Page Metrics and the same applies to the portlet charts.

Figure 22-5 Recent Portlet Metric Summary on the WebCenter Portal Home Page

Description of "Figure 22-5 Recent Portlet Metric Summary on the WebCenter Portal Home Page"

If the chart indicates issues or incidents, click the Portlet Availability or Portlet Performance link navigate to more detailed information to diagnose the issue further (Figure 22-6 and Table 22-5).

Figure 22-6 Recent Portlet Metrics

Description of "Figure 22-6 Recent Portlet Metrics"

Use the information on this page to troubleshoot recent portlet performance issues. The portlet availability/performance charts at the top of the page show "red" if portlet requests are slower than expected or failing.

Note:

Out-of-the-box, the portlet response threshold is 10, 000ms so portlets taking longer than 10, 000ms to respond show "red" in the chart. If this threshold is not suitable for your installation you can change the threshold value. For more information, see Customizing Key Performance Metric Thresholds and Collection.

The charts report availability/performance over the last 'N' portlet requests. The time range starts with the earliest portlet request time and ends with the time of the last portlet request.

Use the information in the table to identify slow portlets. You can determine the name of the portlet and the producer to which the portlets belongs.

To diagnose portlet issues, refer to the advice in Step 5. Monitor portlet performance in Table 22-2.

Table 22-5 Recent Portlet Metrics

Metric	Description
Portlet Availability	Indicates portlet availability over the last 'N' portlet requests: Green - Indicates successful portlet requests. Red - Indicates that a failure occurred during a portlet request. Look at the Status column in the table below to identify any portlet requests that fail. % - Percentage of portlet requests that succeeded. The percentage is calculated using status information from the last 'N' portlet requests. For example, if 'N' is 100 and 5 of the last 100 portlet requests failed, portlet availability is shown as 95%.
Portlet Performance	Indicates portlet performance over the last 'N' portlet requests: Green - Indicates acceptable portlet response times, that is, the time taken to respond is less than a predefined threshold. Red - Indicates portlet responses exceeding the limit set. For example, if your installation specifies the portlet response threshold to be 60 ms, responses longer then 60 ms trigger a warning message and an "out-of-bounds" condition is logged. Out-of-the-box, the portlet response threshold is 10,000ms. Look at the Time column in the table below. Responses that exceed the threshold appear in orange. Click the Sort Descending arrow to identify the slowest portlets. Once you have the portlet's name, you can examine the portlet to assess how they might be modified to improve efficiency. % - Percentage of portlet requests that responded within the time limit specified. The percentage is calculated using information from the last 'N' portlet requests. For example, 'N' is 100, and 10 of the last 100 portlet requests exceeded the portlet response threshold, portlet performance is shown as 90%.
Date Time	Date and time of the portlet request.
Portlet Name	Name of the portlet requested.

22.1.6.2 Overall Portlet Producer Metrics

Historical performance metrics are also available for portlet producers used by WebCenter Portal, as shown in Figure 22-7. The information displayed on this page is described in the following tables:

Note:

To access these metrics through Fusion Middleware Control, see Viewing Performance Metrics Using Fusion Middleware Control.

Figure 22-7 Portlet Producer Metrics

Description of "Figure 22-7 Portlet Producer Metrics"

Table 22-6 Portlet Producers - Summary

Metric	Description
Status	The current status of portlet producers used in the application: Up (Green Up Arrow) - Indicates that all portlet producers are up and running. Down (Red Down Arrow) - Indicates that the one or more portlet producers are currently unavailable. A producer instance might be down, or there could be some network connectivity issues. Unknown (Clock) - Unable to query the status of the portlet producers for some reason. Maybe the managed server is down or the node cannot be reached due to a network issue. To diagnose further, review the Admin Server log, and the managed server logs.
Successful Invocations (%)	The percentage of portlet producer invocations that succeeded: - Since Startup - Last 15 Minutes Any request that fails will impact availability. This includes application-related failures such as timeouts and internal errors, and also client/server failures such as requests returned with response codes HTTP4xx or HTTP5xx, responses with a bad content type, and SOAP faults, where applicable. If Successful Invocations (%) is below 100%, check the diagnostic logs to establish why service requests are failing. See Viewing and Configuring Log Information.
Invocations	The number of portlet producer invocations per minute: - Since Startup - Last 15 Minutes This metric measures each application-related portlet request and therefore, due to cache hits, errors, or timeouts on the application, this total may be higher than the number of actual HTTP requests made to the producer server.
Average Time (ms)	The average time taken to make a portlet request, regardless of the result: - Since Startup - Last 15 Minutes

Table 22-7 Portlet Producer - Detail

Metric	Description
Most Popular Producers	The number of invocations per producer (displayed on a chart). The highest value on the chart indicates which portlet producer is used the most. The lowest value indicates which portlet producer is used the least.
Response Time	The average time each portlet producer takes to process producer requests since WebCenter Portal started up (displayed on a chart). The highest value on the chart indicates the worst performing portlet producer. The lowest value indicates which portlet producer is performing the best.
Producer Name	The name of the portlet producer being monitored. Click the name of a portlet producer to pop up more detailed information about each portlet that the application uses. See Table 22-9.
Status	The current status of each portlet producer: Up (Green Up Arrow) - Indicates that the portlet producer is up and running. Down (Red Down Arrow) - Indicates that the portlet producer is currently unavailable. The producer instance might be down, or there could be some network connectivity issues. Unknown (Clock) - Unable to query the status of portlet producer for some reason.
Producer Type	The portlet producer type: Web or WSRP Web portlet producer - Oracle PDK Java producer deployed to a J2EE application server, which is often remote and communicates through Simple Object Access Protocol (SOAP) over HTTP. WSRP portlet producer - Web Services for Remote Portlets (WSRP) is a Web services standard that allows interoperability between a standards enabled container and any WSRP application.
Successful Invocations (%)	The percentage of producer invocations that succeeded: - Since Startup - Last 15 Minutes
Invocations	The number of invocations, per producer: - Since Startup - Last 15 Minutes By sorting the table on this column, you can find the most frequently accessed portlet producer in WebCenter Portal.
Average Time (ms)	The average time taken to make a portlet request, regardless of the result: - Since Startup - Last 15 Minutes Use this metric to detect non-functional portlet producers. If you use this metric with the Invocations metric, then you can prioritize which producer to focus on.
Maximum Time (ms)	The maximum time taken to process producer requests: - Successes - HTTP200xx response code - Re-directs - HTTP300xx response code - Client Errors - HTTP400xx response code - Server Errors - HTTP500xx response code

22.1.6.3 Overall Portlet Metrics

Historical performance metrics are available for individual portlets used by WebCenter Portal, as shown in Figure 22-8. The information displayed on this page is described in the following tables:

Note:

To access these metrics through Fusion Middleware Control, see Viewing Performance Metrics Using Fusion Middleware Control.

Figure 22-8 Portlet Metrics

Description of "Figure 22-8 Portlet Metrics"

Table 22-8 Portlets - Summary

Metric	Description
Status	The current status of portlets used in WebCenter Portal: Up (Green Up Arrow) - Indicates that all portlets are up and running. Down (Red Down Arrow) - Indicates that the one or more portlets are currently unavailable. A producer instance might be down, or there could be some network connectivity issues. For other causes, see Portlets and Producers - Issues and Actions. Unknown (Clock) - Unable to query the status of portlets for some reason. Maybe the managed server is down or the node cannot be reached due to a network issue. To diagnose further, review the Admin Server log, and the managed server logs.
Successful Invocations (%)	The percentage of portlet invocations that succeeded: - Since Startup - Last 15 Minutes Any request that fails will impact availability. This includes application-related failures such as timeouts and internal errors, and also client/server errors. If Successful Invocations (%) is below 100%, check the diagnostic logs to establish why service requests are failing. See Viewing and Configuring Log Information.
Invocations	The number of portlet invocations per minute: - Since Startup - Last 15 Minutes This metric measures each application-related portlet request and therefore, due to cache hits, errors, or timeouts on the application, this total may be higher than the number of actual HTTP requests made to the portlet producer.
Average Time (ms)	The average time taken to process operations associated with portlets, regardless of the result: - Since Startup - Last 15 Minutes

Table 22-9 Portlet - Detail

Metric	Description
Most Popular Portlets	The number of invocations per portlet (displayed on a chart). The highest value on the chart indicates which portlet is used the most. The lowest value indicates which portlet is used the least.
Response Time	The average time each portlet takes to process requests since WebCenter Portal started up (displayed on a chart). The highest value on the chart indicates the worst performing portlet. The lowest value indicates which portlet is performing the best.
Portlet Name	The name of the portlet being monitored.
Status	The current status of each portlet: Up (Green Up Arrow) - Indicates that the portlet is up and running. Down (Red Down Arrow) - Indicates that the portlet is currently unavailable. The producer instance might be down, or there could be some network connectivity issues.
Producer Name	The name of the portlet producer through which the portlet is accessed.
Producer Type	The portlet producer type: Web or WSRP Web portlet producer - Oracle PDK Java producer deployed to a J2EE application server, which is often remote and communicates through Simple Object Access Protocol (SOAP) over HTTP. WSRP portlet producer - Web Services for Remote Portlets (WSRP) is a Web services standard that allows interoperability between a standards enabled container and any WSRP application.
Successful Invocations (%)	The percentage of portlet invocations that succeeded: - Since Startup - Last 15 Minutes If Successful Invocations (%) is below 100%, check the diagnostic logs to establish why service requests are failing. See Viewing and Configuring Log Information.
Invocations	The number of invocations, per portlet: - Since Startup - Last 15 Minutes By sorting the table on this column, you can find the most frequently accessed portlet in WebCenter Portal.
Average Time (ms)	The average time each portlet takes to process requests, regardless of the result: - Since Startup - Last 15 Minutes Use this metric to detect non-performant portlets. If you use this metric with the Invocations metric, then you can prioritize which portlet to focus on.
Maximum Time (ms)	The maximum time taken to process portlet requests: - Successes - HTTP200xx - Redirects - HTTP300xx - Client Errors - HTTP400xx - Server Errors - HTTP500xx The breakdown of performance statistics by HTTP response code can help you identify which factors are driving up the total average response time. For example, failures due to portlet producer timeouts would adversely affect the total average response time.

Table 22-10 Portlet - HTTP Response Code Statistics

Metric	Description
Portlet Name	The name of the portlet being monitored.
Invocations Count - Successes - Redirects - Client Errors - Server Errors	The number of invocations, by type (HTTP response code): - Since Startup - Last 15 Minutes See Table 22-11.
Average Time (ms) - Successes - Redirects - Client Errors - Server Errors	The average time each portlet takes to process requests: - Since Startup - Last 15 Minutes Use this metric to detect non-functional portlets. If you use this metric with the Invocations metric, then you can prioritize which portlet to focus on.

Metric

Description

Portlet Name

The name of the portlet being monitored.

Invocations Count

- Successes

- Redirects

- Client Errors

- Server Errors

The number of invocations, by type (HTTP response code):

- Since Startup

- Last 15 Minutes

See Table 22-11.

Average Time (ms)

- Successes

- Redirects

- Client Errors

- Server Errors

The average time each portlet takes to process requests:

- Since Startup

- Last 15 Minutes

Use this metric to detect non-functional portlets. If you use this metric with the Invocations metric, then you can prioritize which portlet to focus on.

Table 22-11 HTTP Response Codes

HTTP Response and Error Code	Description
200 -Successful Requests	Portlet requests that return any HTTP2xx response code, or which were successful without requiring an HTTP request to the remote producer, for example, a cache hit.
300 -Unresolved Redirections	Portlet requests that return any HTTP3xx response code.
400 -Unsuccessful Request Incomplete	Portlet requests that return any HTTP4xx response code.
500 -Unsuccessful Server Errors	Portlet requests that failed for any reason, including requests that return HTTP5xx response codes, or which failed due to a application-related error, timeout, bad content type response, or SOAP fault.

22.1.7 Understanding WebLogic Server Metrics

Recent WebLogic Server performance is summarized on the home page for WebCenter Portal (Figure 22-9 and Table 22-12). If the chart indicates issues or incidents, you can navigate to more detailed information to diagnose the issue further.

Note:

To access the home page, see Navigating to the Home Page for WebCenter Portal.

Figure 22-9 Recent WebLogic Server Metric Summary on the Home Page

Description of "Figure 22-9 Recent WebLogic Server Metric Summary on the Home Page"

The charts report results from the last WebLogic Server 100 health checks. By default, metrics are recorded every five minutes so data collected over the last 8 hours can display here. If the server started up recently, the chart displays data from the time the server started to the current time.

Note:

If required, you can customize the metric collection frequency to better suit your installation. For details, see Customizing Key Performance Metric Thresholds and Collection.

Table 22-12 Recent WebLogic Server Metrics on the Home Page

Metric	Description
Health	Summarizes recent WebLogic Server health as reported by the Oracle WebLogic Server self-health monitoring feature. This metric considers recent server health, thread health, and JDBC health: Green - Indicates successful WebLogic Server health checks. Red - Indicates that an incident occurred during a WebLogic Server health check. Click Health to identify health checks that fail (do not report OK). See Figure 22-10. % - Percentage of WebLogic Server health checks that succeeded. By default, the percentage is calculated using status information from the last 100 health checks. For example, if 5 of the last 100 health checks fail (do not report OK), Health is shown as 95%.
Incidents	Number of times WebLogic Server metrics exceed threshold settings (that is, metrics such as CPU usage, memory usage, thread count, number of JDBC connections, session metrics, and so on). For example, if the metric data set contains 2 incidents where thread count exceeded the predefined threshold and the number of JDBC connections exceeded the threshold limit 3 times, then the number of incidents displayed is 5. When the number of incidents is greater than 0, an icon with a red cross displays. Click the Incidents link to drill down to the Recent WebLogic Server Metrics Page (Figure 22-9) and examine the Health Metrics table to diagnose the incidents further.

Metric

Description

Health

Summarizes recent WebLogic Server health as reported by the Oracle WebLogic Server self-health monitoring feature. This metric considers recent server health, thread health, and JDBC health:

Green - Indicates successful WebLogic Server health checks.
Red - Indicates that an incident occurred during a WebLogic Server health check.

Click Health to identify health checks that fail (do not report OK). See Figure 22-10.
% - Percentage of WebLogic Server health checks that succeeded. By default, the percentage is calculated using status information from the last 100 health checks. For example, if 5 of the last 100 health checks fail (do not report OK), Health is shown as 95%.

Incidents

Number of times WebLogic Server metrics exceed threshold settings (that is, metrics such as CPU usage, memory usage, thread count, number of JDBC connections, session metrics, and so on).

For example, if the metric data set contains 2 incidents where thread count exceeded the predefined threshold and the number of JDBC connections exceeded the threshold limit 3 times, then the number of incidents displayed is 5.

When the number of incidents is greater than 0, an icon with a red cross displays. Click the Incidents link to drill down to the Recent WebLogic Server Metrics Page (Figure 22-9) and examine the Health Metrics table to diagnose the incidents further.

You can click Health or Incidents to drill down to the Recent WebLogic Server Metrics Page (Figure 22-9). The metrics displayed on this page are described in the following topics:

Figure 22-10 Recent WebLogic Server Metrics Page

Description of "Figure 22-10 Recent WebLogic Server Metrics Page"

22.1.7.1 WebLogic Server Metrics Section

Metric	Description
General
Up Since	Date and time the server last started up.
State	Current lifecycle state of this server.For example, a server can be in a RUNNING state in which it can receive and process requests or in an ADMIN state in which it can receive only administrative requests. For more information, see Understanding Server Life Cycle in Oracle Fusion Middleware Administering Server Startup and Shutdown for Oracle WebLogic Server.
Health	Health status of the server, as reported by the Oracle WebLogic Server self-health monitoring feature. For example, the server can report if it is overloaded by too many requests, if it needs more memory resources, or if it will soon fail for other reasons. For more information, see Configure health monitoring in Oracle WebLogic Server Administration Console online help.
CPU Usage (%)	Percentage of the CPU currently in use by the Java Virtual Machine (JVM). This includes the load that the JVM is placing on all processors in the host computer. For example, if the host uses multiple processors, the value represents a snapshot of the average load on all the processors.
Heap Usage (MB)	Size of the memory heap currently in use by the Java Virtual Machine (JVM), in megabytes.
Java Vendor	Name of the company that provided the current Java Development Kit (JDK) on which the server is running.
Java Version	Version of the JDK on which the current server is running.
Performance
Garbage Collection Rate (per min)	Rate (per minute) at which the Java Virtual Machine (JVM) is invoking its garbage-collection routine. By default, this metric shows the rate recorded in the last five minutes. See Configuring the Frequency of WebLogic Server Health Checks.
Average Garbage Collection Time (ms)	Average length of time (ms) the Java Virtual Machine spent in each run of garbage collection. The average shown is for the last five minutes. By default, this metric shows the average over the last five minutes. See Configuring the Frequency of WebLogic Server Health Checks.
Active Execute Threads	Number of active execute threads in the pool.
Execute Threads Idle Count	Number of idle threads in the pool. This count does not include standby threads or stuck threads. The count indicates threads that are ready to pick up new work when it arrives.
Hogging Execute Threads	Number of threads that are being held by a request right now. These threads will either be declared as stuck after a configured timeout or return to the pool. The self-tuning mechanism backfills if necessary.
Active Sessions	Number of active sessions for the application.
Open JDBC Sessions	Number of JDBC connections currently open.
Incidents	Number of times WebLogic Server metrics exceed threshold settings (that is, metrics such as CPU usage, memory usage, thread count, number of JDBC connections, session metrics, and so on). For example, if the metric data set contains 2 incidents where thread count exceeded the predefined threshold and the number of JDBC connections exceeded the threshold limit 3 times, then the number of incidents displayed is 5. When the number of incidents is greater than 0, an icon with a red cross displays.
Health	Summarizes recent health status, as reported by the Oracle WebLogic Server self-health monitoring feature. The Health charts report results from the last 100 performance checks. By default, metrics are recorded every five minutes so data collected over the last 500 minutes displays. If the server started up recently, the chart displays data from the time the server started to the current time. Green - Indicates successful health checks, that is, checks that return "OK". Red - Indicates that a health check returned a status other than "OK". For example, if all threads in the default queue become stuck, server health state changes to "CRITICAL". Similarly, if all threads in `weblogic.admin.HTTP,` `weblogic.admin.RMI`, or a user-defined execute queue become stuck, server health state changes to "WARNING". To identify failed health checks, review the Health Metrics Section at the bottom of the page. % - Percentage of health checks that succeeded (OK). The percentage is calculated using status information from the last 100 health checks. For example, if 5 of the last 100 thread health checks fail, thread health is shown as 95%.
WebLogic Server	Reports recent WebLogic Server health checks. For example, if 10 out of the last 100 WebLogic Server health checks failed (not "OK"), WebLogic Server health is shown as 90%.
Thread	Reports recent thread health checks. For example, if 10 out of the last 100 WebLogic Server health checks report a thread health status other than "OK", WebLogic Server thread health is shown as 90% Some example thread health failures include: If all threads in the default queue become stuck, server health state changes to "CRITICAL". If all threads in `weblogic.admin.HTTP,` `weblogic.admin.RMI`, or a user-defined execute queue become stuck, server health state changes to "WARNING".
JDBC	Reports recent JDBC health checks. For example, the server can report too many JDBC connection requests. If 10 out of the last 100 WebLogic Server health checks report a JDBC health status other than "OK", WebLogic Server JDBC health is shown as 90%.

22.1.7.2 Recent CPU and Memory Usage Section

This graph charts CPU and memory utilization for the Java Virtual machine over the the last 100 health checks.The time range starts with the earliest health check and ends with the time of the last health check.

From this performance graph, you will be able to tell how much of the memory/CPU configured for the virtual machine is actually being used and whether the trend is increasing. This might reveal to you that the applications running inside that virtual machine need more memory than the virtual machine has been assigned and that adding more memory to the virtual machine -- assuming that there is sufficient memory at the host level -- might improve performance. Similarly, you can assess whether additional CPU resources are required.

Metric	Description
CPU Usage (%)	Percentage of the CPU currently in use by the Java Virtual Machine (JVM). This includes the load that the JVM is placing on all processors in the host computer. For example, if the host uses multiple processors, the value represents a snapshot of the average load on all the processors.
Heap Usage (MB)	Size of the memory heap currently in use by the Java Virtual Machine (JVM), in megabytes.

Metric

Description

CPU Usage (%)

Percentage of the CPU currently in use by the Java Virtual Machine (JVM). This includes the load that the JVM is placing on all processors in the host computer.

For example, if the host uses multiple processors, the value represents a snapshot of the average load on all the processors.

Heap Usage (MB)

Size of the memory heap currently in use by the Java Virtual Machine (JVM), in megabytes.

22.1.7.3 Recent Session and Thread Usage Section

This graph charts the number of active sessions and active threads recorded over the last 100 health checks.The time range starts with the earliest health check and ends with the time of the last health check.

The number of active sessions and threads should rise and fall with the load on your system. If the graph shows a sudden rise or the number of sessions or threads keep increasing, investigate the issue further to understand what triggered the change in behavior.

Metric	Description
Active Sessions	Number of active sessions for the application.
Active Thread	Number of active threads for the application.

22.1.7.4 Recent JDBC Usage Section

This graph charts the number of open JDBC sessions recorded over the last 100 health checks. The time range starts with the earliest health check and ends with the time of the last health check.

The Current Active Connection Count metric across all the data sources belonging to the server are used to calculate the overall open JDBC session count displayed here.

Use this chart to determine the number of JDBC sessions being used and to see whether the system is leaking JDBC resources. You can use the information in this chart to assess whether JDBC configuration or the connection pool size needs to be adjusted.

22.1.7.5 Health Metrics Section

This table displays data from the last 100 WebLogic Server health metrics collected, as reported by the Oracle WebLogic Server self-health monitoring feature.

Metric	Description
Date Time	Date and time of the WebLogic Server health check.
Server Health	Sever health status, as reported by the Oracle WebLogic Server self-health monitoring feature. Successful health checks return "OK". Unsuccessful health checks report various failures, for example, the server can report if it is overloaded by too many requests, if it needs more memory resources, or if it will soon fail for other reasons. For more information, see Configure health monitoring in Oracle WebLogic Server Administration Console online help.
Thread Health	Thread health status, as reported by the Oracle WebLogic Server self-health monitoring feature. Successful health checks return "OK". Unsuccessful thread checks report various failures, for example, if all the threads in the default queue become stuck, server health state changes to "CRITICAL". If all threads in `weblogic.admin.HTTP`, `weblogic.admin.RMI`, or a user-defined execute queue become stuck, server health state changes to "WARNING". For more information, see Configure health monitoring in Oracle WebLogic Server Administration Console online help.
JDBC Health	JDBC health status, as reported by the Oracle WebLogic Server self-health monitoring feature. Successful health checks return "OK". Unsuccessful JDBC checks report various failures, for example, if the server reports too many JDBC connection requests or that more memory resources are required, server health state changes to "WARNING". For more information, see Configure health monitoring in Oracle WebLogic Server Administration Console online help.
Server CPU (%)	If you are using the Oracle JRockit JDK, this metric shows the percentage of the CPU currently in use by the Java Virtual Machine (JVM). This includes the load that the JVM is placing on all processors in the host computer. For example, if the host uses multiple processors, the value represents a snapshot of the average load on all the processors.
Heap Usage (MB)	Total heap memory (in MB) currently in use by the JVM.
Average Garbage Collection Time (ms)	Average length of time (ms) the Java Virtual Machine spent in each run of garbage collection. The average shown is for the last five minutes. By default, this metric shows the average over the last five minutes. See Configuring the Frequency of WebLogic Server Health Checks.
Garbage Collection Rate (per min)	Rate (per minute) at which the Java Virtual Machine (JVM) is invoking its garbage-collection routine. By default, this metric shows the rate recorded in the last five minutes. See Configuring the Frequency of WebLogic Server Health Checks.
Active Sessions	Number of active sessions for the application.
Active Execute Threads	Number of active execute threads in the pool.
Execute Threads Idle Count	Number of idle threads in the pool. This count does not include standby threads or stuck threads. The count indicates threads that are ready to pick up new work when it arrives.
Hogging Thread Count	Number of threads that are being held by a request right now. These threads will either be declared as stuck after a configured timeout or return to the pool. The self-tuning mechanism backfills if necessary.
Open JDBC Connections	Number of JDBC connections currently open.

22.1.8 Understanding Security Metrics

Some key security-related performance metrics are displayed for WebCenter Portal on the home page (Figure 22-11 and Table 22-13).

Note:

To access the home page, see Navigating to the Home Page for WebCenter Portal.

Figure 22-11 Security Metrics on the Home Page

Description of "Figure 22-11 Security Metrics on the Home Page"

If you compare Since Startup metrics with Recent History metrics you can determine whether performance has recently deteriorated, and if so, by how much.

Table 22-13 Security Metrics

Metric	Description
LDAP Cache Hit Ratio (%)	Percentage of LDAP searches that result in a cache hit.
Average LDAP Lookup Time (ms)	Average time to complete an LDAP search request: - Since Startup - Last 15 Minutes^Foot 1 If LDAP searches are taking too long, its most likely an issue on the LDAP server that is causing slow response times. If you are using Oracle Internet Directory, see Oracle Internet Directory Performance Tuning in Oracle Fusion Middleware Tuning Performance for advice on how to improve performance and avoid bottlenecks. For other LDAP servers, refer to the appropriate product documentation.

Metric

Description

LDAP Cache Hit Ratio (%)

Percentage of LDAP searches that result in a cache hit.

Average LDAP Lookup Time (ms)

Average time to complete an LDAP search request:

- Since Startup

- Last 15 Minutes^Foot 1

If LDAP searches are taking too long, its most likely an issue on the LDAP server that is causing slow response times. If you are using Oracle Internet Directory, see Oracle Internet Directory Performance Tuning in Oracle Fusion Middleware Tuning Performance for advice on how to improve performance and avoid bottlenecks. For other LDAP servers, refer to the appropriate product documentation.

^Footnote 1

The last 10-15 minutes of data is used to calculate recent performance metrics. For details, seeUnderstanding Oracle WebCenter Portal Metric Collection .

22.1.9 Understanding Page Response and Load Metrics

The page response chart on your application's home page (Figure 22-11) shows you how quickly WebLogic Server is responding to page requests and how many requests are being processed (its load).

The average page processing time (in ms) for all portals, is calculated over a 15 minute period. The number of invocations per minute is also displayed to help you determine whether the average page processing time is increasing or decreasing. If slower page processing times are due to a large number of users accessing the system, an increase in invocations per minute will display on the graph. If the number of users has not increased (the invocations per minute graph is not increasing or fluctuating), then slower page processing times are most likely due to machine resource issues or lack of JVM resources (low memory, contention for database connections, and so on).

Click Table View to see detailed response and load values, recorded at 5 minute intervals.

Note:

To access the home page, see Navigating to the Home Page for WebCenter Portal.

Figure 22-12 Page Response Metrics on the Home Page

Description of "Figure 22-12 Page Response Metrics on the Home Page"

If you compare Since Startup metrics with Recent History metrics (last 15 minutes), you can determine whether performance has recently deteriorated, and if so, by how much.

22.1.10 Understanding Portal Metrics

(WebCenter Portal only) You can view live performance metrics for individual portals through Fusion Middleware Control, as shown in Figure 22-13. The metrics displayed on this page are described in Table 22-14 and Metrics Common to all Tools and Services.

Note:

Metrics for the Home portal are not included.

Figure 22-13 Portal Metrics

Description of "Figure 22-13 Portal Metrics"

To monitor these metrics through Fusion Middleware Control, see Viewing Performance Metrics Using Fusion Middleware Control.

The table at the top of this page summarizes the status and performance of individual portals. Use the table to quickly see which portals are up and running, and to review their individual and relative performances.

Statistics become available when a portal is created and are updated every time a member accesses and uses the portal.

You can filter the data displayed in the following ways:

Portal Name Filter - Enter a full or partial search term, and then press Enter to refresh the list with all portals for which a match is found in the display name. To display metrics for all portals, clear the search term and press Enter again.
Maximum Rows - Restrict the total number of portals displayed in the table.
Display - Display metrics for the most accessed portals, the slowest portals, or the portals experiencing the most errors. Depending on you selection, the table orders portals by:

- Number of Invocations (most accessed portals)

- Average Page Processing Time (slowest portals)

- Number of Errors (portals with most errors)
Duration - Display metric information collected since startup or in the last 15 minutes (Recent History).

The top five portals display in the chart.

Table 22-14 Portal Metrics

Metric	Description
Name	Names of portals that match your filter criteria (if any). If you do not specify filter criteria, all the portals are listed.
Status	Current status of each portal: Up (Green Up Arrow) - Indicates that the last portal operation was successful. The portal is up and running. Down (Red Down Arrow) - Indicates that the portal is not currently available or the last portal operation was unsuccessful due to an unexpected error or exception. User errors, such as an authentication failure, do not change the status to "Down". Unavailable (Clock) - Status information is currently unavailable.
Invocations	Total number of portal invocations: - Since Startup - Last 15 Minutes
Errors	Number of errors recorded.
Successful Invocations (%)	Percentage of portal invocations that succeeded: - Since Startup - Last 15 Minutes If Successful Invocations (%) is below 100%, check the diagnostic logs to establish why portal requests are failing. See Viewing and Configuring Log Information.
Page Throughput	The average number of pages processed per minute for each portal: - Since Startup - Last 15 Minutes
Average Time (ms)	The average time (in ms) to display pages in the portal: - Since Startup - Last 15 Minutes
Maximum Time (ms)	Maximum time taken to display a page in the portal.
Minimum Time (ms)	Minimum time taken to display a page in the portal.

Portal Metrics - Graphs

Use the graphs below the table to see information about portals:

Invocations - Graph showing the most active/popular portals, that is, portals recording the most invocations.
Page Throughput - Graph showing the average number of pages accessed per minute for each portal. Use this graph to identify portals with high (or low) page hit rates.
Average Processing Time - Graph showing the average page response time (in milliseconds). Use this graph to identify portals with the best (or worst) page performance.
Errors - Graph showing which portals are reporting the most errors. Use this graph to compare error rates.

To compare a different set of portals:

Specify the appropriate filtering criteria.
Select one or more portals in the table, and then click Display in Chart.

22.1.11 Understanding Tool and Service Metrics

This section includes the following topics:

22.1.11.1 Metrics Common to all Tools and Services

Fusion Middleware Control provides capabilities to monitor performance of tools and services used in WebCenter Portal in the following ways:

Services summary: Summary of performance metrics for each tool or service used in WebCenter Portal. Table 22-15 lists tools and services that use common performance metrics and Table 22-16 describes the common metrics.
Most popular operations and response time for individual operations. Table 22-17 describes these metrics.
Per operation metrics: Performance metrics for individual operations. Table 22-15 lists common performance metrics used to monitor performance of individual operations. Table 22-17 describes these metrics.

Table 22-15 Common Metrics for Tools and Services

Tool or Service	Services Summary (Since Startup and Last 15 Minutes)	Per Operation Metrics (Since Startup and Last 15 Minutes)
Announcements	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
SOA Server	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	Not applicable
Discussion Forums	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
External Applications	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Events	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Import/Export	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Instant Messaging and Presence (IMP)	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Lists	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Mail	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Notes	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
Pages	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
People Connections	The performance metrics include: Average Processing Time (ms) Invocations Successful Invocations (%)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)
RSS	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	Not available
Search	The performance metrics include: Status Successful Invocations (%) Invocations Average Time (ms)	The performance metrics include: Most Popular Operations Response Time Successful Invocations (%) Invocations Average Time (ms) Maximum Time (ms) (Since Startup only)

Tool or Service

Services Summary (Since Startup and Last 15 Minutes)

Per Operation Metrics (Since Startup and Last 15 Minutes)

Announcements