変換時にどのXSLTが低速であるかを特定するためのUmbracoの技術はありますか？

Question

私のAzureアカウントでホストされているUmbracoサイトからのパフォーマンスが非常に低下しています。アカウントは2つのサイトを実行し、どちらもextrasmallのサイズに設定され、フェールオーバーのインスタンスが2つ実行されます。明確にするため

編集 -

各インスタンスで利用可能な2つのサイトがあります。これらの2つのサイトのうち、1つはうまく動作し、もう1つは非常に遅いです（同じインスタンス、同じIISなどから提供されていますが）。

-

私はAzureのインスタンスをチェックすることで開始し、彼らは大丈夫に見える、特に（通常ツール：タスクマネージャ、リソースモニタ、パフォーマンスモニタなど）を苦労されていません。両方のサイトはSQL Azureから実行され、そこにはほとんど遅れがないようです。

次私は?umbdebugshowtrace=trueクエリ文字列で私の低迷サイトを実行し、遅延のほとんどは、ページのライフサイクルの中で、この時点で起こっている：

Category Message FromFirst(ms) FromLast(ms) 

umbracoMacro Before performing transformation 0.858817787142857 0.000024 

Resolve Urls 0 11.9020404352381 11.043223 

umbracoMacro After performing transformation 11.9022704233333 0.000230 

は、XSLT変換が約11秒を取って実行します。

私はいくつかの調査のハッキングを行い、基本的にページ上のすべてのXSLTコントロールを1つずつ取り除きました。いずれも（個々に）いずれもハングを引き起こしていないようです。

私はこれをさらに深く掘り下げて、遅延がどこにあるのかについての情報を少し得ることができますか？

それは私がXSLT変換の問題にそれを絞り込むために十分なデータを持っていることは素晴らしいことだが、より多くの情報が素晴らしいだろう:)何かアドバイスを事前に

多くの感謝！

カール。

Answer 1

コントロールのサブセットを無効にすることは、実用的な方法だと思います。実際に

、1バイナリ検索手順と同様にこれを行うことができます：

1. ベース：あなただけの1つのコントロールを持っている場合、これはコントロールの

2. 無効に半分障害のあるコントロールであり、試してみる。非効率性が消えれば、犯人は障害のある半分にある - そうでなければ残りの半分にある。

3. 反復的に、上記の2.を問題のあるコントロールを含むコントロールのセットに適用します。

Answer 2

これは1つのインスタンスでは問題になりますが、他のインスタンスでは問題が発生しない場合は、Azureの問題の1つに遭遇している可能性があります。

XSLT変換のようなものは、かなりリソースを消費します。トランスフォームに応じて、処理するCPUの量はかなりの量になります。

インスタンスを再イメージング（リブートしない）することで確認できます。私が知ることから、Azureインフラストラクチャに新しい仮想マシンが作成されます。この仮想マシンは、別の物理マシンに配置してください。

これで問題が解決する場合は、インスタンスサイズを大きくすることを検討する価値があります。それはより多くのメモリを獲得し、CPU使用率の優先順位も高くなることも理解しています。

また、問題のあるマシンの仮想メモリが不足していないことを確認してください。多くの文字列割り当てを行うXSLT変換はメモリに余分な圧力をかけるので、余分なガベージコレクションが発生する可能性があります。

Answer 3

それは必ずしもXSLTの実行が11秒を取ったことを意味するものではありません開始した後、変換は11秒を終了しているという事実。その時間の大部分を、開始する前に必要なリソースを待つのに費やしていたかもしれません。たとえば、変換エンジンがXMLパーサーを呼び出し、XMLパーサーがリモートWebサイトから取得するDTDを要求するという一般的な原因があります。