Re: Configuring Oracle Portal and Oracle 9ias

From: Yong Huang <yong321_at_yahoo.com>
Date: 27 Jul 2003 15:04:23 -0700
Message-ID: <b3cb12d6.0307271404.47d90c5e@posting.google.com>

"Tanel Poder" <tanel@@peldik.com> wrote in message news:<3f23a16f$1_1_at_news.estpak.ee>...

>

> The main issue with Portal in my experience is it's scalability problems.
> When you are developing, alone in your Portal and in fast local area network
> you probably don't see any performance problems, but when hundreds or
> thousands of users start using your portal, over slow wide area network you
> might even find out that your app is completely unusable. This is for two
> reasons, since everything is so dynamic, every time a page is generated,
> huge amounts of CPU are used, and we can't much tune it either, because the
> SQL is in wrapped PL/SQL packages. That's why Oracle is promoting their
> WebCache so much with iAS, but once you cache, you won't be completely
> dynamic. So have to balance between performance/caching when desining your
> app.
> The other issue is, that for every page display, Portal is doing a lot of
> HTTP requests toward the server (authentication to single sign-on server for
> for example, and often separate request for every tiny detail on your
> webpage).
>
> This experience comes mostly from iAS v1, hopefully the core page rendering
> engine has been optimized better in v2.
> If you want this to run on your laptop, you probably need 1GB of memory in
> it.
>
> Tanel.

I can't agree more on your comment on the scalability problem. Without web cache, the database experiences very heavy library cache latch contention. It's probably related to frequent calls to dbms_session.reset_package (I don't guarantee remembering some names correctly; can't access the server any more; just laid off). We changed mod plsql method to use fast refresh at /pls/portal/admin_/gateway.htm, which avoids calling reset_package. But we had other problems so switched back. Now the outsourced company is doing our (I mean their) company's intranet Portal site. I think they use webcache and problem is alleviated.

This is also correct: "often separate request for every tiny detail on your webpage". But are you sure the client has to constantly access Single Sign-on server? I thought the browser kept the cookie for the purpose of not talking to SSO in one session.

Yong Huang Received on Sun Jul 27 2003 - 17:04:23 CDT