Re: XSPectomy

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-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

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-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.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-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org