Skip Headers
Oracle® Enterprise Manager Oracle Fusion Middleware Metric Reference Manual,
11g Release 1 (11.1.0.1)

E18807-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

9 Portal

This chapter describes Oracle Portal metrics.

Portlets (All)

This category provides information about portlets metrics.

Cache Hit (%)

This metric specifies the rate of cache hits.

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Average Time (ms)

This metric specifies the average time.

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Requests (per minute)

This metric specifies the rate per minute of requests to the Portal.

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Availability (%)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Producer Type

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Portlets (Top 5)

This category provides information about portlets (Top 5) metrics.

Cache Hit (%)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Average Time (ms)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Requests (per minute)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Availability (%)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Producer Type

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Producers (All)

This category provides information about producers metrics.

Cache Hit (%)

This metric specifies the rate of cache hits from a producer.

Metric Summary

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.

Average Time (ms)

This metric specifies the average time in executing portlet calls for a producer.

Metric Summary

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.

Requests (per minute)

This metric specifies the rate of requests per minute that are getting serviced from a producer.

Metric Summary

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.

Availability (%)

This metric measures the availability of a producer, and measures the percent of requests that got an HTTP-2xx response from a producer.

Metric Summary

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.

Producer Type

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Producers (Top 5)

This category provides information about producers (Top 5) metrics.

Cache Hit (%)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Average Time (ms)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Requests (per minute)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Availability (%)

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Producer Type

Metric Summary

The following table shows how often the metric's value is collected.

Target Version Collection Frequency
All Versions Every 300 Hours

Portal Cache

This category provides information about portal cache metrics.

Average Expire Hit Time (ms)

This metric specifies the average time for cache hits in the Portal cache for content that uses "Expires-based caching".

Metric Summary

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.

Expire Hit (%)

This metric specifies the percentage of requests that resulted in successful cache hits, for content that does "Expiry-based caching".

Metric Summary

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.

Average New Time (ms)

This metric specifies the average time for cache misses in the Portal cache for content that is newly created in the cache.

Metric Summary

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.

New (%)

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.

Metric Summary

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.

Average Ping Hit Time (ms)

This metric specifies the average time for cache hits in the Portal cache for content that uses "Ping-based caching".

Metric Summary

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.

Ping Hit (%)

This metric specifies the percentage of requests that resulted in successful cache hits for content that requires ping checks.

Metric Summary

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.

Requests (per minute)

This metric specifies the rate per minute of requests to the Portal Cache.

Metric Summary

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.

Average Stale Time (ms)

This metric specifies the average time for cache misses in the Portal cache for content that is stale and requires re-generation.

Metric Summary

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.

Stale (%)

This metric specifies the percentage of requests that resulted in cache misses because the content cached in the Portal Cache was not the latest.

Metric Summary

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.

Database Connection Pool Statistics

This category provides information about database connection pool statistics.

Average Fetch Time (ms)

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.

Metric Summary

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.

Requests (per minute)

This metric provides the rate of incoming requests that require a database connection

Metric Summary

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.

Hit (%)

This metric indicates the effectiveness of the Portal connection pool by measuring the percentage of Portal database connection pool hit rate.

Metric Summary

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.

New (%)

This metric indicates the effectiveness of the Portal connection pool by measuring the percentage rate of creating new database connections in Portal.

Metric Summary

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.

Stale (%)

This metric indicates the effectiveness of the Portal connection pool by providing the percentage rate of discarding pooled database connections.

Metric Summary

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.

Database Repository Response Code Statistics

This category provides information about database repository response code statistic metrics.

Responses (per minute)

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.

Metric Summary

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.

Average Processing Time (ms)

This metric provides the average response time for generating a response code.

Metric Summary

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.

Page Engine Statistics

This category provides information about page engine statistic metrics.

Average Queue Wait Time (ms)

This metric provides the average time all internal PPE requests spent in the PPE internal request queue.

Metric Summary

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.

Average Page Processing Time (ms)

This metric specifies the average time taken to generate the pages and also retrieve the page metadata.

Metric Summary

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, 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

Pages (per minute)

This metric specifies the rate of pages per minute generated by the Parallel Page Engine

Metric Summary

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.

Average Page Metadata Fetch Time (ms)

This metric specifies the average time taken to retrieve the page metadata.

Metric Summary

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.

Page Metadata Fetches (per minute)

This metric specifies the page metadata throughput per-minute.

Metric Summary

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.

Average Page Metadata Wait Time (ms)

This metric specifies the average time spent in the PPE internal request queue waiting for page metadata.

Metric Summary

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.

Queue Timeouts (per minute)

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.

Metric Summary

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.

HTTP200-HTTP299 (%)

This metric provides the percentage rate of HTTP-2xx responses generated by the Portal Parallel Page Engine (PPE).

Metric Summary

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.

HTTP300-HTTP399 (%)

This metric provides the percentage rate of HTTP-3xx responses generated by the Portal Parallel Page Engine (PPE).

Metric Summary

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.

HTTP400-HTTP499 (%)

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.

Metric Summary

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.

HTTP500-HTTP599 (%)

This metric provides the percentage rate of HTTP-5xx responses generated by the Portal Parallel Page Engine (PPE).

Metric Summary

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.

Timeout (%)

This metric provides the percentage rate of timeout responses generated by the Portal Parallel Page Engine (PPE).

Metric Summary

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

WebCache Page Metadata Hits (%)

This metric specifies the percentage of requests that are able to retrieve the cached page metadata content from WebCache.

Metric Summary

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.

WebCache Page Metadata Misses (%)

This metric specifies the percentage of requests that are not able to retrieve hit the cached page metadata content from WebCache.

Metric Summary

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.

WebCache Page Metadata Non-Cacheables (%)

This metric specifies the percentage of requests that cannot use WebCache to cache content.

Metric Summary

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.

Response

This category provides information about response metrics.

UpDown Status

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.

Metric Summary

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

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.