On 11/27/05, Werner Dittmann <[EMAIL PROTECTED]> wrote:
> 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.
>
You are right, anyhow is usally slower to use xpath to select elements
than using an Id, but the xml sec should only be a little slower
because of this not a big slower as it is now.

> 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?
>
That sounds good to me.

But anyhow if there are more clients that need xpath, I can improve
the performance of the slow path.
 And that is the main reoson for the beginig mail. To know what other
people needs. So please, if you need a faster xpath in your
signatures, raise your hands....


Regards,

Raul
> Regards,
> Werner
>
> Raul Benito wrote:
> > On 11/25/05, Werner Dittmann <[EMAIL PROTECTED]> 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
> >
>
>


--
http://r-bg.com

Reply via email to