[jira] [Commented] (SANTUARIO-595) Performance issue in 3.0.1 (and 2.3.2) while signing XML with many references

["Adomas Birstunas (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SANTUARIO-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707324#comment-17707324 ] 

Adomas Birstunas commented on SANTUARIO-595:
--------------------------------------------

More investigation in this, see bellow:

We have 3 cases:
 * Case A) Xalan library is not presented.
 * Case B) Xalan library is presented and default implementation for XPathFactory is used
 * Case C) Xalan library is presented and org.apache.xml.security.test.dom.xalan.XalanXPathFactory implementation for XPathFactory is used
(defined through System properties and config_xalan.xml)

Transform for XPathFilter is created through org.apache.xml.security.transforms.Transform.initializeTransform(String).
For the cases A) and B) it is org.apache.xml.security.utils.JDKXPathFactory.
For the case C) it is org.apache.xml.security.test.dom.xalan.XalanXPathFactory.

The XPathFilter transformation does nothing except registers new Filter in the XMLSignatureInput field nodeFilters.

After Canonicalization transformation is performed.
It goes through all nodes in the XML and, besides canonicalization, it calls every registered filter method isNodeInclude(Node).

Method isNodeInclude(Node) invocation leads to:
XPathAPI xPathAPI = newXPathAPI();
xPathAPI.evaluate(Node, Node, String, Node)

For the cases A) and B) xPathAPI is an instance of org.apache.xml.security.utils.JDKXPathAPI.
For the case C) xPathAPI is an instance of org.apache.xml.security.test.dom.xalan.XalanXPathAPI.

Cases A) and B):
JDKXPathAPI.evaluate(Node, Node, String, Node) calls:
    XPathFactory xpf = XPathFactory.newInstance();
    and creates XPathExpression object using obtained XPathFactory, and
    invokes method evaluate(Object, QName) for it.

  For the case A) it will be
  com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl and
  com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl.
  
  For the case B) it will be
  org.apache.xpath.jaxp.XPathFactoryImpl
  org.apache.xpath.jaxp.XPathExpressionImpl.
  Xalan registers itself for java, therefore XPathFactory.newInstance() returns Xalan implementation in this case.

Case C):
XalanXPathAPI.evaluate(Node, Node, String, Node)
    creates org.apache.xpath.XPath and
    invokes method execute(XPathContext, int, PrefixResolver) for it.

As the result we have:
 * Case A) with:
org.apache.xml.security.utils.JDKXPathFactory,
org.apache.xml.security.utils.JDKXPathAPI and
com.sun.org.apache.xpath.internal.jaxp.XPathExpressionImpl
(created through com.sun.org.apache.xpath.internal.jaxp.XPathFactoryImpl).
 * Case B) with:
org.apache.xml.security.utils.JDKXPathFactory,
org.apache.xml.security.utils.JDKXPathAPI and
org.apache.xpath.jaxp.XPathExpressionImpl
(created through org.apache.xpath.jaxp.XPathFactoryImpl).
Note 1: this case is strange, since it is party jdk and partly xalan implementation.
Note 2: org.apache.xpath.jaxp.XPathExpressionImpl inside creates org.apache.xpath.XPath object and invokes execute(...) method for it.
 * Case C) with:
org.apache.xml.security.test.dom.xalan.XalanXPathFactory,
org.apache.xml.security.test.dom.xalan.XalanXPathAPI and
org.apache.xpath.XPath.

In the provided example test, xPathAPI.evaluate(Node, Node, String, Node) are invoked more than 120 000 times for every signature creation or validation.

If XPathExpression is used (cases A and B), context for the Xpath execution is created every time (> 120 000). XalanXPathAPI caches context and, therefore it is created only 100 time (one context per one transformation registered in the signature).
This context creation takes half of the time (9s from 17s in the provided example).

Xpath execution through XPathExpression is 7-8 time longer, than direct execution for org.apache.xpath.XPath. XPath execution through org.apache.xpath.jaxp.XPathExpressionImpl is not efficient in the Xalan.

The profiling data can be seen in the provided JFR files.

[^caseA_flightNoXalan.jfr]

[^caseB_flightWithXalan.jfr]

[^caseC_flightXalan.jfr]
 

> Performance issue in 3.0.1 (and 2.3.2) while signing XML with many references
> -----------------------------------------------------------------------------
>
>                 Key: SANTUARIO-595
>                 URL: https://issues.apache.org/jira/browse/SANTUARIO-595
>             Project: Santuario
>          Issue Type: Improvement
>          Components: Java
>    Affects Versions: Java 3.0.1, Java 2.3.2
>         Environment: java11
>            Reporter: Adomas Birstunas
>            Assignee: Colm O hEigeartaigh
>            Priority: Major
>         Attachments: XmlsecPerformanceTest.java, caseA_flightNoXalan.jfr, caseB_flightWithXalan.jfr, caseC_flightXalan.jfr
>
>
> XML signing and verification takes unacceptable long time if signature uses many references to the simple XML file.
> Using earlier xmlsec versions issue was fixed by including xalan library to the classpath.
> From xmlsec version 3.0.1 (and 2.3.2) this fix does not work any more.
> Therefore,
> with xmlsec version 3.0.0 and xalan (version 2.7.2) in the classpath signing and verification takes less 1s,
> and, for the same signature, with xmlsec version 3.0.1 and xalan (version 2.7.2) in the classpath, signing and verification takes more than 10s.
> It is unacceptable time for the rather simple signature.
> Test which illustrates this performance issue is attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)