XenAppおよびXenDesktop 7.7：ゾーン、遅延、および仲介のパフォーマンス
ゾーン
WAN で接続された広く分散した場所にまたがる展開では、ネットワークの遅延と信頼性の問題に直面する可能性があります。複数のサイトを作成し、それぞれに個別に管理する必要がある独自の SQL Server サイトデータベースを必要とするのではなく、1 つのサイト内にゾーンを構成できます。
仲介のパフォーマンスに対する遅延時間の影響
エンドユーザーの大半は、毎日リソースを列挙して起動します。ゾーンの追加により、ユーザーはローカルブローカーが存在する限り、よりレイテンシの高いリンクを使用できるようになりました。
このレーテンシーが増加すると、必然的にエンドユーザーエクスペリエンスに影響が及ぶことになります。ユーザーが行う作業の大半では、サテライトブローカーと SQL データベース間のラウンドトリップに関連する予想される遅さが表示されます。
しかし、アプリケーションを起動するには、実際に仲介セッションに苦労があります。この課題は、アプリの起動先として最も負荷の低いVDAを選択する必要があるためです。 これはデータベーストランザクション内で発生し、デリバリーグループ内のVDAのすべての現在の負荷のスナップショットが必要です。これを実現するには、デリバリーグループ内のすべてのワーカーに対してロックを解除します。これにより、他のユーザーが同じロックを取得できなくなります（シリアル化が発生します）。また、待機し、ワーカー状態の変更（セッションイベントなど）をブロックします。
低遅延では、ロックを取ってから解放するまでの遅延は非常に小さくなります。ただし、待ち時間が長くなるにつれて、ロックが保持される時間も増加するため、ブローカーセッションへの時間が長くなります。
これをバックアップするために、さまざまなレイテンシーと発売率を見てきました。遅延はラウンドトリップ時間（RTT）であり、Verizon IP 遅延情報に基づいていました。ほとんどの RTT はリストされている最大値より低くなっていますが、いくつかの有用な RTT でテストしていることを確認したかったことに注意してください。
往復時間は10ミリ秒（ミリ秒）で、ほとんどの国間の遅延をカバーし、45ミリ秒は北米、ヨーロッパ、および日本をカバーし、90ミリ秒は大西洋横断をカバーし、160ミリ秒は太平洋横断と中南米、アジア太平洋地域をカバーし、250ミリ秒はEMEAとアジア太平洋地域をカバーします。
さまざまな同時リクエストでテストしました。12 から 60 までの値を 12 ずつ増やします。
注： テストはブローカーの遅延への影響に焦点を当てているため、VDAセッションはシミュレートされます。このテストでは、1つのデリバリーグループ内に57のVDAがあります。各テストで10,000人のユーザーを起動しようとしました。
| RTTの結果：10ミリ秒 | |||||
|---|---|---|---|---|---|
| 同時リクエスト | 12 | 24 | 36 | 48 | 60 |
| 平均応答時間 | 0.9 | 1.4 | 1.6 | 2.1 | 2.6 |
| 1秒あたりの仲介要求 | 14 | 17.8 | 22.9 | 23.2 | 22.9 |
| エラー (%) | 0 | 0 | 0 | 0 | 0 |
| 10,000人のユーザーを起動するまでの時間 | 11m 57s | 9m 24s | 7m 16s | 7m 11s | 7m 17s |
予想通り、10msはシステム上に置かれた負荷を処理するのに十分な速さであり、エラーはありませんでした。これは、ユーザーを起動する最速の方法です。最大起動レートが60人の同時ユーザーであった場合、平均応答時間は2.6秒で、10,000人のユーザーをすべて起動するのに7分17秒かかりました。
| 検索結果：45ミリ秒 | |||||
|---|---|---|---|---|---|
| 同時リクエスト | 12 | 24 | 36 | 48 | 60 |
| 平均応答時間 | 1.7 | 3.1 | 4.3 | 6.4 | 7.3 |
| 1秒あたりの仲介要求 | 7.1 | 7.8 | 8.4 | 7.5 | 8.2 |
| エラー (%) | 0 | 0 | 0 | 0.01 | 0.01 |
| 10,000人のユーザーを起動するまでの時間 | 23m 28s | 21m 19s | 19m 51s | 22m 15s | 20m 19s |
45ミリ秒で、結果はまだ良好でした。非常に高い起動率では、1人または2人のユーザーがエラーを検出しました。
注： シリアライゼーションの影響は応答時間に分かります。セッションをブローカーするには、1.7 秒から 7.3 秒に増加します。ブローカー10,000人のユーザーの合計時間は、20〜23分でした。
| RTTの結果：90ミリ秒 | |||||
|---|---|---|---|---|---|
| 同時リクエスト | 12 | 24 | 36 | 48 | 60 |
| 平均応答時間 | 2.9 | 6.4 | 9.5 | 12.9 | 16.2 |
| 1秒あたりの仲介要求 | 4.1 | 3.7 | 3.8 | 3.7 | 3.7 |
| エラー (%) | 0 | 0 | 0 | 0.01 | 0.01 |
| 10,000人のユーザーを起動するまでの時間 | 40m 30s | 44m 29s | 44m 11s | 44m 55s | 45m 04s |
90 ミリ秒の結果では、エラーはほとんど見られなかった。ただし、遅延によるトランザクションの影響は、ユーザーが 12 の同時要求を持つセッションを仲介するのに許容可能な平均時間 2.9 秒であることが明らかになり、60 の同時要求を持つセッションを仲介するために許容できない可能性が 16.2 秒に増加します。この場合、より低いレートでユーザーを仲介する方が実際には有利です。10,000人のユーザーをすべて起動するのに40〜45分かかりました。
| RTT の検索結果は160ミリ秒 | |||||
|---|---|---|---|---|---|
| 同時リクエスト | 12 | 24 | 36 | 48 | 60 |
| 平均応答時間 | 5.7 | 11.4 | 17.3 | 23.2 | 28.0 |
| 1秒あたりの仲介要求 | 2.1 | 2.1 | 2.1 | 2.1 | 2.1 |
| エラー (%) | 0 | 0 | 0.12 | 4.0 | 17.7 |
| 10,000人のユーザーを起動するまでの時間 | 時間 19メートル | 時間の短短短距離 | ハンバーグ | 時間の高さ20メートル 26秒 | - |
160 ミリ秒では、高い起動レートで重大なエラーが発生し、48 リクエストで 4% のエラー、60 リクエストで 17.7% のエラー、応答時間は 30 秒に近づいています。ただし、最大 36 件の要求では、エラー率は 0.1 パーセントで、平均仲介時間は 17 秒です。
注: 17 パーセントの失敗は考慮しにくいので、60 リクエストの起動時間を判断するのは難しいです。
このレイテンシーでは、24 の同時リクエストを渡さないことをお勧めします。また、サイトの規模は要因となる場合があります。1,000人のユーザーを起動するには約8分かかります。これは、10,000 ユーザーに対して最大 1 時間 20 分まで拡張できます。そのため、データベースへのこのレベルの待ち時間を持つ大規模なサイトはお勧めしません。
| 250ミリ秒のRTT結果結果 | |||||
|---|---|---|---|---|---|
| 同時リクエスト | 12 | 24 | 36 | 48 | 60 |
| 平均応答時間 | 9.3 | 15.4 | 26.7 | - | - |
| 1秒あたりの仲介要求 | 1.3 | 1.6 | 1.3 | - | - |
| エラー (%) | 0 | 0 | 4.6 | 42.8 | 99.0 |
| 10,000人のユーザーを起動するまでの時間 | 2h 8m 33s | 1h 46m 52s | 2h 3m 46s | - | - |
このような長い遅延では、より高い同時起動レートで多数のタイムアウトが発生しました。48 件の要求では、要求の 42.8% が失敗しました。60件のリクエストでは、タイムアウトが非常に一般的であり、リクエストの 99% が失敗したため、サイトが使用できなくなっていました。許容される起動率は、12件と24件のリクエストのみでした。このレベルの遅延で大規模なサイトを展開することはお勧めできません。1,000人のユーザーを起動すると、12の同時リクエストで13分、24の同時リクエストで11分かかりました。ユーザー数が10,000人の場合、最大2時間8分かかります。
スロットル要求
待機時間が長く、タイムアウトが多すぎることがわかった場合、XenApp/XenDesktop 7.7にレジストリキーが追加され、一定数の同時ブローカー要求のみを処理できるようになりました。StoreFront は、数秒後に制限を超えるリクエストを再試行します。これは要求をバックオフするのに役立ち、ロックキューイングを減らします。しかし、一部のユーザーは、常に不運であり、要求は常にバックアップされるため、起動時間が長くなることがあります。
キーはDWORDであり、次の場所に格納する必要があります：HKEY_LOCAL_MACHINE\Software\Citrix\DesktopServer\ThrottledRequestAddressMaxConcurrentTransactions。
キーが存在しない場合、仲介要求に制限はありません。
注： キーはDelivery Controller ごとであるため、SQL Server上のリクエストの合計をリモートコントローラ間で分割する必要があります。
概要
仲介は遅延に対しても機能しますが、リモートゾーンのサイジングには遅延を考慮する必要があります。ゾーンが大きい場合でも、そのゾーンに対してデータベースをローカルに保つことが望ましい場合があります。ゾーンが小さい場合は、リモートゾーンを使用するとうまく機能し、エンドユーザーエクスペリエンスに影響を与えずに管理コストを削減できます。
ゾーンの RTT は 250 ms 未満にすることをお勧めします。それ以降は、異なるサイトを設定することを検討してください。
この記事は、Chris Gilbert によって書かれたブログ記事から変更されました。元のブログを読み、コメントを表示するには、 https://www.citrix.com/blogs/2016/02/09/zones-latency-and-brokering-performance-2/にアクセスしてください。