XSLT性能注意事項

Question

我正在開發一個使用以下技術的項目。 Java，XML，XSL

大量使用XML。 我經常需要 - 將一個XML文檔轉換為另一個XML文檔 - 在應用一些業務邏輯之后將一個XML文檔轉換為另一個XML文檔。

所有內容都將構建到EAR中並部署在應用程序服務器上。 由於用戶數量巨大，我需要在定義編碼標准之前考慮性能。

我不是XSL的忠實粉絲，但我試圖理解在這種情況下使用XSL是否是更好的選擇，還是我應該只使用Java。 請注意，我有將XML轉換為XML格式的要求。 我沒有要求將XML轉換為HTML等其他格式的要求。

從性能和可管理性的角度來看 - 與使用XLST進行XML到XML轉換相比，JAVA不是更好的選擇嗎？

Answer 1

從我以前的這種應用程序的經驗來看，如果你有性能瓶頸，那么它就不會是XSLT處理。 （唯一的例外可能是處理非常復雜且程序員在XSLT中缺乏經驗。）如果處理大型文檔，XML解析或序列化可能存在性能瓶頸，但這些將適用於您用於轉換的任何技術。

在XSLT中進行簡單轉換比在Java中進行簡單轉換要簡單得多。 復雜的轉換在XSLT中通常也更容易編碼，除非它們大量使用Java類庫中可用的免費功能（例如，可能是日期解析）。 當然，這對於同樣適合兩種語言編碼的人來說都是如此。

當然，在你開始談論具體數字之前，不可能只提出有關性能的武器建議。

Answer 2

我同意上述回應。 與在Java中執行轉換相比，XSLT的開發速度更快，更簡潔。 您可以更改XSLT而無需重新編譯整個應用程序（只需重新創建EAR並重新部署）。 手動轉換應該總是更快，但代碼可能比XSLT大得多，因為XPATH和其他技術允許非常簡潔和強大的表達式。 嘗試幾個XSLT引擎（java提供，saxon，xalan ......）並嘗試使用獨立IDE Altova XMLSpy等工具來檢測和分析XSLT，以檢測瓶頸。 嘗試加載XSLT轉換並在處理需要相同轉換的多個XML時重用它。 另一個選擇是將XSLT編譯為Java類，允許更快的解析（saxon似乎允許它），但更改並不像您需要重新編譯XSLT和生成的類那么容易。

我們使用XSLT和XSL-FO為計費軟件生成發票。 我們從數據庫中提取數據並創建XML文件，使用XSLT使用XSL-FO對其進行轉換，並使用Apache FOP處理結果XML（FO指令）以生成PDF。 當生成多個頁面的發票時，在多用戶環境中並且基於用戶請求（在線處理）在不到一秒的時間內完成作業。 我們還進行批處理（計費周期），並且通過重用XSLT轉換可以更快地完成作業。 僅對於非常大的PDF文檔（> 100頁），我們遇到了一些麻煩（分鍾），但最昂貴的任務是始終使用FO處理XML到PDF，而不是使用XSLT處理XML到XML。

如前所述，如果您需要更多處理能力，您只需“添加”更多處理器並輕松並行完成工作。 我認為如果你有一些使用它的經驗，使用XSLT節省的時間可以用來購買更多的硬件。 這是使用強大的開發工具來節省開發時間和購買更多硬件或“手動”執行操作以獲得最佳性能的二分法。

像ESB這樣的集成工具大量基於XSLT轉換，以使XML數據從一個系統（發送方）適應另一個系統（接收方），並且通常可以在一秒鍾內執行數百個“事務”（數據處理和集成）。

Answer 3

如果您使用現代XSLT處理器，例如Saxon（免費版本），您會發現性能非常好。 此外，從長遠來看，XSL轉換將比硬編碼的Java類更易於維護。

（我與撒克遜的作者沒有關系）

Answer 4

以下是基於經驗數據的觀察結果。 我廣泛使用xslt，並且在許多情況下作為java中實現的數據處理器的替代方案。 我們編譯的一些數據處理器涉及更多。 我們主要通過oxygenxml編輯器使用SAXON EE。 以下是我們在轉型表現方面所注意到的。

對於不太復雜的xsl樣式表，性能非常好（2s讀取30MB xml文件並生成超過20個html內容頁面，具有大量div結構）。 並且相對於文件大小的變化，性能的變化似乎是線性的或更小的。

但是，當xsl樣式表的復雜性發生變化時，性能變化可能是指數級的。（相同的文件，通常在模板中引入函數調用，實現簡單的xpath分辨率，可以改變處理時間，同樣文件，從2s到24s）似乎功能和函數調用的引入似乎是一個主要的罪魁禍首。 也就是說，我們還沒有進行詳細的性能評估和代碼優化。 （仍處於alpha模式，性能仍在我們的限制范圍內 - 即批量作業）。 我必須承認，我們可能已經“濫用”了xsl函數，因為在很多地方我們都使用了代碼抽象的功能（除了使用模板）。 我懷疑，由於調用xslt模板的性質，在實現過程中可能會有很多最終的遞歸（對於xslt處理器），如果沒有優化函數調用會變得昂貴。 我們認為在編寫xsl腳本的過程中，“策略”的改變（更多以XSLT / XPATH為中心）可能有助於xlst處理器的性能。 例如，使用xsl鍵。 是的，我們可能和處理器收費一樣內疚:)

另一個性能問題是內存利用率。 雖然RAM在技術上不是問題，但是對於單個調用/轉換而言，從1GB（!!!）到6GB的簡單處理器並不完全是猶太教。 可能存在可擴展性和容量問題（取決於應用程序和使用情況）。 這可能與底層的xlst處理器關系不大，而且與編輯器工具有關。這似乎對實時調試樣式表有很大的影響（即單步執行xslt）。

很少有觀察結果： - 處理器的命令行或“生產”調用具有更好的性能 - 對於連續運行（調用xslt處理器），第一次運行時間最長（比如10s），連續運行時間要少得多（比如4s）。 ，也許與編輯環境有關。

也就是說，雖然處理器的性能有時很難，並且取決於應用程序的要求，但我認為如果你考慮這里已經提到的其他因素，例如代碼維護，易於實現，快速更改，大小在使用XSLT與Java（或其他）比較實現時，代碼庫，可以減輕性能問題，或者可以“接受”（如果最終應用程序仍然可以使用性能數字）

...再見！