You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lenya.apache.org by an...@apache.org on 2008/02/06 17:48:04 UTC
svn commit: r619060 - in /lenya/trunk/src/modules/contactform:
config/menu.xml config/menu.xsp menus.xmap
Author: andreas
Date: Wed Feb 6 08:48:03 2008
New Revision: 619060
URL: http://svn.apache.org/viewvc?rev=619060&view=rev
Log:
Changed contactform menu from XSP to simple XML.
Added:
lenya/trunk/src/modules/contactform/config/menu.xml
- copied, changed from r618794, lenya/trunk/src/modules/contactform/config/menu.xsp
Removed:
lenya/trunk/src/modules/contactform/config/menu.xsp
lenya/trunk/src/modules/contactform/menus.xmap
Copied: lenya/trunk/src/modules/contactform/config/menu.xml (from r618794, lenya/trunk/src/modules/contactform/config/menu.xsp)
URL: http://svn.apache.org/viewvc/lenya/trunk/src/modules/contactform/config/menu.xml?p2=lenya/trunk/src/modules/contactform/config/menu.xml&p1=lenya/trunk/src/modules/contactform/config/menu.xsp&r1=618794&r2=619060&rev=619060&view=diff
==============================================================================
--- lenya/trunk/src/modules/contactform/config/menu.xsp (original)
+++ lenya/trunk/src/modules/contactform/config/menu.xml Wed Feb 6 08:48:03 2008
@@ -18,22 +18,14 @@
<!-- $Id: generic.xsp 155806 2005-03-01 17:55:42Z andreas $ -->
-<xsp:page
- language="java"
- xmlns:xsp="http://apache.org/xsp"
- xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
- xmlns:uc="http://apache.org/cocoon/lenya/usecase/1.0"
- xmlns="http://apache.org/cocoon/lenya/menubar/1.0"
->
-
- <menu>
- <menus>
- <menu i18n:attr="name" name="File">
- <block admin="false">
- <item uc:usecase="usecasedocument.create" href="?usecase=contactform.sendMessage"><i18n:text>New Contact Form</i18n:text></item>
- </block>
- </menu>
- </menus>
- </menu>
-
-</xsp:page>
+<menu xmlns="http://apache.org/cocoon/lenya/menubar/1.0"
+ xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
+ xmlns:uc="http://apache.org/cocoon/lenya/usecase/1.0">
+ <menus>
+ <menu i18n:attr="name" name="File">
+ <block admin="false">
+ <item uc:usecase="usecasedocument.create" href="?usecase=contactform.sendMessage"><i18n:text>New Contact Form</i18n:text></item>
+ </block>
+ </menu>
+ </menus>
+</menu>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@lenya.apache.org
For additional commands, e-mail: commits-help@lenya.apache.org
Re: XSPectomy
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
>
> * Powerbook G4 1.5 Ghz
> * Standard Jetty setup
> * 1 thread
> * 20 requests to /default/authoring/index.html
>
> 2.0.1: avg. 1467 ms (41/min)
> 2.0.2-dev with some modifications: avg. 929 ms (65/min)
>
>
> I didn't explicitly check if the menu XML is cached, but the authoring
> environment feels notably faster. IMO it's worth the update. Maybe
> we'll find a way to leverage caching without losing backwards
> compatibility (e.g. using include fallback elements).
>
> -- Andreas
>
>
>
Nice.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier schrieb:
>>> i'm not sure i understand vadim's comment, though:
>>>
>>>> Vadim Gritsenko - 07/Feb/08 07:28 PM You should differentiate the
>>>> case when source exists but not cacheable, and when source does not
>>>> exist. Otherwise you will be caching what must not be cached.
>>> isn't that what
>>>
>>> return (newValidity == null) ? SourceValidity.VALID
>>> : SourceValidity.INVALID;
>> I think the problem is that "Source.getValidity() == null" doesn't tell
>> you if the source doesn't exist or just can't be cached.
>
> ah, ok. i thought null meant "does not exist", and for all existing
> sources, there'd be a validity object that would indicate if it's
> cacheable or not...
I thought so too, but a look at the Excalibur Source javadocs indicates
a different behaviour, which is IMO a bit fuzzy:
**
* Get the Validity object. This can either wrap the last
modification date or
* some expiry information or anything else describing this object's
validity.
* <p>
* If it is currently not possible to calculate such an information,
* <code>null</code> is returned.
*
* @return the validity, or <code>null</code>.
*/
SourceValidity getValidity();
>> IMO the whole
>> null value business is a PITA [1]. I'll try to find out if it can
>> determined if the source really doesn't exist. Unfortunately, the
>> SitemapSource doesn't seem to be very cooperative in this regard. For
>> our scenario the patch probably works,
>
> maybe, but it's a huge potential bug....
Yes, I agree.
>> maybe we can use a
>> special-purpose subclass of the InludeTransformer / MultiSourceValidity.
>
> not so nice imho - let's keep close to cocoon. this feature would make
> sense for others as well, so it should go upstream. maybe the thread you
> started on cocoon-dev turns up something useful..
I hope so too. Maybe I get more insights into the source validity
handling after some more debugging sessions.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>> i'm not sure i understand vadim's comment, though:
>>
>>> Vadim Gritsenko - 07/Feb/08 07:28 PM You should differentiate the
>>> case when source exists but not cacheable, and when source does not
>>> exist. Otherwise you will be caching what must not be cached.
>>
>> isn't that what
>>
>> return (newValidity == null) ? SourceValidity.VALID
>> : SourceValidity.INVALID;
>
> I think the problem is that "Source.getValidity() == null" doesn't tell
> you if the source doesn't exist or just can't be cached.
ah, ok. i thought null meant "does not exist", and for all existing
sources, there'd be a validity object that would indicate if it's
cacheable or not...
> IMO the whole
> null value business is a PITA [1]. I'll try to find out if it can
> determined if the source really doesn't exist. Unfortunately, the
> SitemapSource doesn't seem to be very cooperative in this regard. For
> our scenario the patch probably works,
maybe, but it's a huge potential bug....
> maybe we can use a
> special-purpose subclass of the InludeTransformer / MultiSourceValidity.
not so nice imho - let's keep close to cocoon. this feature would make
sense for others as well, so it should go upstream. maybe the thread you
started on cocoon-dev turns up something useful..
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier schrieb:
>>> nah.
>> If the patch for https://issues.apache.org/jira/browse/COCOON-2166
>> proves useful (or we find another solution), this will fortunately
>> not be necessary.
>
> i just looked at the patch - if i understand it correctly, it's really
> slick!
>
> i'm not sure i understand vadim's comment, though:
>
>> Vadim Gritsenko - 07/Feb/08 07:28 PM You should differentiate the
>> case when source exists but not cacheable, and when source does not
>> exist. Otherwise you will be caching what must not be cached.
>
> isn't that what
>
> return (newValidity == null) ? SourceValidity.VALID
> : SourceValidity.INVALID;
I think the problem is that "Source.getValidity() == null" doesn't tell
you if the source doesn't exist or just can't be cached. IMO the whole
null value business is a PITA [1]. I'll try to find out if it can
determined if the source really doesn't exist. Unfortunately, the
SitemapSource doesn't seem to be very cooperative in this regard. For
our scenario the patch probably works, maybe we can use a
special-purpose subclass of the InludeTransformer / MultiSourceValidity.
-- Andreas
[1] http://c2.com/cgi/wiki?NoNullBeyondMethodScope
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>>
>> nah.
>
> If the patch for https://issues.apache.org/jira/browse/COCOON-2166
> proves useful (or we find another solution), this will fortunately
> not be necessary.
i just looked at the patch - if i understand it correctly, it's really
slick!
i'm not sure i understand vadim's comment, though:
> Vadim Gritsenko - 07/Feb/08 07:28 PM You should differentiate the
> case when source exists but not cacheable, and when source does not
> exist. Otherwise you will be caching what must not be cached.
isn't that what
return (newValidity == null) ? SourceValidity.VALID
: SourceValidity.INVALID;
does?
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Andreas Hartmann schrieb:
>> I did some more tests - maybe I did missed something before, but now I
>> get different results which resemble my expectations.
>>
>> * same setup as above
>> * Lenya 2.0.2-dev without modifications
>> * Fallback source URI caching enabled
>>
>> a) standard publication.xml: avg. 1200 ms
>> b) publication.xml contains only modules with menus: avg. 800 ms
>>
>> In case b), the aggregated menu XML is cached because the include
>> transformer didn't come across any non-existing sources and therefore
>> the validity could be computed.
>>
>> At the moment b) can't be enforced because the publication.xml entries
>> are also used for i18n. But I'm confident that we would find another way
>> to assemble the modules i18n catalogue.
>>
>> WDYT - can we require that publication.xml contains only modules which
>> provide a menu, and throw an exception otherwise?
>
> nah.
If the patch for https://issues.apache.org/jira/browse/COCOON-2166
proves useful (or we find another solution), this will fortunately not
be necessary.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Andreas Hartmann schrieb:
> I did some more tests - maybe I did missed something before, but now I
> get different results which resemble my expectations.
>
> * same setup as above
> * Lenya 2.0.2-dev without modifications
> * Fallback source URI caching enabled
>
> a) standard publication.xml: avg. 1200 ms
> b) publication.xml contains only modules with menus: avg. 800 ms
>
> In case b), the aggregated menu XML is cached because the include
> transformer didn't come across any non-existing sources and therefore
> the validity could be computed.
>
> At the moment b) can't be enforced because the publication.xml entries
> are also used for i18n. But I'm confident that we would find another way
> to assemble the modules i18n catalogue.
>
> WDYT - can we require that publication.xml contains only modules which
> provide a menu, and throw an exception otherwise?
nah. the current situation is bad enough (having to specify modules for
i18n). i think the only sensible behaviour from a user POV is either not
to specify any modules at all and always activate all modules (not a
good idea, but at least it's consistent), or better yet, only specify
those modules we wish to use and effectively disable all others (i.e.
not only their menus, but everything including usecases, menus and i18n).
this might make sense for security - i.e. an old abandoned module with a
critical usecase might open a security hole that no-one realizes because
it's not visible.
but that would imply another lookup each time a module resource is
resolved... dunno how much overhead that'll cause.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Andreas Hartmann schrieb:
>> Richard Frovarp schrieb:
>>> Andreas Hartmann wrote:
>>
>> [...]
>>
>>>> We wouldn't require that the module contains a menu - the
>>>> implication of the test result is that the performance degrades if
>>>> the publication.xml contains references to modules which don't
>>>> contain a menu. At least this is my interpretation, and a debugging
>>>> session indicated that this is really the case.
>>>>
>>>> So a possible approach to enforce a performant configuration would
>>>> be not to deliver an empty menu XML for those modules but to throw
>>>> an exception instead, so that the user is forced to remove the
>>>> "offending" module references from publication.xml.
>>>>
>>>> -- Andreas
>>>>
>>>>
>>>
>>> Our documentation states that the modules need to be listed to
>>> generate the menus and to access i18n messages. Something like
>>> notification doesn't have menus, but does need i18n. How would that
>>> work?
>>
>> I'm currently working on this issue. My idea is to use a generator to
>> provide a list of all available modules, and to generate a complete
>> i18n catalogue including the messages of all modules. It would of
>> course be great if this catalogue could also be cached, but I doubt
>> that this will be possible without requiring all modules to contain
>> i18n catalogues. Maybe someone has an idea how to solve this problem ...
>
> One approach would be to override the IncludeTransformer. The existence
> of the missing sources would be checked everytime the content is
> requested, and if the sources still don't exist and the other source
> validities are still valid, the cached content is returned. I think this
> is worth a try, when I find the time I'll try to implement this and do
> some more testing.
I sent a mail to cocoon-dev to see what they think about this idea.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
[...]
> One approach would be to override the IncludeTransformer. The existence
> of the missing sources would be checked everytime the content is
> requested, and if the sources still don't exist and the other source
> validities are still valid, the cached content is returned. I think this
> is worth a try, when I find the time I'll try to implement this and do
> some more testing.
This seems to work. I submitted a bug report and attached a patch:
https://issues.apache.org/jira/browse/COCOON-2166
I also refactored and simplified the i18n catalogue generation so that
the catalogue is cacheable for each publication+language combination.
Now I have the following test results:
* Lenya 2.0.2-dev
* fallback cache enabled
* patch from Cocoon issue 2166
* 20 requests to /default/authoring/index.html
-> avg. 600 ms
That's less than half the processing time of 2.0.1. I hope I didn't
introduce some simplifications which destroy functionality. Tomorrow and
on the weekend I'll do more testing.
I used to think that Java code bottlenecks have a big impact, but they
seem to be peanuts compared to overly complex and uncached pipelines.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Richard Frovarp schrieb:
>> Andreas Hartmann wrote:
>
> [...]
>
>>> We wouldn't require that the module contains a menu - the implication
>>> of the test result is that the performance degrades if the
>>> publication.xml contains references to modules which don't contain a
>>> menu. At least this is my interpretation, and a debugging session
>>> indicated that this is really the case.
>>>
>>> So a possible approach to enforce a performant configuration would be
>>> not to deliver an empty menu XML for those modules but to throw an
>>> exception instead, so that the user is forced to remove the
>>> "offending" module references from publication.xml.
>>>
>>> -- Andreas
>>>
>>>
>>
>> Our documentation states that the modules need to be listed to
>> generate the menus and to access i18n messages. Something like
>> notification doesn't have menus, but does need i18n. How would that work?
>
> I'm currently working on this issue. My idea is to use a generator to
> provide a list of all available modules, and to generate a complete i18n
> catalogue including the messages of all modules. It would of course be
> great if this catalogue could also be cached, but I doubt that this will
> be possible without requiring all modules to contain i18n catalogues.
> Maybe someone has an idea how to solve this problem ...
One approach would be to override the IncludeTransformer. The existence
of the missing sources would be checked everytime the content is
requested, and if the sources still don't exist and the other source
validities are still valid, the cached content is returned. I think this
is worth a try, when I find the time I'll try to implement this and do
some more testing.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Richard Frovarp schrieb:
> Andreas Hartmann wrote:
[...]
>> We wouldn't require that the module contains a menu - the implication
>> of the test result is that the performance degrades if the
>> publication.xml contains references to modules which don't contain a
>> menu. At least this is my interpretation, and a debugging session
>> indicated that this is really the case.
>>
>> So a possible approach to enforce a performant configuration would be
>> not to deliver an empty menu XML for those modules but to throw an
>> exception instead, so that the user is forced to remove the
>> "offending" module references from publication.xml.
>>
>> -- Andreas
>>
>>
>
> Our documentation states that the modules need to be listed to generate
> the menus and to access i18n messages. Something like notification
> doesn't have menus, but does need i18n. How would that work?
I'm currently working on this issue. My idea is to use a generator to
provide a list of all available modules, and to generate a complete i18n
catalogue including the messages of all modules. It would of course be
great if this catalogue could also be cached, but I doubt that this will
be possible without requiring all modules to contain i18n catalogues.
Maybe someone has an idea how to solve this problem ...
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
> Richard Frovarp schrieb:
>> Andreas Hartmann wrote:
>
> [...]
>
>>> I did some more tests - maybe I did missed something before, but now
>>> I get different results which resemble my expectations.
>>>
>>> * same setup as above
>>> * Lenya 2.0.2-dev without modifications
>>> * Fallback source URI caching enabled
>>>
>>> a) standard publication.xml: avg. 1200 ms
>>> b) publication.xml contains only modules with menus: avg. 800 ms
>>>
>>> In case b), the aggregated menu XML is cached because the include
>>> transformer didn't come across any non-existing sources and
>>> therefore the validity could be computed.
>>>
>>> At the moment b) can't be enforced because the publication.xml
>>> entries are also used for i18n. But I'm confident that we would find
>>> another way to assemble the modules i18n catalogue.
>>>
>>> WDYT - can we require that publication.xml contains only modules
>>> which provide a menu, and throw an exception otherwise?
>>
>> I would assume you could get away with a blank menu? Still, requiring
>> a menu seems to be a bit of a kludge when it isn't necessary for the
>> module (prettyprinting for example).
>
> We wouldn't require that the module contains a menu - the implication
> of the test result is that the performance degrades if the
> publication.xml contains references to modules which don't contain a
> menu. At least this is my interpretation, and a debugging session
> indicated that this is really the case.
>
> So a possible approach to enforce a performant configuration would be
> not to deliver an empty menu XML for those modules but to throw an
> exception instead, so that the user is forced to remove the
> "offending" module references from publication.xml.
>
> -- Andreas
>
>
Our documentation states that the modules need to be listed to generate
the menus and to access i18n messages. Something like notification
doesn't have menus, but does need i18n. How would that work?
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Richard Frovarp schrieb:
> Andreas Hartmann wrote:
[...]
>> I did some more tests - maybe I did missed something before, but now I
>> get different results which resemble my expectations.
>>
>> * same setup as above
>> * Lenya 2.0.2-dev without modifications
>> * Fallback source URI caching enabled
>>
>> a) standard publication.xml: avg. 1200 ms
>> b) publication.xml contains only modules with menus: avg. 800 ms
>>
>> In case b), the aggregated menu XML is cached because the include
>> transformer didn't come across any non-existing sources and therefore
>> the validity could be computed.
>>
>> At the moment b) can't be enforced because the publication.xml entries
>> are also used for i18n. But I'm confident that we would find another
>> way to assemble the modules i18n catalogue.
>>
>> WDYT - can we require that publication.xml contains only modules which
>> provide a menu, and throw an exception otherwise?
>
> I would assume you could get away with a blank menu? Still, requiring a
> menu seems to be a bit of a kludge when it isn't necessary for the
> module (prettyprinting for example).
We wouldn't require that the module contains a menu - the implication of
the test result is that the performance degrades if the publication.xml
contains references to modules which don't contain a menu. At least this
is my interpretation, and a debugging session indicated that this is
really the case.
So a possible approach to enforce a performant configuration would be
not to deliver an empty menu XML for those modules but to throw an
exception instead, so that the user is forced to remove the "offending"
module references from publication.xml.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
> Andreas Hartmann schrieb:
>> Andreas Hartmann schrieb:
>>
>> [...]
>>
>>>> Unfortunately we need some resource-exists selector cascades in
>>>> global-sitemap.xmap to stay backwards compatible, and therefore the
>>>> pipelines are not cacheable. When I find the time I'll do some load
>>>> testing to find out what happens when we have only static and
>>>> cacheable menu XML processing.
>>>
>>> * Powerbook G4 1.5 Ghz
>>> * Standard Jetty setup
>>> * 1 thread
>>> * 20 requests to /default/authoring/index.html
>>>
>>> 2.0.1: avg. 1467 ms (41/min)
>>> 2.0.2-dev with some modifications: avg. 929 ms (65/min)
>>>
>>>
>>> I didn't explicitly check if the menu XML is cached, but the
>>> authoring environment feels notably faster. IMO it's worth the
>>> update. Maybe we'll find a way to leverage caching without losing
>>> backwards compatibility (e.g. using include fallback elements).
>>
>> In fact the XML hadn't been cached, because the IncludeTransformer's
>> MultiSourceValidity isValid() method returns "invalid" if one of the
>> included sources was not found. I removed the "offending" modules
>> from publiction.xml. Now the XML is cached, but the load test results
>> are virtually identical. I'll do some more investigation.
>
> I did some more tests - maybe I did missed something before, but now I
> get different results which resemble my expectations.
>
> * same setup as above
> * Lenya 2.0.2-dev without modifications
> * Fallback source URI caching enabled
>
> a) standard publication.xml: avg. 1200 ms
> b) publication.xml contains only modules with menus: avg. 800 ms
>
> In case b), the aggregated menu XML is cached because the include
> transformer didn't come across any non-existing sources and therefore
> the validity could be computed.
>
> At the moment b) can't be enforced because the publication.xml entries
> are also used for i18n. But I'm confident that we would find another
> way to assemble the modules i18n catalogue.
>
> WDYT - can we require that publication.xml contains only modules which
> provide a menu, and throw an exception otherwise?
>
> -- Andreas
>
>
>
I would assume you could get away with a blank menu? Still, requiring a
menu seems to be a bit of a kludge when it isn't necessary for the
module (prettyprinting for example).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Andreas Hartmann schrieb:
>
> [...]
>
>>> Unfortunately we need some resource-exists selector cascades in
>>> global-sitemap.xmap to stay backwards compatible, and therefore the
>>> pipelines are not cacheable. When I find the time I'll do some load
>>> testing to find out what happens when we have only static and
>>> cacheable menu XML processing.
>>
>> * Powerbook G4 1.5 Ghz
>> * Standard Jetty setup
>> * 1 thread
>> * 20 requests to /default/authoring/index.html
>>
>> 2.0.1: avg. 1467 ms (41/min)
>> 2.0.2-dev with some modifications: avg. 929 ms (65/min)
>>
>>
>> I didn't explicitly check if the menu XML is cached, but the authoring
>> environment feels notably faster. IMO it's worth the update. Maybe
>> we'll find a way to leverage caching without losing backwards
>> compatibility (e.g. using include fallback elements).
>
> In fact the XML hadn't been cached, because the IncludeTransformer's
> MultiSourceValidity isValid() method returns "invalid" if one of the
> included sources was not found. I removed the "offending" modules from
> publiction.xml. Now the XML is cached, but the load test results are
> virtually identical. I'll do some more investigation.
I did some more tests - maybe I did missed something before, but now I
get different results which resemble my expectations.
* same setup as above
* Lenya 2.0.2-dev without modifications
* Fallback source URI caching enabled
a) standard publication.xml: avg. 1200 ms
b) publication.xml contains only modules with menus: avg. 800 ms
In case b), the aggregated menu XML is cached because the include
transformer didn't come across any non-existing sources and therefore
the validity could be computed.
At the moment b) can't be enforced because the publication.xml entries
are also used for i18n. But I'm confident that we would find another way
to assemble the modules i18n catalogue.
WDYT - can we require that publication.xml contains only modules which
provide a menu, and throw an exception otherwise?
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
[...]
>> Unfortunately we need some resource-exists selector cascades in
>> global-sitemap.xmap to stay backwards compatible, and therefore the
>> pipelines are not cacheable. When I find the time I'll do some load
>> testing to find out what happens when we have only static and
>> cacheable menu XML processing.
>
> * Powerbook G4 1.5 Ghz
> * Standard Jetty setup
> * 1 thread
> * 20 requests to /default/authoring/index.html
>
> 2.0.1: avg. 1467 ms (41/min)
> 2.0.2-dev with some modifications: avg. 929 ms (65/min)
>
>
> I didn't explicitly check if the menu XML is cached, but the authoring
> environment feels notably faster. IMO it's worth the update. Maybe we'll
> find a way to leverage caching without losing backwards compatibility
> (e.g. using include fallback elements).
In fact the XML hadn't been cached, because the IncludeTransformer's
MultiSourceValidity isValid() method returns "invalid" if one of the
included sources was not found. I removed the "offending" modules from
publiction.xml. Now the XML is cached, but the load test results are
virtually identical. I'll do some more investigation.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann schrieb:
> Jörn Nettingsmeier schrieb:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier schrieb:
>>>> andreas@apache.org wrote:
>>>>> Author: andreas
>>>>> Date: Wed Feb 6 08:48:03 2008
>>>>> New Revision: 619060
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=619060&view=rev
>>>>> Log:
>>>>> Changed contactform menu from XSP to simple XML.
>>>> lovely!
>>> FYI, the ultimate goal is to store all menus as static XML to enable
>>> caching for the whole menu XML. The dynamics (disabling items etc.) will
>>> be added by a final transformation. I expect this to speed up the
>>> authoring environment a bit.
>>
>> great idea.
>>
>>> I don't yet know if this can be achieved, but getting rid of the XSPs
>>> certainly doesn't hurt :)
>>
>> absolutely not! i'd like to see XSP go away entirely. one more (ugly)
>> DSL our users don't have to learn...
>>
>> to me, today's svn log is pure poetry :)
>
> Yes, it feels good to get rid of the cruft :)
>
> Unfortunately we need some resource-exists selector cascades in
> global-sitemap.xmap to stay backwards compatible, and therefore the
> pipelines are not cacheable. When I find the time I'll do some load
> testing to find out what happens when we have only static and cacheable
> menu XML processing.
* Powerbook G4 1.5 Ghz
* Standard Jetty setup
* 1 thread
* 20 requests to /default/authoring/index.html
2.0.1: avg. 1467 ms (41/min)
2.0.2-dev with some modifications: avg. 929 ms (65/min)
I didn't explicitly check if the menu XML is cached, but the authoring
environment feels notably faster. IMO it's worth the update. Maybe we'll
find a way to leverage caching without losing backwards compatibility
(e.g. using include fallback elements).
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: XSPectomy
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier schrieb:
>>> andreas@apache.org wrote:
>>>> Author: andreas
>>>> Date: Wed Feb 6 08:48:03 2008
>>>> New Revision: 619060
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=619060&view=rev
>>>> Log:
>>>> Changed contactform menu from XSP to simple XML.
>>> lovely!
>> FYI, the ultimate goal is to store all menus as static XML to enable
>> caching for the whole menu XML. The dynamics (disabling items etc.) will
>> be added by a final transformation. I expect this to speed up the
>> authoring environment a bit.
>
> great idea.
>
>> I don't yet know if this can be achieved, but getting rid of the XSPs
>> certainly doesn't hurt :)
>
> absolutely not! i'd like to see XSP go away entirely. one more (ugly)
> DSL our users don't have to learn...
>
> to me, today's svn log is pure poetry :)
Yes, it feels good to get rid of the cruft :)
Unfortunately we need some resource-exists selector cascades in
global-sitemap.xmap to stay backwards compatible, and therefore the
pipelines are not cacheable. When I find the time I'll do some load
testing to find out what happens when we have only static and cacheable
menu XML processing.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
XSPectomy
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>> andreas@apache.org wrote:
>>> Author: andreas
>>> Date: Wed Feb 6 08:48:03 2008
>>> New Revision: 619060
>>>
>>> URL: http://svn.apache.org/viewvc?rev=619060&view=rev
>>> Log:
>>> Changed contactform menu from XSP to simple XML.
>>
>> lovely!
>
> FYI, the ultimate goal is to store all menus as static XML to enable
> caching for the whole menu XML. The dynamics (disabling items etc.) will
> be added by a final transformation. I expect this to speed up the
> authoring environment a bit.
great idea.
> I don't yet know if this can be achieved, but getting rid of the XSPs
> certainly doesn't hurt :)
absolutely not! i'd like to see XSP go away entirely. one more (ugly)
DSL our users don't have to learn...
to me, today's svn log is pure poetry :)
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r619060 - in /lenya/trunk/src/modules/contactform:
config/menu.xml config/menu.xsp menus.xmap
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> andreas@apache.org wrote:
>> Author: andreas
>> Date: Wed Feb 6 08:48:03 2008
>> New Revision: 619060
>>
>> URL: http://svn.apache.org/viewvc?rev=619060&view=rev
>> Log:
>> Changed contactform menu from XSP to simple XML.
>
> lovely!
FYI, the ultimate goal is to store all menus as static XML to enable
caching for the whole menu XML. The dynamics (disabling items etc.) will
be added by a final transformation. I expect this to speed up the
authoring environment a bit.
I don't yet know if this can be achieved, but getting rid of the XSPs
certainly doesn't hurt :)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r619060 - in /lenya/trunk/src/modules/contactform:
config/menu.xml config/menu.xsp menus.xmap
Posted by Jörn Nettingsmeier <ne...@apache.org>.
andreas@apache.org wrote:
> Author: andreas
> Date: Wed Feb 6 08:48:03 2008
> New Revision: 619060
>
> URL: http://svn.apache.org/viewvc?rev=619060&view=rev
> Log:
> Changed contactform menu from XSP to simple XML.
lovely!
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org