Re: Configuring Oracle Portal and Oracle 9ias

yong321_at_yahoo.com (Yong Huang) wrote in message news:<b3cb12d6.0307271404.47d90c5e_at_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

Wth regard to the overall functionality and scalability of Portal I only aim this site to be a demonstative model with the possibility of expansion later on. I only expect several users to be accessing this application at one time, to start with, but with the intention of increasing this.

Would I be right in saying that this would be ok?

But obviously things will need to be looked at again when the time is right to increase the number of users that will access it following the above guidelines.

Tim Corke Received on Mon Jul 28 2003 - 07:32:21 CDT