Sizing OracleAS Portal : Usage reporting from the Performance Logs
Sizing : Usage reporting from the Performance Logs
Introduction
OracleAS Portal Release 3.0.x provided portal administrators with a collection of reporting and charting portlets, available by default on the Monitor tab, for reporting object access information. The information in these reports and charts was retrieved from the OracleAS Portal Activity Log tables, which were located in the OracleAS Portal Repository. In addition, a set of public views were made available for anyone who wished to issue their own SQL queries directly against this data.
With the move to OracleAS Portal Release 2, and the introduction of OracleAS Web Cache into the portal architecture, the information in these tables became inaccurate. Therefore, all the pre-built reporting and charting portlets were removed from Portal. The OracleAS Portal Activity Log tables and views still remain in the OracleAS Portal Repository for backward compatibility, however, these tables may be removed entirely in a future release. You will find that the tables still get populated with data
when objects in the repository (charts, forms reports etc) are created or
dropped. This data is not a reliable source of accurate usage logging data for
view only activities, because they do not take into account content that is
delivered from the mid-tier file cache or Web Cache. This functionality has been
replaced by a set of reports known as the Portal Performance Reports.
All the reports mentioned here accept an argument to adjust their output,
if not mentioned in this tech note, you will find that the arguments are
documented in the header of each script.
Generated by the summ_login.sql file with an argument of 'hour' or 'day'. The file
generated by this report is called summ_login_byhour.txt and looks like the
sample below.
Generated by the summ_login.sql file with an argument of 'day'. The file
generated by this report is called summ_login_byday.txt and looks like the sample below.
Successful Login Time Summary, by Day
Avg 50th 90th Total
Req Perc Perc Req Req
Date sec sec sec Count mins
--------- -------- -------- -------- --------- -------
04-SEP-02 0.902 0.686 0.975 12291 184.7
03-SEP-02 1.388 1.232 1.723 20948 484.7
02-SEP-02 1.690 1.313 1.924 9209 259.4
01-SEP-02 1.652 1.353 1.970 3857 106.2
31-AUG-02 1.767 1.296 1.935 3050 89.8
30-AUG-02 1.353 1.243 1.686 16904 381.1
29-AUG-02 0.993 0.612 0.810 19548 323.4
28-AUG-02 1.366 1.262 1.737 18696 425.8
The example shows that were 20,948 successful logins on 3rd Sept 2002,
with each login taking approximately 1.388 secs to service.
There are some eight reports that would help with answering this
question, generated by the top_portlet.sql query depending on the arguments passed.
The reports generated can be organized by day or hour, averaged or summed, and
sorted ascending or descending depending on your preference. The name of the
file generated depends on the arguments passed to the script. In the case of
the example the file generated by this report would be called
top_portlet_sum_asc_byday.txt and looks like the sample below. (For brevity
some of the report columns have been removed)
The example shows that were 13 requests for the Internal News portlet.
One hundred percent of these requests were served from the cache in 3/1000
of a second. There was no variance in response time as the values for
average, fiftieth and ninetieth percentile request seconds are identical.
There are four reports that would help with answering this
question, generated by the top_portlet.sql query depending on the arguments passed.
The reports generated can be organised by day or hour, averaged or summed, and
sorted ascending or descending depending on your preference. The name of the
file generated depends on the arguments passed to the script. In the case of
the example the file generated by this report would be called
top_portlet_sum_desc_byday.txt and looks like the sample below. (For brevity
some of the report columns have been removed)
The example shows that there were eight requests for the FOLDER portlet
taking an average of 1sec per request to process. There was also no caching of
the content and a variance of some 300ms between the average and the ninetieth
percentile. For the request counts shown in the example, these figures are
acceptable, however if the portlet in question was a popular one that
received hundreds of requests per day then we would need to consider caching
the content to get the response times down.
This report expects four arguments (time_unit, num_items, sortfn, sortdir).
To generate the example report above, therefore, we would pass the arguments
thus..
The example shows that the STOCK portlet was the most popular.
This report expects four arguments (time_unit, num_items, sortfn, sortdir).
To generate the example report above, therefore, we would pass the arguments
thus..
This report generates a breakdown of pages that have been viewed
by each portal user. The report breaks on Page ID and then on User. If you would like to
find out the descriptive details of the pages, you will need to issue the
following query in SQL*Plus against the origin portal repository.
select name, title
from portal.wwpob_page$
where ID = [Page ID from above]
Generated by the summ_uniqsess.sql. The file
generated by this report is called summ_uniqsess_byday.txt and looks
like the sample below.
Unique Sessions Summary, by Day
Unique
Date Host Sessions
--------- -------------------- ---------
03-SEP-02 www.qpalzm1.com 123064
02-SEP-02 www.qpalzm1.com 62158
01-SEP-02 www.qpalzm1.com 41885
31-AUG-02 www.qpalzm1.com 39198
30-AUG-02 www.qpalzm1.com 102490
29-AUG-02 www.qpalzm1.com 116257
The example shows that on that 3rd Sept we received 123,064 unique
logins. The number of unique users can be estimated by the number of unique
session_file entries. The http_user column is not sufficient, as
many sites run as the PUBLIC user.
The example shows that the site map portlet was requested 2,113 times.
This report can be very large, the sample report above was cut from a daily
report run within Oracle that is some 16 pages long per day, so the example
is a trimmed version with columns missing for brevity.
The example shows that Page ID 1546 was requested 45 times, and its
performance was consistent, shown by the fact that the timings for average,
50th and 90th percentile have a very small variance. If you would like to
find out the descriptive details of the pages, you will need to issue the
following query in SQL*Plus against the origin portal repository.
select name, title
from portal.wwpob_page$
where ID = [Page ID from above]
The example shows that the LOB Site Map portlet was requested 2,113
times in one day, the portlet responded on average in 181 milliseconds and
57.3% of the requests were served from the cache and not generated from the
repository. Interestingly, the portlet timed out once. If this figure
started to rise, it would be worth investigating in the logs what was
happening.
The example shows the physical requests served by each machine within the
portal farm. By passing the argument 'IP' to the report, the physical host
names would be replaced with IP addresses.
There are many administrative and management questions that arise when
implementing and running a corporate portal. The scripts described in this
technote will help administrators to answer some of those questions.
Bookmark
