XSLTのパフォーマンスに関する考慮事項

Question

私は次のテクノロジーを使用したプロジェクトに取り組んでいます。 Java、XML、XSL

XMLを多用しています。かなり頻繁に私は - あるXML文書を別のものに変換する必要があります。 - いくつかのビジネスロジックを適用した後に1つのXML文書を別のものに変換します。

すべてがEARに組み込まれ、アプリケーションサーバーにデプロイされます。ユーザー数が膨大なので、コーディング標準を定義する前に、パフォーマンスを考慮する必要があります。

私はXSLの大ファンではありませんが、このシナリオではXSLを使用する方が良いかどうかを理解しようとしています。 XMLをXML形式に変換する必要があることに注意してください。 HTMLなどの他の形式にXMLを変換するための要件が​​ありません。

XMLからXMLへの変換にXLSTを使用するよりも、Javaの方が性能と操作性が優れていますか？

Answer 1

Saxon（無料版で利用可能）などの最新のXSLTプロセッサを使用している場合、パフォーマンスはかなり良いとわかります。また、長期的には、XSL変換はハードコードされたJavaクラスよりもはるかにメンテナンス可能です。

を使用すると、パフォーマンスのボトルネックを持っている場合、それはXSLT処理されません、アプリケーションのこの種の私の以前の経験から

Answer 2

（私はサクソンの著者と接続されていません）。 （唯一の例外は、処理が非常に複雑でプログラマーがXSLTで非常に不慣れな場合です。）大規模な文書を処理する場合は、XMLの解析やシリアライゼーションにパフォーマンスのボトルネックが存在する可能性がありますが、 。

単純な変換は、Javaの場合よりもXSLTの方がはるかに簡単です。複雑な変換は、通常、Javaクラスライブラリで使用可能な機能を多用していないかぎり、XSLTでコードを作成する方が簡単です（日付解析などがあります）。もちろん、これは両方の言語でコーディングするのにぴったりの人にのみ当てはまります。

もちろん、具体的な数字の話を始めるまでは、パフォーマンスに関する腕を振るだけのアドバイスはできません。

Answer 3

私は上記の回答に同意します。 XSLTは、Javaで変換を実行するよりも速く、より簡潔です。アプリケーション全体を再コンパイルせずにXSLTを変更できます（EARを再作成して再デプロイするだけです）。手作業での変換は常に速くなければなりませんが、XPATHや他の技術によって非常に凝縮された強力な表現が可能なため、コードはXSLTよりもはるかに大きくなる可能性があります。いくつかのXSLTエンジン（java提供、saxon、xalan ...）を試し、スタンドアロンIDE Altova XMLSpyのようなツールを使用してボトルネックを検出し、XSLTのデバッグとプロファイルを試みてください。同じ変換が必要な複数のXMLを処理するときに、XSLT変換をロードして再利用してください。もう1つの選択肢は、XSLTをJavaクラスにコンパイルしてより高速な解析（サクソンが可能に見える）を可能にすることですが、変更はXSLTとクラスの再コンパイルに必要なほど簡単ではありません。

XSLTとXSL-FOを使用して課金ソフトウェアの請求書を生成します。データベースからデータを抽出し、XMLファイルを作成し、XSL-FOを使用してXSLTに変換し、結果XML（FO命令）を処理してApache FOPを使用してPDFを生成します。複数ページの請求書を生成する場合、ジョブはマルチユーザー環境では1秒未満で、ユーザー要求に基づいて行われます（オンライン処理）。また、バッチ処理（請求サイクル）も行い、XSLT変換を再利用するほどジョブの処理速度が向上します。非常に大規模なPDF文書（> 100ページ）に対してのみ問題がありますが（分）、XSLTを使用したXMLからXMLへの変換ではなく、FOからXMLへの処理が最もコストがかかる作業です。

これまで述べたように、処理能力がさらに必要な場合は、プロセッサを「追加」してジョブを並行して簡単に実行できます。私はあなたがそれを使用していくつかの経験を持っている場合は、より多くのハードウェアを購入するために使用することができますXSLTを使用して保存時間だ最大限のパフォーマンスを得るためには、強力な開発ツールを使用して開発時間を節約し、ハードウェアを増やしたり、手動で「手動で」行うことができます。

ESBのような統合ツールは、あるシステム（送信者）から別のシステム（受信者）にXMLデータを適合させるXSLT変換に大きく基づいており、通常は数百の「トランザクション」（データ処理および統合）

Answer 4

ここでは経験的データに基づいて私の観察です。私は広範囲にxsltを使い、多くの場合、javaで実装されているデータプロセッサの代替として使用します。私たちが編集したデータプロセッサの中には、もう少し複雑なものがあります。主にSAXON EEをoxygenxmlエディタで使用します。ここでは、変換のパフォーマンスに関して我々が気づいたことがあります。

あまり複雑でないxslスタイルシートの場合、パフォーマンスはかなり良いです（30MBのXMLファイルを読み込み、div構造を多く含む20のhtmlコンテンツページより を生成するには2秒です）。パフォーマンスのばらつきは、ファイルのサイズの変化に対して線形またはそれ以下のように見えます。

しかし、xslスタイルシートの複雑さが変化すると、パフォーマンスの変化が指数関数的になる可能性があります（同じファイル、関数呼び出しが頻繁に呼び出され、関数が単純なxpath解決を実装しているため、 、同じファイル、2から24まで）とそれは関数と関数呼び出しの導入が大きな原因と思われるようです。 しかし、詳細なパフォーマンスレビューとコード最適化は行っていません。 （まだアルファモードで、性能はまだ私たちの限界の範囲内です - バッチジョブ）。私は、コード抽象化のアイデアを関数（テンプレートの使用に加えて）に使用した場所の多くの場所で、xsl関数が「乱用されている」ことを認めなければなりません。私の疑問は、xsltテンプレートが呼び出される性質のために、xsltプロセッサ用の実装プロシージャで多くの最終的な再帰があり、関数呼び出しが最適化されていないと高価になる可能性があるということです。 XSLT/XPATH中心になるように、xslスクリプトを書く方法での "戦略"の変更は、xlstプロセッサのパフォーマンスに役立つと考えています。たとえば、xslキーの使用。そう、はい、私たちは多分、プロセッサーが請求したものと同じくらい有罪です:)

他のパフォーマンス上の問題の1つは、メモリー使用量です。 RAMは技術的に問題ではありませんが、1回の呼び出し/変換で1GB（4GB）から6GBまでの単純なプロセッサーは、まったく正式なものではありません。多分、スケーラビリティと容量に関する懸念があります（アプリケーションと使用方法によって異なります）。これは、基礎となるxlstプロセッサーとはあまり関係がないかもしれません。また、エディターツールともっと関連しているかもしれません。これは、リアルタイムでスタイルシートをデバッグすることに大きな影響を与えます（xsltをステップ実行する）。

少数の観測： - コマンドラインまたはプロセッサの「生産」呼び出しは より良い性能を持っているが - の連続実行（XSLTプロセッサを呼び出す）ため、最初の実行が最長（10Sを言う）と連続して実行されますが、はるかに少ないを取る取ります（4秒）.Again、おそらくエディタ環境と関係があります。

しかし、プロセッサの性能は時には苦痛を伴うことがありますが、アプリケーションの要件に応じて、コードのメンテナンス、実装の容易さ、迅速性XSLTとJava（またはその他）を使用した実装を比較するときに、コードベース、コードベースのサイズ、パフォーマンスの問題を緩和したり、「受け入れられる」（最終アプリケーションがまだパフォーマンス番号で生き残れるかどうか）

.adieu！