This chapter describes Oracle Portal metrics.
Note:
The current Enterprise Manager release does not support Oracle 10g Portal metrics.This category provides information about portlets metrics.
This metric specifies the rate of cache hits.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
This metric specifies the average time.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
This metric specifies the rate per minute of requests to the Portal.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
This category provides information about portlets (Top 5) metrics.
The cache hit percentage
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
This is the average time in milliseconds
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
This is the number of requests recorded per minute.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
This category provides information about producers metrics.
This metric specifies the rate of cache hits from a producer.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the cache hit ratio for a producer.
This metric specifies the average time in executing portlet calls for a producer.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the response times of a producer. If response time is out-of-bound, then assess average response times of individual portlets. Consider caching options and scaling out to optimize performance.
This metric specifies the rate of requests per minute that are getting serviced from a producer.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the load on the producer.
This metric measures the availability of a producer, and measures the percent of requests that got an HTTP-2xx response from a producer.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the availability of a producer. If this number is out-of-bounds, check the producer instance for availability and check for network connectivity from the Portal middle-tier to the producer.
This category provides information about producers (Top 5) metrics.
The cache hit percentage.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
The average time in milliseconds
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
The number of requests per minute
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
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".
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of the pages/content. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
This metric specifies the percentage of requests that resulted in successful cache hits, for content that does "Expiry-based caching".
Use this metric to assess the caching statistics of the pages/content. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of your pages/content. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
This metric specifies the average time for cache misses in the Portal cache for content that is newly created in the cache.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of your pages/content. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
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.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of your pages/content.
This metric specifies the average time for cache hits in the Portal cache for content that uses "Ping-based caching".
Use this metric to assess the caching statistics of your pages/content.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of the pages/content. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
This metric specifies the percentage of requests that resulted in successful cache hits for content that requires ping checks.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of your pages/content.
This metric specifies the rate per minute of requests to the Portal Cache.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the rate 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.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to assess the caching statistics of the pages/content. See "Using Caching with PL/SQL Based Web Applications" section in the Oracle® Fusion Middleware User's Guide for mod_plsql in OTN.
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 |
User Action
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.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
If the average time is high:
Look at the connection pool hit ratio and make sure it is not out-of-bounds.
Look at the time taken to create new connections to the database, and at your database settings.
Check the network and database connection.
This metric provides the rate of incoming requests that require a database connection
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Tune the database sessions based on the number of concurrent 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 |
User Action
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 |
User Action
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 |
User Action
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 |
User Action
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 |
User Action
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 |
User Action
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.
If the average time is high, use the Portal diagnostic logs to find out the cause of any failures. Average time may be high due to any of the following reasons:
Poorly performing portlet
Sudden increase in the load
Database performance issues
Network or database connectivity issues
This metric specifies the rate of pages per minute generated by the Parallel Page Engine
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
If this value is out-of-bounds, identify the key pages in the site and enable better caching options. See "Improving Page Performance" chapter in "User's Guide for Oracle Portal" document in OTN for performance tuning information.
This metric specifies the average time taken to retrieve the page metadata.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
If the average time is high, review the page metadata caching options for the pages and enable more caching at various levels.
This metric specifies the page metadata throughput per-minute.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
If this value is out-of-bounds, identify the key pages for the site and enable better caching. See "Improving Page Performance" chapter in "User's Guide for Oracle Portal" document in OTN for performance tuning information.
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 |
User Action
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 |
User Action
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).
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
If this number is low, use the diagnostic logs to investigate.
This metric provides the percentage rate of HTTP-3xx 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 |
User Action
If the number of redirect responses in the system (HTTP 302) is high, review the cause for these responses and see if something can be optimized.
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.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
If the number of HTTP-4xx responses that are generated by the PPE is high, use the Portal diagnostic logs to investigate.
This metric provides the percentage rate of HTTP-5xx 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 |
User Action
If the number of HTTP-5xx responses that are generated by the PPE is high, use the Portal diagnostic logs to investigate.
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 |
User Action
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.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this value to understand how effectively WebCache is being used for caching the page metadata. If this value is low, review the caching options for the pages.
This metric specifies the percentage of requests that are not able to retrieve hit the cached page metadata content from WebCache.
The following table shows how often the metric's value is collected.
| Target Version | Collection Frequency |
|---|---|
| All Versions | Every 300 Hours |
User Action
Use this metric to understand how effectively WebCache is being used for caching the page metadata for your pages.
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 |
User Action
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.
| Target Version | Evaluation and Collection Frequency | Upload Frequency | Operator | Default Warning Threshold | Default Critical Threshold | Alert Text |
|---|---|---|---|---|---|---|
| All Versions | Every Minute | After Every 60 Samples | = | Not Defined | 0 | The Portal Application is down |
User Action
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.