santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Dittmann <Werner.Dittm...@t-online.de>
Subject Re: xmlsec 1.3 released... and now what's left.
Date Sun, 27 Nov 2005 20:18:01 GMT
Raul,

thanks for the info. If I understood you correctly then the
performance problem is due to some specific Xpath/namespace
usage for xml-sec, not a generic XPath problem to locate
some elements in a document.

Background to this question:
some specifications (WS-SecurityPolicy)
use XPath to locate the elements to process (sign, encrypt).

In case a SecurityPolicy defines a XPath I would use the XPath
to locate the element, insert a wsu:Id and use this id to add
the element to sign (as already done in WSS4J) thus avoiding any
XPath processing during signature

Any ideas to that, caveats to look at?

Regards,
Werner

Raul Benito wrote:
> On 11/25/05, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:
> 
>>Raul,
>>
>>first of all thanks for the big imporvments you did for xmlsec !!
>>
>>With respect to performance: I'm just working on JuiCE to have
>>a JCE compliant provider for the main functions of OpenSSL. First
>>tests I did (using some modes inside BouncyCastle) were promising.
>>We're waiting for some Sun action (Certificate to produce a signed
>>JCE jar).
>>
> 
> That will be good,
> Juice was the reason I'll begin to hack xml-sec: at 1.0.D2 times I
> thought the xml-sec problems was due slownes in JCE, but after seeing
> that juice speeds a lot digesting and signing but none xml-sec i begin
> to investigate inside xml-sec...
> 
> I'll think that today it will speed xml-sec a lot.(well I have
> published some figures before with xmlbench).
> 
> 
>>Just a question about YPath: AFAIK XPath is implemented
>>in Xalan, what is the problem regarding performance here? Or is
>>this a problem of xmlsec using XPath?
>>
> 
>   The root of all problems can be traced to this infamous bug in xalan:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=2650
>   In order to not be hit with this bug in xml-sec, when it c14ns any
> nodeset the XMLUtils.circumventBug2650 function is called. This method
> just visit all the nodes an copy/creates all the namespace bindings
> (the xmlns:*=... things), that contain all its ancestors.
>   I'm sure you can see that this function is a very costly operatin
> both in time and memory(creating a lot attributtes of a DOM tree is
> not cheap). But it also increase further processing time (the c14n is
> mainly o(n) where n is the number of nodes that we have just manage to
> increase, in sometimes duplicate).
>   So the xpath cannot handle big documents as it will make it bigger,
> in an exponential way( the bigger the number elements, the bigger of
> creation of new xmlns bindings).
>   The main difference between 1.1 and 1.2 is the splitting of the slow
> path(the xpath) and the fast path(no xpath), and not use the
> XMLUtils.circumventBug2650 in the fast path. And you all can see that
> it pays off.
>   The ironic of this problem is that the XMLUtils.circumventBug2650 is
> only seldom needed in the xpath(only when the xpath expression
> contains any namespace selection), so in theory we can check if
> XMLUtils.circumventBug2650 is needed and only in the small cases call
> it.
>   But xml-sec nodeset c14n methods algorithm impose that its input has
> been "circumvented", and it does not work with no circumvented
> nodesets. This behaviour can be fixed (two weeks fully dedicated) but
> we are going to end with three c14n methods:
>     - one for whole nodes.
>     - one for NOT circumvented nodesets.
>     - one for circumvented nodesets.
>   The first two will be simillar
> 
> All in All: the xpath path in xml-sec takes a hit becouse a bug in
> xalan, but this hit is avoidable with some work(three months of work
> with my current "free" time).
> 
> I hope this email is readable enough. ;)
> 
> Regards,
> 
> Raul
> 
>>Regards,
>>Werner
>>
>>PS: something that needs some "brush up" is the XMLCipher code,
>>
> 
> You are right. So many things, so few time...
> 
>>Werner
>>
>>Raul Benito wrote:
>>
>>>Hello Everybody,
>>>  After the painful release of the xmlsec(mainly because of the
>>>updating of the web page, and deadlines in my "day" job), I begin to
>>>wonder where the java xml sec should lead.
>>>
>>>>>From my area of expertise, performance:
>>>  The fast path (URI selection, only enveloping transformation)  is as
>>>fast as it can gets(about 10% overhead of plain serialization and
>>>digesting), it can only get better with JCE(70% of execution time)
>>>speed ups (Juice any one??).
>>>   Anyhow perhaps is time to improve performance in the slow(xpath
>>>transformation) path. with a little help we can get rid off the slow
>>>circunventbug call.
>>>   Or perhaps is better to pursue newer fields, I having playing with
>>>SAX and the results are impressive, documents that the DOM library can
>>>not ever dream manage the SAX handles without any memory adjustments,
>>>and fast as hell.
>>>  But SAX is not the api of mode anymore perhaps is better to take a
>>>look Stax and begin to work on it. It seems that are more projects
>>>using Stax than sax nowadays (axis, xmlbeans,...).
>>>
>>>What do you think? Where we should focus our efforts performance wise????
>>>
>>>
>>>And that's not all, jsr 105, the neglected encrypted part, xkms....
>>>New transformations, c14ns, j2me, etc...  But that's a discussion, for
>>>other thread.
>>>
>>>Regards,
>>>
>>>Raul
>>>--
>>>http://r-bg.com
>>>
>>
>>
> 
> 
> --
> http://r-bg.com
> 


Mime
View raw message