You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2002/07/24 18:43:07 UTC
Performance problem XSP after April 20
Hi.
After Leszek Gawron pointed out performance problems with ESQL after
an upgrade from one snapshot to another
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102560380325818&w=2
I've discovered that XSP performance has deteriorated drastically:
tomcat 4.1.7
java version "1.3.1_03"
linux 2.4.19-rc3-ac3
intel piii-850 640 MB
"current" version (10 days old, still HSQLDB 1.63)
mean
simple 261 213 243 244 260 170 244 182 200 226 "224.3"
request 492 310 261 235 164 98 104 111 106 101 "198.2"
esql 260 144 164 270 246 87 93 86 91 89 "153.0"
samples "19.6"
"old" version (2002-04-20)
simple 180 188 218 195 70 42 32 49 37 28 "103.9"
request 107 223 73 102 99 49 55 51 58 50 "86.7"
esql 119 122 142 127 41 40 46 39 47 35 "75.8"
samples 20 35 17 22 17 17 23 17 18 36 "22.2"
All being reload times in milliseconds for consecutive
reloads. "simple" is the "Simple XSP" example, "request" "Request
Logicsheet", "esql" "Simple ESQL", and "samples" the "samples/welcome"
static page.
While "samples" is reasonable similar, all XSPs have doubled. Any
clues?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Peter Royal <pr...@apache.org>.
On Monday 29 July 2002 11:34 am, Berin Loritsch wrote:
> > yuk! perhaps an immediate change would be to store looked-up
> > objects in a
> > HashSet to skip the iteration?
>
> Even better would be to start migrating to Fortress.
> All your expensive stuff on the backend is done asyncronously,
> so the critical path is not affected.
Of course, but for the 2.0.3 stable branch, a slight modification to the ECM
might be easier to swallow.
> The fact that the cache has to lookup and release up to 15
> components at runtime is horrendous. That makes me think
> that the cache should be redesigned so that it is self contained.
That crossed my mind also :)
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Per Kreipke <pe...@onclave.com>.
Does all this mean that 2.0.3 will continue to suffer from this performance
problem?
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> >
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > Even better would be to start migrating to Fortress.
> > > All your expensive stuff on the backend is done asyncronously,
> > > so the critical path is not affected.
> > >
> > > Another one would be to fix the assumption that lookup/release
> > > is 0 time. That is obviously proven false in this case.
> > >
> > > The fact that the cache has to lookup and release up to 15
> > > components at runtime is horrendous. That makes me think
> > > that the cache should be redesigned so that it is self contained.
> >
> > Berin,
> >
> > Not cache. Cocoon engine:
> >
> > 1. Cocoon lookups sitemap processor.
> > 2. Processor (sitemap) lookups pipelines.
> > 3. Sitemap selects all matchers, selectors, actions, generators,
> > serializers, transformers as needed (you have to build pipeline).
> > 4. Pipeline [gets cached response and] lookups XML deserializer.
> >
> > The more complex sitemap you have (more matchers/selectors/etc), the
> > more lookups will happen. Say, every cocoon source will
> > lookup processor
> > and continue the process from step 2.
>
>
> I see. I misread your post.
>
>
> > <flame-bait>
> > I know that you want to use pre-built pipelines, but (skipping
> > discussion of how this could be possible) with growing site
complexity
> > amount of all possible pipelines in the sitemap grows exponentially
> > (IIRC, DNA has only four building blocks, but amount of possible
> > combinations is close to infinity), thus making any effort to
> > pre-built
> > pipelines ahead of time futile.
> > </flame-bait>
> >
> > ;)
>
> I wasn't addressing that at the moment.
>
>
> Fortress will help tremendously. We just need a RoleManager that can
> read
> the old style of XXXX.roles file, and a Fortress Container decendant
> that
> can read the old style of XXXX.xconf files. They are very similar,
and
> Fortress is really what you guys need.
Looking forward to it! :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Berin Loritsch <bl...@apache.org>.
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Even better would be to start migrating to Fortress.
> > All your expensive stuff on the backend is done asyncronously,
> > so the critical path is not affected.
> >
> > Another one would be to fix the assumption that lookup/release
> > is 0 time. That is obviously proven false in this case.
> >
> > The fact that the cache has to lookup and release up to 15
> > components at runtime is horrendous. That makes me think
> > that the cache should be redesigned so that it is self contained.
>
> Berin,
>
> Not cache. Cocoon engine:
>
> 1. Cocoon lookups sitemap processor.
> 2. Processor (sitemap) lookups pipelines.
> 3. Sitemap selects all matchers, selectors, actions, generators,
> serializers, transformers as needed (you have to build pipeline).
> 4. Pipeline [gets cached response and] lookups XML deserializer.
>
> The more complex sitemap you have (more matchers/selectors/etc), the
> more lookups will happen. Say, every cocoon source will
> lookup processor
> and continue the process from step 2.
I see. I misread your post.
> <flame-bait>
> I know that you want to use pre-built pipelines, but (skipping
> discussion of how this could be possible) with growing site complexity
> amount of all possible pipelines in the sitemap grows exponentially
> (IIRC, DNA has only four building blocks, but amount of possible
> combinations is close to infinity), thus making any effort to
> pre-built
> pipelines ahead of time futile.
> </flame-bait>
>
> ;)
I wasn't addressing that at the moment.
Fortress will help tremendously. We just need a RoleManager that can
read
the old style of XXXX.roles file, and a Fortress Container decendant
that
can read the old style of XXXX.xconf files. They are very similar, and
Fortress is really what you guys need.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Peter Royal [mailto:proyal@apache.org]
> >
> > On Saturday 27 July 2002 12:01 pm, Vadim Gritsenko wrote:
> > > Actually, release is slower then lookup, because it
> > > invokes iterating
> > > through all lists in all proxies, which takes more
> > > time with growing
> > > complexity of the site (aggregations etc).
> >
> > yuk! perhaps an immediate change would be to store
> > looked-up objects in a
> > HashSet to skip the iteration?
> > -pete
>
>
> Even better would be to start migrating to Fortress.
> All your expensive stuff on the backend is done asyncronously,
> so the critical path is not affected.
>
> Another one would be to fix the assumption that lookup/release
> is 0 time. That is obviously proven false in this case.
>
> The fact that the cache has to lookup and release up to 15
> components at runtime is horrendous. That makes me think
> that the cache should be redesigned so that it is self contained.
Berin,
Not cache. Cocoon engine:
1. Cocoon lookups sitemap processor.
2. Processor (sitemap) lookups pipelines.
3. Sitemap selects all matchers, selectors, actions, generators,
serializers, transformers as needed (you have to build pipeline).
4. Pipeline [gets cached response and] lookups XML deserializer.
The more complex sitemap you have (more matchers/selectors/etc), the
more lookups will happen. Say, every cocoon source will lookup processor
and continue the process from step 2.
<flame-bait>
I know that you want to use pre-built pipelines, but (skipping
discussion of how this could be possible) with growing site complexity
amount of all possible pipelines in the sitemap grows exponentially
(IIRC, DNA has only four building blocks, but amount of possible
combinations is close to infinity), thus making any effort to pre-built
pipelines ahead of time futile.
</flame-bait>
;)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Berin Loritsch <bl...@apache.org>.
> From: Peter Royal [mailto:proyal@apache.org]
>
> On Saturday 27 July 2002 12:01 pm, Vadim Gritsenko wrote:
> > Actually, release is slower then lookup, because it invokes
> iterating
> > through all lists in all proxies, which takes more time
> with growing
> > complexity of the site (aggregations etc).
>
> yuk! perhaps an immediate change would be to store looked-up
> objects in a
> HashSet to skip the iteration?
> -pete
Even better would be to start migrating to Fortress.
All your expensive stuff on the backend is done asyncronously,
so the critical path is not affected.
Another one would be to fix the assumption that lookup/release
is 0 time. That is obviously proven false in this case.
The fact that the cache has to lookup and release up to 15
components at runtime is horrendous. That makes me think
that the cache should be redesigned so that it is self contained.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Peter Royal <pr...@apache.org>.
On Saturday 27 July 2002 12:01 pm, Vadim Gritsenko wrote:
> Actually, release is slower then lookup, because it invokes iterating
> through all lists in all proxies, which takes more time with growing
> complexity of the site (aggregations etc).
yuk! perhaps an immediate change would be to store looked-up objects in a
HashSet to skip the iteration?
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Berin Loritsch <bl...@apache.org>.
> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
> > From: Peter Royal [mailto:proyal@apache.org]
> Pete,
>
> Component creation isn't bottleneck, lookup/release time is
> important. When Cocoon works from cache, it does essentially
> just couple of things:
>
> 1. Lookups *and* releases tons of components (ok, not tons,
> just 5-15), 2. Verifies validity, 3. Sends response back
> (sometimes - from in-memory cache).
>
> These three tasks by my estimates (and some old profilings with
> optimizeit) split whole 100% processing time on three slices
> (approximately): 20% - 70% - 10%.
>
> Actually, release is slower then lookup, because it invokes
> iterating through all lists in all proxies, which takes more
> time with growing complexity of the site (aggregations etc).
With Fortress, all release() operations are done asyncronously.
That means that we can have expensive decisions that need to be
done without affecting the critical path of execution.
> When response is not from cache, of course most of the time
> is spent in XSP generation and XSLT processing, and Avalon's
> slice decreases to 8%
> (simple.xsp) and below.
It can still be faster. I haven't been able to attempt the switch
to Fortress yet....
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Peter Royal [mailto:proyal@apache.org]
>
> On Saturday 27 July 2002 10:15 am, Vadim Gritsenko wrote:
> > About complexity itself: I'm referring to this particular change in
> > DefaultComponentFactory:
> >
> >
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/src/java/org/
> >
apache/avalon/excalibur/component/Attic/DefaultComponentFactory.java.dif
> > f?r1=1.10&r2=1.11&diff_format=h
> >
> > Addition of
> >
> > private final Collection m_unreleased = new ArrayList();
> >
> > slows down Cocoon from 8% (dynamic page) to something around 20%
(page
> > from cache).
>
> Is it slower on component creation from the DefaultComponentFactory or
upon
> general ComponentManager.lookup() calls with the new added proxy?
Pete,
Component creation isn't bottleneck, lookup/release time is important.
When Cocoon works from cache, it does essentially just couple of things:
1. Lookups *and* releases tons of components (ok, not tons, just 5-15),
2. Verifies validity,
3. Sends response back (sometimes - from in-memory cache).
These three tasks by my estimates (and some old profilings with
optimizeit) split whole 100% processing time on three slices
(approximately): 20% - 70% - 10%.
Actually, release is slower then lookup, because it invokes iterating
through all lists in all proxies, which takes more time with growing
complexity of the site (aggregations etc).
When response is not from cache, of course most of the time is spent in
XSP generation and XSLT processing, and Avalon's slice decreases to 8%
(simple.xsp) and below.
Regards,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Peter Royal <pr...@apache.org>.
On Saturday 27 July 2002 10:15 am, Vadim Gritsenko wrote:
> About complexity itself: I'm referring to this particular change in
> DefaultComponentFactory:
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/src/java/org/
> apache/avalon/excalibur/component/Attic/DefaultComponentFactory.java.dif
> f?r1=1.10&r2=1.11&diff_format=h
>
> Addition of
>
> private final Collection m_unreleased = new ArrayList();
>
> slows down Cocoon from 8% (dynamic page) to something around 20% (page
> from cache).
Is it slower on component creation from the DefaultComponentFactory or upon
general ComponentManager.lookup() calls with the new added proxy?
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Avalon-related slowdown ? (was Re: Performance problem XSP after April 20)
Posted by Berin Loritsch <bl...@apache.org>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
>slows down Cocoon from 8% (dynamic page) to something around 20% (page
>from cache).
>
>
Wow ! That's really bad :(
Is the new container in Avalon faster ? Do we need to plan the switch to
this new container in 2.1 ?
Berin, can you please answer this question ?
Actually yes there is! I even wrote it, with the help of my fellow
Avaloners. Fortress is the name of the new higher performance
Container.
On tests Fortress is at least 15 times as fast (1500% faster) than
ECM. It also has some experimental support for lifecycle extensions.
Work is continuing on it, we are trying to fit in some of the more
robust meta-info facilities from Merlin, because Avalon is trying to
standardize on one way of expressing meta-information.
Currently, Fortress should be considered an almost defacto standard
replacment for ECM. It supports Poolable, Factory, ThreadSafe, and
a new default: PerThread component lifestyles.
The RoleManager markup is slightly different, and all components are
at a root level. It gives us the flexibility of grabbing a default
component directly, or going through the selector. If you want more
info, let me know. The URL is here:
http://jakarta.apache.org/avalon/excalibur/fortress/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Avalon-related slowdown ? (was Re: Performance problem XSP after
April 20)
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>Vadim Gritsenko wrote:
>>
>>>Chris,
>>>
>>>What you use to measure time?
>>>
>>>I timed executing of simple.xsp in Cocoon "-D 20020420" and in Cocoon 2.0.4-dev with the "for() time wget", and compared time reported by the Cocoon in access.log.
>>>
>>>After factoring out additional complexities in excalibur code
>>>(responsible for 8-9% performance loss), results were *identical*.
>>>
>>>
>>>
>>>
>>Vadim, can you explain what are these additional complexities ? Is the
>>current version 8% slower because of changes of changes in excalibur ?
>>
>>
>
>Ok, after second look, seems that these complexities are present in both
>versions, which means that old version also can go at least 9% faster.
>May be there are some other changes. Will take another look later.
>
>
>About complexity itself: I'm referring to this particular change in
>DefaultComponentFactory:
>
>http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/src/java/org/
>apache/avalon/excalibur/component/Attic/DefaultComponentFactory.java.dif
>f?r1=1.10&r2=1.11&diff_format=h
>
>Addition of
>
> private final Collection m_unreleased = new ArrayList();
>
>slows down Cocoon from 8% (dynamic page) to something around 20% (page
>from cache).
>
>
Wow ! That's really bad :(
Is the new container in Avalon faster ? Do we need to plan the switch to
this new container in 2.1 ?
Berin, can you please answer this question ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Vadim Gritsenko wrote:
>
> >Chris,
> >
> >What you use to measure time?
> >
> >I timed executing of simple.xsp in Cocoon "-D 20020420" and in Cocoon
> >2.0.4-dev with the "for() time wget", and compared time reported by
the
> >Cocoon in access.log.
> >
> >After factoring out additional complexities in excalibur code
> >(responsible for 8-9% performance loss), results were *identical*.
> >
> >
>
> Vadim, can you explain what are these additional complexities ? Is the
> current version 8% slower because of changes of changes in excalibur ?
Ok, after second look, seems that these complexities are present in both
versions, which means that old version also can go at least 9% faster.
May be there are some other changes. Will take another look later.
About complexity itself: I'm referring to this particular change in
DefaultComponentFactory:
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/src/java/org/
apache/avalon/excalibur/component/Attic/DefaultComponentFactory.java.dif
f?r1=1.10&r2=1.11&diff_format=h
Addition of
private final Collection m_unreleased = new ArrayList();
slows down Cocoon from 8% (dynamic page) to something around 20% (page
from cache).
Vadim
> Sylvain
>
> --
> Sylvain Wallez
> Anyware Technologies Apache Cocoon
> http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>Chris,
>
>What you use to measure time?
>
>I timed executing of simple.xsp in Cocoon "-D 20020420" and in Cocoon
>2.0.4-dev with the "for() time wget", and compared time reported by the
>Cocoon in access.log.
>
>After factoring out additional complexities in excalibur code
>(responsible for 8-9% performance loss), results were *identical*.
>
>
Vadim, can you explain what are these additional complexities ? Is the
current version 8% slower because of changes of changes in excalibur ?
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> Sent: Thursday, July 25, 2002 4:50 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: Performance problem XSP after April 20
...
> I've re-run the test using the "content" view, thus eleminating the
> transformation step (but using a different serializer!).
>
> "current"
> simple 261 213 243 244 260 170 244
182 200 226
> "224.3"
> request 492 310 261 235 164 98 104
111 106 101
> "198.2"
> esql 260 144 164 270 246 87 93 86
91 89 "153.0"
> samples
"19
> 6"
>
> "current?cocoon-view=content"
> simple 112 114 138 97 171 77 132
86 112 104
> "114.3"
> esql 138 138 138 139 110 113 106 104
101 112 "119.9"
> request 264 148 131 146 131 76 122
139 116 117
> "139.0"
>
>
> "2002-04-20"
> samples 20 35 17 22 17 17 23
17 18 36 "22.2"
> simple 32 39 36 29 27 28 36
34 36 26 "32,3"
> request 107 223 73 102 99 49 55
51 58 50 "86.7"
> esql 119 122 142 127 41 40 46 39
47 35 "75.8"
>
> "2002-04-20?cocoon-view=content"
> simple 16 13 13 46 12 12 12
22 12 12 "17.0"
> esql 74 18 20 22 17 18 15 16
18 30 "24.8"
> request 14 13 13 12 12 19 12
12 11 12 "13.0"
>
> Oh, I've redone the "simple" test because it had a great variance in
> it. In general, variance is quite large. Occasionally, times around
> 500 ms appear within a sequence of 30 ms.
Chris,
What you use to measure time?
I timed executing of simple.xsp in Cocoon "-D 20020420" and in Cocoon
2.0.4-dev with the "for() time wget", and compared time reported by the
Cocoon in access.log.
After factoring out additional complexities in excalibur code
(responsible for 8-9% performance loss), results were *identical*.
PS I did not test HEAD though.
PPS CVS command syntax is bit different from what you wrote:
cvs -q checkout -D 20020420 xml-cocoon2
Vadim
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 24.Jul.2002 -- 07:15 PM, Sylvain Wallez wrote:
> Have you compared the generated source files ? Are they different ?
Not significantly (namely creation date &c.) -- since esql.xsl has
changed significantly between these versions the esql sample differs
at great lengths. But implanting the newer esql code into the old code
base does not change run times.
> Is this related to pizza, as suggested by Berin (i.e. does switching
> back to Javac change something) ?
According to cocoon.xconf, both use pizza.
> If not, we'll have to find what changed in the engine...
I'm afraid so.
I've re-run the test using the "content" view, thus eleminating the
transformation step (but using a different serializer!).
"current"
simple 261 213 243 244 260 170 244 182 200 226 "224.3"
request 492 310 261 235 164 98 104 111 106 101 "198.2"
esql 260 144 164 270 246 87 93 86 91 89 "153.0"
samples "19 6"
"current?cocoon-view=content"
simple 112 114 138 97 171 77 132 86 112 104 "114.3"
esql 138 138 138 139 110 113 106 104 101 112 "119.9"
request 264 148 131 146 131 76 122 139 116 117 "139.0"
"2002-04-20"
samples 20 35 17 22 17 17 23 17 18 36 "22.2"
simple 32 39 36 29 27 28 36 34 36 26 "32,3"
request 107 223 73 102 99 49 55 51 58 50 "86.7"
esql 119 122 142 127 41 40 46 39 47 35 "75.8"
"2002-04-20?cocoon-view=content"
simple 16 13 13 46 12 12 12 22 12 12 "17.0"
esql 74 18 20 22 17 18 15 16 18 30 "24.8"
request 14 13 13 12 12 19 12 12 11 12 "13.0"
Oh, I've redone the "simple" test because it had a great variance in
it. In general, variance is quite large. Occasionally, times around
500 ms appear within a sequence of 30 ms.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>Hi.
>
>After Leszek Gawron pointed out performance problems with ESQL after
>an upgrade from one snapshot to another
>http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102560380325818&w=2
>I've discovered that XSP performance has deteriorated drastically:
>
>
<snip/>
>All being reload times in milliseconds for consecutive
>reloads. "simple" is the "Simple XSP" example, "request" "Request
>Logicsheet", "esql" "Simple ESQL", and "samples" the "samples/welcome"
>static page.
>
>While "samples" is reasonable similar, all XSPs have doubled. Any
>clues?
>
>
Have you compared the generated source files ? Are they different ?
Is this related to pizza, as suggested by Berin (i.e. does switching
back to Javac change something) ?
If not, we'll have to find what changed in the engine...
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Performance problem XSP after April 20
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 24.Jul.2002 -- 01:45 PM, Vadim Gritsenko wrote:
> > From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> >
> > Hi.
> >
> > After Leszek Gawron pointed out performance problems with ESQL after
> > an upgrade from one snapshot to another
> > http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102560380325818&w=2
>
> ...
>
> > "current" version (10 days old, still HSQLDB 1.63)
>
> ...
>
> > "old" version (2002-04-20)
>
> How did you get these version (what is cvs command)?
Vadim,
off my head it's "-D '2002-04-20'" (date tag) but I really used
cervisia (KDE cvs frontend) which has an option for that...
So it should be something like
cvs -z3 -d:ext:cvs.apache.org:/home/cvs checkout -D '2002-04-20' xml-cocoon2
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Berin Loritsch <bl...@apache.org>.
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> Hi.
>
> After Leszek Gawron pointed out performance problems with
> ESQL after an upgrade from one snapshot to another
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102560380325818&w=2
I've discovered that XSP performance has deteriorated drastically:
<snip/>
All being reload times in milliseconds for consecutive
reloads. "simple" is the "Simple XSP" example, "request" "Request
Logicsheet", "esql" "Simple ESQL", and "samples" the "samples/welcome"
static page.
While "samples" is reasonable similar, all XSPs have doubled. Any clues?
Possibly the use of Pizza to compile the XSP instead of Jikes or
JavaC....
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Performance problem XSP after April 20
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
>
> Hi.
>
> After Leszek Gawron pointed out performance problems with ESQL after
> an upgrade from one snapshot to another
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102560380325818&w=2
...
> "current" version (10 days old, still HSQLDB 1.63)
...
> "old" version (2002-04-20)
How did you get these version (what is cvs command)?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org