You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Saddest OfAllKeys <ke...@yahoo.com> on 2002/03/30 19:19:19 UTC
performance
I have tentative approval to go ahead with Jetspeed
for a project.
Performance and scale is a concern. I'm looking for
ideas about improving these issues by configuring
Jetspeed.
For example, it seems to me that if I disallow patron
customization of a portal, that that would improve
performance because hopefully I can avoid hitting the
database.
Another example might be to turn off Jetspeed logging.
Another ideas? The upshot is that I want to streamline
Jetspeed, even if it does reduce the "portal
experience" for the end user.
thanks in advance,
Mike
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: performance
Posted by Saddest OfAllKeys <ke...@yahoo.com>.
Thanks for the info!
Which profiling tool(s) do you use?
--- Santiago Gala <sg...@hisitech.com> wrote:
> El s�b, 30-03-2002 a las 19:19, Saddest OfAllKeys
> escribi�:
> >
> > I have tentative approval to go ahead with
> Jetspeed
> > for a project.
> >
> > Performance and scale is a concern. I'm looking
> for
> > ideas about improving these issues by configuring
> > Jetspeed.
> >
> > For example, it seems to me that if I disallow
> patron
> > customization of a portal, that that would improve
> > performance because hopefully I can avoid hitting
> the
> > database.
> >
>
>
>
> > Another example might be to turn off Jetspeed
> logging.
>
> This will give a boost. At least, you could tell it
> to log only errors.
> >
> > Another ideas? The upshot is that I want to
> streamline
> > Jetspeed, even if it does reduce the "portal
> > experience" for the end user.
> >
>
> I found some (instantiation/recycling related)
> memory bottlenecks while
> looking at how JetspeedTemplateLink is used. I am
> about to commit a lot
> of (minor) changes to improve this.
>
> For scalability, you should profile intensively for
> your typical
> configuration. After you know where time is spent,
> then you can look for
> solutions in those areas.
>
> I would start by testing with estimated full load
> the "standard"
> Jetspeed release you are trying to use (If your
> project will take time
> to develop I would do stress testing with CVS
> version) and then
> profiling Jetspeed (in your servlet container and
> with your target JDK)
> to see where time is spent. Then you can think about
> the necessary
> trade-offs.
>
> In my experience, most of the problems come from
> careless generation of
> garbage ( string concatenation, lack of reuse of
> objects, etc.) which
> triggers too much garbage collection effort. But
> only code in the inner
> loops is worthwhile to be changed, because code
> clarity is a must in the
> long term.
>
>
> > thanks in advance,
> > Mike
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Greetings - send holiday greetings for
> Easter, Passover
> > http://greetings.yahoo.com/
> >
> > --
> > To unsubscribe, e-mail:
>
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
>
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: performance
Posted by Santiago Gala <sg...@hisitech.com>.
El sáb, 30-03-2002 a las 19:19, Saddest OfAllKeys escribió:
>
> I have tentative approval to go ahead with Jetspeed
> for a project.
>
> Performance and scale is a concern. I'm looking for
> ideas about improving these issues by configuring
> Jetspeed.
>
> For example, it seems to me that if I disallow patron
> customization of a portal, that that would improve
> performance because hopefully I can avoid hitting the
> database.
>
> Another example might be to turn off Jetspeed logging.
This will give a boost. At least, you could tell it to log only errors.
>
> Another ideas? The upshot is that I want to streamline
> Jetspeed, even if it does reduce the "portal
> experience" for the end user.
>
I found some (instantiation/recycling related) memory bottlenecks while
looking at how JetspeedTemplateLink is used. I am about to commit a lot
of (minor) changes to improve this.
For scalability, you should profile intensively for your typical
configuration. After you know where time is spent, then you can look for
solutions in those areas.
I would start by testing with estimated full load the "standard"
Jetspeed release you are trying to use (If your project will take time
to develop I would do stress testing with CVS version) and then
profiling Jetspeed (in your servlet container and with your target JDK)
to see where time is spent. Then you can think about the necessary
trade-offs.
In my experience, most of the problems come from careless generation of
garbage ( string concatenation, lack of reuse of objects, etc.) which
triggers too much garbage collection effort. But only code in the inner
loops is worthwhile to be changed, because code clarity is a must in the
long term.
> thanks in advance,
> Mike
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Greetings - send holiday greetings for Easter, Passover
> http://greetings.yahoo.com/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>