XenAppおよびXenDesktop 7.11から現在のバージョンまで：遅延およびSQLブロッキングクエリの改善
遅延を伴う仲介のパフォーマンス情報は、この記事XenAppおよびXenDesktop 7.7：ゾーン、遅延、および仲介のパフォーマンスに記載されています。この記事では、XenAppおよびXenDesktop 7.11からの遅延との仲介に関する改善点について説明します。また、VDA登録時のデッドロックを防止するための機能強化についても説明します。
遅延の改善による仲介の改善
XenAppおよびXenDesktop 7.11では、コア仲介SQLコードを再確認しました。このコードでは、ロードが最も少ないVDAを特定し、そのVDAに起動リクエストを送信します。「完璧な」負荷分散アルゴリズムから「十分に良い」負荷分散アルゴリズムに切り替えることにしました。
XenAppおよびXenDesktop 7.11より前のバージョンでは、最小負荷のVDAが検索され、そのVDAが使用可能になるまで他の起動要求がロックまたはブロックされました。これにより、他のすべての仲介要求がブロックされました。
XenAppおよびXenDesktop 7.11では、現在ロックされていない最も負荷の低いワーカーが検索されます。つまり、最も負荷の少ないワーカー（おそらく2番目または3番目に負荷の少ないワーカー）を取得することはできませんが、他のすべての起動要求をロックすることなくこれを行うことができます。ロック解除された労働者が見つからない場合は、座ってロックを待ちます。十分なVDAがあれば、すべてのVDAを同時にロックすることはまれですが、その動作は以前のアルゴリズムと同じです。
一部のシナリオでは、管理者は負荷分散のわずかな違いに気づくかもしれませんが、最も負荷の低いVDAを使用しないことに注意する必要があります。
コア仲介コードには、SQL ブロッキングの問題が改善された他の場所があります。大規模なサイトでは、7.13または7.6 CU3ブローカーを使用して、現在知られているすべての機能強化を行うことをお勧めします。
パフォーマンス結果
次の表は、前の記事内のデータに 2 つのデータポイントを追加し、遅延の改善による仲介を示します。
| 製品バージョン | 7.7 | 7.11以降 | 7.7 | 7.7 | 7.11以降 |
|---|---|---|---|---|---|
| 待ち時間（ミリ秒） | 90 | 90 | 250 | 250 | 250 |
| コンカレント要求 | 48 | 48 | 36 | 48 | 48 |
| 平均応答時間 | 12.9 | 3.7 | 26.7 | - | 7.6 |
| 1 秒あたりのブローカー要求数 | 3.7 | 12.6 | 1.3 | - | 6.3 |
| エラー (%) | 0 | 0 | 4.6 | 42.8 | 0 |
| 10,000人のユーザーを起動するまでの時間 | 4時間 55秒 | 所要時間 8時間 | 2時間03分 | なし | 所要時間 6時間 |
250ミリ秒の遅延でわかるように、XenAppおよびXenDesktop 7.11は、90ミリ秒の7.7コードよりも優れたパフォーマンスを発揮するようになりました。したがって、多くのデータポイントのテストに時間を費やすのではなく、以前に失敗したものをテストしました。7.11 以降では、ブローカーと SQL Server 間の遅延があっても、リソースの仲介が速くなることがわかります。
LTSR 7.6 CU3コントローラをご利用のお客様は、同様の改善の恩恵を受けることができます。LTSR 7.6 CU3がレイテンシーとともに展開されるとは思っていませんが、これらの変更により、レイテンシーがなくてもパフォーマンスが向上します。また、LTSR 7.6 CU3がレイテンシーで導入されているお客様もいることがわかっています。
登録ストームのシリアル化
残念ながら、ロックがあることがわかっている領域はVDA登録です。ロックの理由は、ワーカーを登録するときにデッドロックを避けるためです。これで、複数の登録スレッドにわたって一貫した順序でワーカーのセッションをロックしないため、デッドロックの原因をよりよく理解できるようになりました。セッションIDでセッションロックを行い、VDA登録のデッドロックを停止します。
この動作の変更を内部でテストし、再登録スケールのテストでいくつかの問題を解決するのに役立つことがわかりました。ただし、非常に複雑な環境を使用しているお客様もいるため、このロックを完全に削除していないため、より多くのテストに時間をかけることができます。代わりに、我々は、XenAppとXenDesktop ktopを持つお客様のために、このロックの使用に調整可能を提供してきました 7.12 以降. この調整可能な設定は、XenAppおよびXenDesktop 7.12データベースの「chb_Config.Site」テーブルにあります。
select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site
SerializeMultiSessionAudits SerializeMultiSessionDeregistrations
--------------------------- ------------------------------------
1 1
これらのフラグを 0 に設定すると、ロックの使用が解除されます。
update chb_config.Site set SerializeMultiSessionAudits=0, SerializeMultiSessionDeregistrations=0
select SerializeMultiSessionAudits, SerializeMultiSessionDeregistrations from chb_config.Site
(1 row(s) affected)
SerializeMultiSessionAudits SerializeMultiSessionDeregistrations
--------------------------- ------------------------------------
0 0
XenApp およびXenDesktop 7.15以降、このロックはデフォルトで無効になっています。また、XenAppおよびXenDesktop 7.15以降にアップグレードすると、ロックが無効になります。調整可能は、ロックを再度有効にする必要があるお客様向けに提供されます。
この記事は、Chris Gilbert によって書かれたブログ記事から変更されました。元のブログを読み、コメントを表示するには、https://www.citrix.com/blogs/2017/03/06/latency-and-sql-blocking-query-improvements/にアクセスしてください。