この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
先日2017/04/18(火)〜2017/04/19(水)の2日間に渡り、ウェスティンホテル東京@恵比寿にて行われたカンファレンスイベント 『Tableau Conference 2017 On Tour Tokyo』。
当エントリでは、イベント2日目(2017/04/19)のテクニカルセッション『Tableau Serverビューパフォーマンスの向上』についてその内容をご紹介したいと思います。
目次
セッション情報：概要
事前に公開されていたセッションの概要情報は以下となります。
読み込み中アイコンしか表示されない Web ページにうんざりしていませんか? Tableau のダッシュボードが Tableau Desktop ではすぐに読み込まれるのに、Web ではいつまでたっても読み込まれないのはなぜだろうと思いますか? サーバー上でのダッシュボードの動作にどのような要因が関係しているか、エンドユーザーのパフォーマンス向上のために何ができるかについて学びましょう。パフォーマンスの測定やボトルネックの特定のプロセスのほか、それらのプロセスを現在の環境に適用する方法についても紹介します。
Speaker: 津久井 英樹 レベル: Jedi タイプ: ブレイクアウトセッション 場所: 桜 A
セッション内容レポート
パフォーマンス向上の大前提
まずセッションの解説を始めるにあたり、大前提となるポイントを紹介。それは
Tableau Desktopで遅ければ、Tableau Serverでも遅い(可能性が高い)
という点。
また、Tableau公式で展開されている『必読』のホワイトペーパーについても紹介がありました。こちらについては
- 視覚的なワークブック
- インタラクティブなワークブック
- 繰り返し分析出来る
- 動作の速いワークブック
- シンプルなワークブック
- 見た目の良いワークブック
というようなポイントについてのベストプラクティスがまとめられています。
キャッシングをより確実に行うには？
ダッシュボード(Viz)を読み込む仕組み
- 処理の順序は以下の通り。
- 1.クライアントからのリクエスト送信
- 2.ワークブックの読み込み/パーミッションのチェック/HTMLドキュメントの返信
- 3.ブラウザ機能の検知/ダッシュボードのリクエスト
- 4.クエリの実行/レイアウト/パッケージデータ/シリアル化/クライアントへのペイロードの送信
- 5.データの処理/DOMエレメントの作成/Vizのレンダリング
- また、処理終盤でTableau Serverが返す処理で対応するキャッシュはそれぞれ以下の様な形となっている。
- クエリの実行：クエリキャッシュ
- レイアウト：モデルキャッシュ：マーク、位置、配置等の結果が同じであれば同じ結果を返す事が出来る。レイアウトキャッシュ。
- シリアル化：レスポンスキャッシュ：jsonシリアライズされたもの。
環境によるレンダリングモードの違い
| クライアント | サーバー |
|---|---|
| 『効率的な』クライアント | 『非効率的』なクライアント |
| HTMLキャンバスを使用した ブラウザでのVizレンダリング | サーバーでのVizレンダリング |
| クライアントに『生』(に近い)データを送信 | クライアントにイメージ(.png)を送信 |
| 操作をローカルで処理＝操作性の向上 | 操作にサーバーとの通信が必要 |
レンダリングモードの決定
- v10.0で複雑度ヒューリスティックを再検討
- ダッシュボードのクライアントがより多くのレンダリングを実行
- 考慮されるようになった結果
- マークのタイプ
- データの量
- Vizのサイズ(ピクセル)
- プラットフォーム(モバイル等)
- レンダリングモードを確認するため、『?:jsdebug=y』フラグを追加
- javascript api always displays in debug mode |Tableau Community
キャッシングのポイント
- 1.ダッシュボードのサイズを固定：レイアウト描画にはダッシュボードのサイズが必要
- 2.クライアントのレンダリングが出来るかどうかに掛かっている。出来ない場合、サーバ側で画像を生成して送る事が必要になってくる。
- 3.ユーザーフィルタを避ける：行レベルのセキュリティを用いて、見せる範囲を変更する。
- 4.『相対日付』のフィルタを避ける：now()等を使ってしまうと、毎回違うパラメータでクエリが飛んでしまう。
閾値・モードは重要なポイント。レンダリングモードの判定は応答性能に応じて考えられている。(※実はTableau Publicでは実はこの辺りのデータを取っており、参考にしているとの事。ちなみにマークのタイプが5000を超えたらサーバレンダリングしているらしい)
サーバ管理者はブラウザ or モバイルでその閾値をtabadminコマンドを使って変える事も可能。
テレメトリーメトリクス
複雑性の決定要素の内容を、vizqlserverログで確認出来る。
ペイロードサイズに影響する要素
初期読み込みにおいては、『ペイロードサイズによる要素』がパフォーマンスに影響してくる。ちなみに『ペイロードサイズ』は最大積載量、データそのものの量という意味。
構成要素を変えるだけで(この場合、情報の事前取得が必要なプルダウンからテキストボックスに変更するだけで)、大きなコストダウンが図れている。
逆に、以下の要素はペイロードサイズには影響しない。
- データソースの数
- データソースのフィールド
- ワークブックのシートの数
- ダッシュボードのレイアウト/浮動ゾーン
送信するデータ量を確認するには？
ブートストラップペイロード：ペイロードはJSON。Chrome開発ツールやFiddlerで確認出来る。また、『jsdebug=y』を使って最適化を無効化も。
ダッシュボードを簡素化して、クライアントに送信するデータを削減する事も重要なポイント。
- 原則として複雑性を必要最小限に留める
- 大きなドメインのフィルターの表示では、カスタムリストかワイルドカード照合を利用する
- ペイロードサイズとその内容を確認しながらサイズを削減して行く
操作の話：応答性の要素
Tableau Vizの『操作』についても、種類に拠っては影響を及ぼす。
カスタムシェイプや透明度の操作についても実はパフォーマンスに効いてくる。(無駄に透明度の設定は行わない方が良いらしい...)
そして、利用するブラウザの種類も実は影響が大きい。現行メジャーWebブラウザの中ではGoogle Chromeが断トツに良い。
『応答性の要素』に対する推奨ルール
- フィルターに注意
- 要素数が100を超える場合、カスタムリストかワイルドカード照合のフィルタを使用する事
- 大規模なドメインフィールドで色を利用しない
- エンコーディングが増大してしまう
- Vizのマークカード『詳細レベル(LOD: Level of Detail)』に注意
- 不要なLODは排除、処理すべきデータ量やツールヒントの量を必要最小限にする
- 『マスター＋詳細』パターンのダッシュボードを使用する
- ハイライトアクションの数を制御する
- マークの透明処理を使い過ぎない
また『必要な操作を効率的に実行出来るVizを作成する』というのが何よりも重要。シンプルさが大切。
ユーザーの体感を知るには？
Tableau Serverでは管理ビューにてビューのパフォーマンスを確認する事が出来る。
また、非サポート機能ではあるが、サーバのApacheログを確認する事も可能。
- 読み込みと操作の時間に関するパフォーマンスメトリクスの収集
- サーバのApacheログでの確認
- https://server-name/inst?v=1&
- ネットワークトラフィックとログファイルサイズの増加
- tabadmin/YML設定を使用した以下の有効化が必要
tabadmin set vizqlserver.client_metrics_enabled true
tabadmin set vizqlserver.client_metrics_filter core
まとめ
という訳で『Tableau Serverビューパフォーマンスの向上』に関するセッション内容のご紹介でした。仕組みを把握し、原因を特定する事で色々と改善するポイントがある事が分かりました。ホワイトペーパー『効率的に作業できるワークブックの設計』に目を通す事はもはやTableauでビューを作成する者であれは必読の書的な感じですね。パフォーマンス改善及び、パフォーマンス改善を行わなくて済むようなワークブックの作り方をマスターして行きたいものです。
24
