Portal performance issue

Question

We're working on Portal 3.0.9.8.3, applied all mentioned "magic settings" suggested by Oracle support, but still encountering the poor performance problem. Our site is running load balancing on 2 Application Servers, pointing to 1 database server.
During a performance test, while trying to open a total of 100 browsers in 10 PCs (10 browsers for 1 PC) accessing the welcome page (with some Oracle provided portlets like Set Languages, Login, HTML Portlet, and 2 tailor-made JSP portlets) at the same time (should be "almost at the same time"), the CPU of the AS boosted up to 100% for quite a long while, but the CPU of the DB seems normal. And only some of the browsers can access the welcome page, whilst some errors like the following appeared:
"Portlet Timeout";
"Timeout occurred whilst retrieving page meta data";
"Portlet could not be contacted";
"HTTP 500 internal server error", etc.
Did anyone try similar performance test before? Is there any reference site running Portal successfully on top of Windows 2000 platform, with the capability of around 1,000 concurrent access?

Answer 1

Michael,
Did you read the following document ?
http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/OTN_CONTENT/MAINPAGE/ARCHITECTURE/TROUBLESHOOTING_ISSUES_IN_ORACLE9IAS_PORTAL2.HTM
This document (amongst other things) explains how to analyse problems like this.
Do you have error logs from Apache, Jserv and the database ?
Have you run the portal in debug mode (_debug=1) ?
If so, what did it say ?
How long do the custom portlets take to return ?
Is the content cached ?
etc etc
You need to understand also that your testing method is a little primitive, if you have 10 pc's with 10 browsers open, then you will have instantiated 10 sessions, each of the browsers will be accessing the same session on the PC as we write a cookie for the session the first time you connect, (unless of course you didn't log on)
Just because you have the browser sessions started does not mean that you have a concurrent user community. Remember that HTTP is a disconnect request/response protocol, there is no notion of being concurrent. You should operate in terms of page requests per second (preq/s).
With this in mind, consider that my.oracle.com, which has over 300,000 registered users, only gets 120preq/s. You can read about this further in the whitepaper 'Architecting my.oracle.com' on OTN.
If you have applied 3.0.9.8.3 then you will have access to the performance logging features exposed in that patch. I would suggest that you use that to try and analyse the problems you are seeing.
Regards
Jason