| Oracle® Enterprise Manager Oracle Fusion Middleware Metric Reference Manual, 11g Release 1 (11.1.0.1) E18807-01 |
|
 Previous |
 Next |
| Oracle® Enterprise Manager Oracle Fusion Middleware Metric Reference Manual, 11g Release 1 (11.1.0.1) E18807-01 |
|
Previous |
Next |
This chapter describes Oracle Portal metrics.
This category provides information about portlets metrics.
This category provides information about portlets (Top 5) metrics.
This category provides information about producers metrics.
This metric specifies the rate of cache hits from a producer.
This metric specifies the average time in executing portlet calls for a producer.
This metric specifies the rate of requests per minute that are getting serviced from a producer.
This metric measures the availability of a producer, and measures the percent of requests that got an HTTP-2xx response from a producer.
This category provides information about producers (Top 5) metrics.
This category provides information about portal cache metrics.
This metric specifies the average time for cache hits in the Portal cache for content that uses "Expires-based caching".
This metric specifies the percentage of requests that resulted in successful cache hits, for content that does "Expiry-based caching".
This metric specifies the average time for cache misses in the Portal cache for content that is newly created in the cache.
This metric specifies the percentage of requests for which new content was generated and cached. New content was generated because there were cache misses due to content not being in the Portal Cache.
This metric specifies the average time for cache hits in the Portal cache for content that uses "Ping-based caching".
This metric specifies the percentage of requests that resulted in successful cache hits for content that requires ping checks.
This metric specifies the rate per minute of requests to the Portal Cache.
This metric specifies the average time for cache misses in the Portal cache for content that is stale and requires re-generation.
This metric specifies the percentage of requests that resulted in cache misses because the content cached in the Portal Cache was not the latest.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
Use this metric to assess the caching statistics of your pages or content and to understand how frequently cached content is becoming stale due to content editing. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
This category provides information about database connection pool statistics.
This metric provides the average time spent by Portal in acquiring a database connection - either by creating a fresh connection to the database or by acquiring a connection from the connection pool.
This metric provides the rate of incoming requests that require a database connection
This metric indicates the effectiveness of the Portal connection pool by measuring the percentage of Portal database connection pool hit rate.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If this value is low, check the:
setting for the PlsqlMaxRequestsPerSession connection pooling parameter. If the setting for this parameter is too low, the pooled connection may be discarded based on the property setting.
"Database Repository Response Code Statistics" metrics to see if there are too many error responses. Some database error responses may cause a pooled connection to be discarded.
database logs to find out if there are any server side crashes.
This metric indicates the effectiveness of the Portal connection pool by measuring the percentage rate of creating new database connections in Portal.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If this value is low, check the:
setting for the PlsqlMaxRequestsPerSession connection pooling parameter. If the setting for this parameter is too low, the pooled connection may be discarded based on the property setting.
"Database Repository Response Code Statistics" metrics to see if there are too many error responses. Some database error responses may cause a pooled connection to be discarded.
database logs to find out if there are any server side crashes.
This metric indicates the effectiveness of the Portal connection pool by providing the percentage rate of discarding pooled database connections.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If this value is low, check the:
setting for the PlsqlMaxRequestsPerSession connection pooling parameter. If the setting for this parameter is too low, the pooled connection may be discarded based on the property setting.
"Database Repository Response Code Statistics" metrics to see if there are too many error responses. Some database error responses may cause a pooled connection to be discarded.
database logs to find out if there are any server side crashes.
This category provides information about database repository response code statistic metrics.
This metric provides the rate per minute for generating a HTTP response code, and is a measure of how frequently a particular HTTP response code is generated.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
Use this value along with the "Average Response Time" value to assess the number of requests that are generating a particular HTTP response code and to assess the total time spent on it. For example, charting some of the typical failure codes like HTTP-404, HTTP-500, HTTP-503 and so on enables the assessment of the failure rate.
This metric provides the average response time for generating a response code.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
Use this value along with the "Responses (per minute)" value to assess the time taken in generating a response. If the average response time is not within bounds, or if the total time taken in generating a response code is high, investigate further to find out why. For example, if the time taken to get a response from the database is consistently high, then it is possible that the database is under too much load or it is not performing too well because of some SQL*queries. SQL*Profiling and SQL*Trace maybe enabled to help identify the issue.
This category provides information about page engine statistic metrics.
This metric provides the average time all internal PPE requests spent in the PPE internal request queue.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If the average time is high, analyze why existing PPE threads are not being released to take on work from the PPE internal queue. Assess the page caching options and analyze the performance of system and network resources. Consider tweaking the number of the PPE fetcher threads or having a new container. Make sure that increasing the number of threads does not impact performance.
This metric specifies the average time taken to generate the pages and also retrieve the page metadata.
This metric specifies the rate of pages per minute generated by the Parallel Page Engine
This metric specifies the average time taken to retrieve the page metadata.
This metric specifies the page metadata throughput per-minute.
This metric specifies the average time spent in the PPE internal request queue waiting for page metadata.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
This value maybe high because the system is under heavy load. The value may also be high because the requests are waiting for the PPE request threads to become available. In this case, use the "poolSize" configuration setting to increase the size of the thread pool. Default pool size is 25.
This metric specifies the rate per minute of the number of requests for Portal data that have timed out in the PPE internal request queue.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If this value is out-of-bounds, use the diagnostic logs to get details on specific page or content requests that are timing out. Analyze the log details to identify any pattern for the timeout. Some common reasons for timeout are listed below.
Timeout is encountered around peak load times. This maybe because the system is not setup to take the load, the pages/content are not responsive enough to meet the performance criteria, or the pages/contents are not optimized for best performance by enabling caching.
Timeout is always for a particular portlet or set of portlets. Evaluate the backend producer and its load and response characteristics.
Same page times out most of the times. This typically is indicative of some attributes of the page. Analyze the page and its contents, and optimize caching. See "Improving Page Performance" chapter in "User's Guide for Oracle Portal" document in OTN for performance tuning information.
Timeouts may occur because of performance blocks in resources like the CPU/memory/resources of the instances such as the middle-tier, database, producer nodes and so on. Monitor these resources for such blocks.
Timeout may occur while connecting to the remote nodes or there maybe delays due to network connectivity issues.
Timeout may occur due to improper system and network configuration.
If all aspects of the system and network are setup properly, consider increasing the number of fetcher threads in the PPE or adding another node in the cluster. However, this option should be done only if other components can take on the load added by the additional fetcher threads. If the backend producer cannot handle the existing load, then adding more fetcher threads or cluster members will negatively impact performance. In such cases, consider adding more resources for the producers.
This metric provides the percentage rate of HTTP-2xx responses generated by the Portal Parallel Page Engine (PPE).
This metric provides the percentage rate of HTTP-3xx responses generated by the Portal Parallel Page Engine (PPE).
This metric provides the percentage rate of HTTP-4xx responses generated by the Portal Parallel Page Engine (PPE).
HTTP-499 is a special code which means that the requested resource is protected and a "Login" is needed to access it. Similarly, "HTTP-470" means that a "Logout" operation was performed.
This metric provides the percentage rate of HTTP-5xx responses generated by the Portal Parallel Page Engine (PPE).
This metric provides the percentage rate of timeout responses generated by the Portal Parallel Page Engine (PPE).
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If the number of timeout responses is high, use the Portal diagnostic logs to find out the cause of any failures. Timeouts may occur because of any of the following reasons:
Poorly performing portlet
Sudden increase in the load
Database performance issues
Network or database connectivity issues
Timeout value set to an improper value
This metric specifies the percentage of requests that are able to retrieve the cached page metadata content from WebCache.
This metric specifies the percentage of requests that are not able to retrieve hit the cached page metadata content from WebCache.
This metric specifies the percentage of requests that cannot use WebCache to cache content.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
| All Versions | Every 300 Hours |
If this value is high, use this value to analyze how much of the pages are defined to not use WebCache for page metadata caching. This is not a common option for most pages and has performance implications. Unless there are specific reasons, review the caching options for such pages. See "Improving Page Performance" chapter in "User's Guide for Oracle Portal" document in OTN for performance tuning information.
This category provides information about response metrics.
This metric indicates the status of Portal. A green up arrow indicates that Portal is up and running. A red down arrow indicates that Portal is down. A "timer-clock" state icon indicates that Enterprise Manager is unable to query and retrieve the Portal status information.
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Consecutive Number of Occurrences Preceding Notification | Alert Text |
|---|---|---|---|---|---|---|---|
| All Versions | Every Minute | After Every 60 Samples | = |
Not Defined | 0 | 1 | The Portal Application is down |
If the status of Portal is down, check if the:
Portal WebLogic container (WLS_PORTAL) is running. If required, start it.
Portal application within the Portal WebLogic container has been started. If required, start the application.
If the container and the application are running and the status is still down, use the Portal diagnostic logs to find out why.
|
 Copyright © 2006, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|