2017-03-24 4 views
1

現在、かなりの期間、実際にはうまく動作しないXSL変換の原因を見つけるのに苦労しています。LuceeでのXSLTのパフォーマンスが悪い原因の特定

これまでのところ、重い負荷の下で発生する可能性があるため、サーバーが基本的にアイドル状態のときに発生する可能性があります。添付の例は、15分で158件のリクエストがあったときに発生しました。だから、言及の余地は全くありません。

変換で使用されるいくつかの外部XML文書が疑われていましたが、通常はミリ秒、場合によっては数秒でロードされるため、問題はないようですが、200秒以上要求はかかった。

問題があるかどうかを後で確認するときに、同じ変換がかなりうまく実行されます。

私たちはサーバを監視するためにFusion Reactorを実行していますが、珍しいことはありません。昨日のケースでは、CPUの負荷が高くなることもなく、通常どおりに動作するものもありませんでした。

私はFusion Reactorのプロファイラのスクリーンショットを添付しました。そこには撮影時間が表示され、結果を正しく解釈すると、時間の99%を占める "scanDocument"パートと思われます。

遅延の原因を突き止める方法はありますか?私たちは、現在実行されている

バージョンは以下のとおりです。

のUbuntu:14.04.5 LTS のJava:1.8.0_45 Lucee:4.5.4.017最終

Fusion Reactor profiler

答えて

2

まあ、99.8%でありSocketInputStream.sockerRead0だから私は遅いネットワーク接続を責めるだろう。

バイトが低速ネットワーク接続を介して到着するのをあなたはうーん、高いCPU

+0

が表示されないように、プログラムの残りの部分は、私たちの初期の疑いのように聞こえるだろうが、我々はいずれかを見ることができない、待っていますその間に出てゆくリクエストが遅くなります。私たちはすべての非https要求を記録するプロキシとしてsquidを実行しています。問題の変換には含まれていないhttps文書は含まれていません。 これは、LuceeやJava内部の内部通信の問題でもありますか? – korguell

+0

@korguell:必要なXMLファイルとXSLTファイルのローカルコピーを使って実験を行ってみませんか? – kjhughes

+0

@korguell遅いのは、私は疑わしい、おそらくあなたのネットワーク接続を監視するwiresharkまたはいくつかのUL/DLのスピードメーターツーリングを実行することができます着信ストリーム上にある? – RobAu

関連する問題