ユーザー トラフィックの最適化
抽出の更新を必要とする多くのアクティブな Tableau Server ユーザーがあり、パブリッシュされたデータ ソースがあまりない場合には、トラフィックを最適化する必要があります。
ユーザー トラフィックを最適化するタイミング
ビューの読み込み時間が遅い
サンプル パフォーマンス ワークブックの [リクエストとセッション] ダッシュボードを使用して、ビューの読み込みにかかる時間を分析します。
読み込みに 10 秒以上かかるビューが複数あり、読み込み時間の遅さが大量のセッションに対応している場合、ユーザー トラフィックによってサーバーの速度が低下していることを示している可能性があります。
ただし、特定のビューで、閲覧する時刻に関係なく読み込みに時間がかかる場合、ビューのワークブックを最適化する必要がある兆候です。ロード時間の統計 管理ビューでは、最適化する必要があるワークブックを識別できます。ワークブックを最適化する簡単な方法には、各ビューに表示する情報を減らす、ビューを分割する、フィルターの数を減らす、データ抽出を使用するなどがあります。
高いリソース使用量がユーザー トラフィックに対応している
ピーク トラフィック時刻にサーバーが高い CPU およびメモリ使用量を示している場合は、ユーザー トラフィックを最適化することをお勧めします。ピーク トラフィック時間を判断し、サーバー上の同時ユーザーの数を分析するには、[ユーザーとアクション] ダッシュボードを使用します。さらに、ビューへのアクセス量 管理ビューを使用してユーザー トラフィックがどの程度ビューへのアクセスに関与しているかを確認できます (管理機能、パブリッシュやその他のタスクを実行するのではなく)。
[ユーザー数] ビューのポイントをクリックすると、ダッシュボードには、その時点でアクティブとなっていたユーザー、およびそれらのユーザーが実行したユーザー アクションの数が表示されます。既定では、表示される唯一のユーザー アクションはユーザー ビューですが、[アクション タイプ] フィルターを使用して追加ユーザー アクションを表示できます。
同時ユーザーやビューが多数ある場合、時刻を書き留め、これをリソースの使用量と比較できるようにします。経験則として、ユーザー数は大量のユーザー アクションに比例する必要があります。ただし、この例のビューは、負荷生成テストの一貫として 1 人のユーザーに対する人工的に多数のアクションを示しています。たとえば、6 月 28 日 12 AM の大量のビューと、後ほど説明するダッシュボードのリソース使用量を比較できます。
[CPU 使用量] ダッシュボードを使用して、合計 CPU 使用量のパーセントや、各プロセスの CPU 使用量のパーセントを表示します。次の例で、6 月 28 日 12 AM における合計 CPU 使用量と VizQL サーバー プロセスの急増に注意してください。VizQL サーバー プロセスはビューを読み込んでレンダリングするため、大量のユーザー トラフィックによって最初に枯渇を示すのは VizQL サーバー プロセスです。
注: 個別プロセスの CPU 使用率の割合は、合計すると 100 パーセントを超える場合があります。これは、個別プロセスのプロセッサー利用状況は与えられたプロセッサー コアに対して測定されるためです。対照的に、合計 CPU 使用量はすべてのプロセッサー コアに対して測定されます。
[メモリ使用量] ダッシュボードを使用して、合計メモリ使用量のパーセントや、平均メモリ使用量をギガバイト単位で表示します。一般的な規則として、メモリー使用量はユーザー トラフィックと安定して増加します。ここでも、大量のトラフィックにより最初に枯渇を示すのは VizQL サーバー プロセスです。
ユーザー トラフィック用の最適化方法
以前の例で示したように、ユーザー トラフィックの高さがリソース使用率の高さに対応している場合、ユーザー トラフィック用に最適化することをお勧めします。
VizQL サーバー プロセスの数を調節する
ユーザー トラフィックを最適化する最も効果的な方法は、VizQL サーバー プロセスの数を調節することです。最初に VizQL サーバー プロセスを 1 回に 1 つずつ追加し、さらにパフォーマンス モニタリングを行って影響を測定します。VizQL サーバー プロセスは多くの CPU およびメモリを消費することがあるため、あまりにも多くのプロセスを追加すると、代わりにサーバーの速度が低下する可能性があります。一貫してメモリ使用量が高い場合、VizQL サーバー プロセスの数を減らして予約されるメモリの量を減らしてみてください。
プロセスの構成の詳細については、ノードの構成を参照してください。
他のプロセスの数を調節する
ユーザー トラフィックのパフォーマンスを改善する最も効果的な方法は VizQL サーバー プロセスの数を調節することですが、VizQL サーバー プロセスをサポートする他のプロセスを調節したり、VizQL サーバー プロセスがリソースにアクセスするのを防ぐこともできます。たとえば、VizQL サーバー プロセスはキャッシュ サーバー プロセスに頻繁に要求を行うため、キャッシュ サーバー プロセスの数を増やす場合があります。一方、バックグラウンダー プロセスは VizQL サーバー プロセスと CPU リソースを争う可能性があります。その結果、抽出の更新を頻繁に実行する必要がない場合は、バックグラウンダーに使用するプロセスの数を減らすことができます。バックグラウンダーの追加インスタンスが必要であり、クラスターで Tableau Server を実行している場合、バックグラウンダー プロセスを専用ノードに移行できます。
VizQL セッション タイムアウト制限を調節する
以前の例では、VizQL サーバー プロセスによって使用されるメモリの量はユーザー トラフィックとともに増加し、トラフィックの終了後しばらくの間、Tableau Server によって引き続き予約されます。これは、VizQL サーバー プロセスは指定された時間の各セッション用にメモリを確保するためです。VizQL サーバー プロセスが利用可能なメモリの高いパーセンテージを使用している場合、メモリをより素早く利用できるよう、各セッションのタイムアウトを削減してみてください。
これを実行するには、tsm configuration set コマンドを使用して vizqlserver.session.expiry.timeout 設定を減らします。規定値は 30 分です。
キャッシュの更新頻度を減らす
ユーザーが常に最新のデータを必要としない場合は、Tableau Server でキャッシュを作成し、できるだけデータを再使用するよう構成することで、ユーザー トラフィックを最適化できます。
これを実行するには、tsm data-access caching list コマンドを使用して更新頻度を確認します。既定では Low です。更新頻度を変更するには、tsm data-access caching set コマンドを使用します。
ビューの応答性の評価
ユーザーがビューを開くと、ビューのコンポーネントが最初に取得および解釈され、その後にユーザーの Web ブラウザーに表示されます。ほとんどのビューでは、表示レンダリング フェーズはユーザーの Web ブラウザーで行われ、これによって最速の結果と最高レベルのインタラクティブな応答性が得られます。クライアント Web ブラウザーでほとんどの操作を処理すると、帯域幅が減少し、往復要求の待機時間がなくなります。ビューが非常に複雑である場合、一般的に最適なパフォーマンスをもたらすため、Tableau Server はクライアント Web ブラウザーではなく、サーバー上でレンダリング フェーズを処理します。ビューに必要な応答性がないことが判明した場合は、クライアント Web ブラウザーではなくサーバーでビューのレンダリングを行うしきい値をテストして、変更することができます。詳細については、クライアント側レンダリングの構成を参照してください。