Qlikアプリケーションのパフォーマンス最適化するための資料です。

1. Qlik Application Performance Optimization Strategies
(QAPOS)
Qlikアプリケーションのパフォーマンス最適化戦略
QlikPerf.com
Document Author: Jeff R. Robbins
Email: Jeff.Robbins@qlik.com; jr@QlikPerf.com
Date: February 2nd
, 2020
目次
はじめに .......................................................................................................................................2
パフォーマンスライフサイクル.................................................................................................................2
QAPOS 1: オブジェクトと数式のリファクタリング ........................................................................................4
QAPOS 2: データモデルの複雑さを軽減する ............................................................................................5
QAPOS 3: ファクト行の事前集計（統合）について ....................................................................................5
QAPOS 4: ストリームライン テーブルリンク..............................................................................................6
QAPOS 5: 冗長なデータや未使用のデータの削除 .....................................................................................6
QAPOS 6: キャッシュウォーミング..........................................................................................................7
QAPOS 7: アプリケーションのセグメント化...............................................................................................8
Appendix 1: CalcTimeによるユニットパフォーマンステスト（QlikViewのみ) ...................................................9
Appendix 2: PMPTによるユニットパフォーマンステスト（QlikViewのみ) ...................................................... 10

2. はじめに
Qlik Application Performance Optimization Strategies（略称：QAPOS1）
は、QlikViewとQlik
Senseのアプリケーションにおいて、特定の最適化を識別して実装するためのフレームワークを提供します。最適化とは、経
験的に測定可能なパフォーマンスの向上をもたらすアプリケーションの変更のことで、以下の1つまたは複数の側面がありま
す:
1. レスポンスタイムの短縮
2. ハードウェアリソースの消費量の減少
3. システムの信頼性・安定性の向上
パフォーマンスライフサイクル
フトウェア・アプリケーションのパフォーマンス測定と改善は、この図に示すように循環的なプロセスです:
1
QAPOS "の発音は/kāpōs/で、ギターアクセサリーの複数形である "capos "の発音と同じです:
https://en.wikipedia.org/wiki/Capo

3. QAPOSは、パフォーマンス測定と改善のライフサイクルを以下のように促進します:
1. パフォーマンス基準の定義
基準の例を挙げます。ここで、レスポンスタイムとは、ユーザーが入力（クリック）してから、すべてのチャ
ートの計算と描画が完了するまでの時間のことであり、平均レスポンスタイムが8秒以下であることが許
容される。2
平均応答時間8秒は、1000人の同時使用ユーザーを対象とし、各ユーザーがシステムの
応答後に平均1分考えることを想定していること。3
2. ベースラインのアプリケーション、作業負荷、ハードウェア構成でのパフォーマンスを測定します。
3. アプリケーションの変更案（最適化候補）をテスト環境で適用する。このドキュメントで紹介され
ている戦略（QAPOS）は、最適化候補を特定するための領域を指定します。
4. 提案された変更の実施後にパフォーマンスを測定し、ベースラインのパフォーマンス（ステップ2）と
この変更後のパフォーマンス、およびステップ1で設定した基準とを比較する。
• シンプルな手動のストップウォッチテストは、提案された変更の追加パフォーマンステスト
を正当化するための初期結果を、QlikViewとQlik Senseの両方で提供することがで
きます。
• QlikViewでは、オブジェクトCalcTimesは、Appendix1で説明されているよう
に、有用なユニットパフォーマンステストのメカニズムを提供することができます。
PMPTは、Appendex2に記載されているように、もう一つの有用なQlikView
のユニットパフォーマンステストツールです。
• QlikSenseとQlikViewのScalability Toolsを使って、包括的なマルチユーザーシステムテストを自動
化することができます。
5. 変更後のパフォーマンスが向上した場合、その変更は有効な最適化であり、その最適化を新しいベースラインに
昇格させます。
6. 順1で定義した許容範囲内の性能が得られるまで、手順2～5を繰り返します。
以下のページでは、7つのQAPOSについて順に説明します。
2 平均値よりもパーセンタイルの方が意味があることが多いという非常に効果的な議論がこのリンクにあります。
3 パフォーマンステストにおける思考時間のシミュレーションについては、このリンクを含め、いくつかの場所で取り上げられています。

4. February 2nd
, 2020
QlikPerf.co
m
Qlik Application Performance Optimization
Strategies
Page 4 of 10
QAPOS 1: オブジェクトと数式のリファクタリング
ここでは、リファクタリングの 2 つのカテゴリー、すなわち、オブジェクトの計算時間の短縮（UI の変更を必要としない）
とオブジェクトの計算回数を減らす（UI の変更が必要な場合もあります）。
A. オブジェクトの計算時間の短縮（UIの変更なし）
Qlikオブジェクト（チャートなど）とそれに含まれる式は、SQLの集約クエリに似ています。目的の出
力を達成するために、通常、複数の可能なSQLクエリ（それぞれが異なるパフォーマンス特性を持つ）
があるのと同じように、特定の結果を達成するためにQlikオブジェクトとその構成式を構築するための
複数の方法があることがよくあります。このように、非常に強力なQlikパフォーマンス改善戦略は、次
のようなステップでオブジェクトと式のリファクタリングです:
1. 様々な選択状態でオブジェクトが示す結果を確認する。
2. オブジェクト全体（構成する式や変数を含む）を調べ、データモデルに対してどのように計算を行う
のかを理解します。
3. オリジナルのオブジェクトと同じ出力を提供する代替オブジェクトのバージョンを考え、実装する。
場合によっては、より効率的なオブジェクトの作成をサポートするために、データモデルにフィール
ドを追加することが価値あることもあります。この概念の一般的な例は、チャートの計算されたデ
ィメンションを、新しいデータモデルのフィールドに基づいたディメンションに置き換えることです。
4. オブジェクトの代替バージョンのパフォーマンスをテストします。変更後のパフォーマンスがいずれか
の代替バージョンで改善された場合、そのバージョンを新しいベースラインに昇格させます。
B. オブジェクト算出頻度の減少（UIの変更が必要な場合があります。）
Qlikの計算エンジンは、ユーザーのアクション（フィールドでの選択など）がUIオブジェクトに表示
されているデータに影響を与えることを検出した場合、すべてのUIオブジェクトを再計算します。そ
のため、特定の時点でオブジェクトの計算を無効にすることは、多くのケースで有用です。 ユーザ
ーが行う以下の手順を考えてみましょう。:
1. 「フィルターを開く」ボタンをクリックすると、ディメンションフィールドのリストボックスが表示されます。
2. ディメンション・フィールドAの値を選択します。
3. ディメンション・フィールドBの値を選択します。
4. フィルターを閉じる］ボタンをクリックすると、ディメンションフィールドのリストボックスが非表示になります。
5. チャートを見る
ユーザーが操作するたびにすべてのUIオブジェクトが再計算されると、クリックするたびに顕著な遅延が発
生し、一連の遅延からなる遅いユーザー体験を提供することになります。そのため、ユーザーが（クローズ
フィルターなどのボタンをクリックして）チャートを見たいと言うまで、リソースを多く消費するチャートの計算を
無効にした方が有利な場合があります。チャートの計算を遅延させるには、シートオブジェクトの計算条件
や表示条件を設定するだけでよい。

5. QAPOS 2: データモデルの複雑さを軽減する
テーブル数が多くなると、テーブルのトラバースが頻繁に行われるため、ランタイムの応答時間が長くなるからで
す。つまり、テーブル数が多いデータモデルは、テーブル数が少ないデータモデルよりも一般的に効率が悪くなり
ます。
25以上のテーブルを含むデータモデルのエンドユーザーのパフォーマンスを向上させるには、4つ以下のフィール
ドを持つテーブルを論理的に関連するテーブルに結合することで、テーブルの数を減らします（多対多の関係
でレコードの数が増えたり、無効なデータが発生したりする場合を除く）。データモデルのさらなる統合（およ
びランタイムパフォーマンスの向上）は、JOINやCONCATENATEなどのQlikの技術を使用して、共通の統
一されたファクトテーブルを作成することで達成できることがよくあります。
つまり、一般的には、スノーフレークスキーマよりもスタースキーマに近い特性を持つデータモデルを目
指すことを推奨します。スタースキーマではテーブルの数が少ないため、時間のかかるテーブルトラバー
サルが少なくなります。
QAPOS 3: ファクト行の事前集計（統合）について
ファクト行を統合することで、ファクトテーブルのレコード数を減らし、それに伴って応答時間を短縮することができます。次のよ
うなデータセットの例を考えてみましょう:
Transaction ID Customer ID Region <Metric Field>
1 A Z 3
2 A Z 4
3 B Z 7
このデータセットは、以下のように地域レベルで事前に集計することができます:
Region <Metric Field>
Z 14
ここでの基本的なプロセスは、エンドユーザがメトリクスを表示する必要がある最高の粒度でQlikファクトテー
ブルにメトリクスフィールドを格納することです。メトリクス・フィールドの事前集計は、Qlikデータ・ロード・スクリ
プトでGroup by構文を使って簡単に行うことができます。
トランザクションレベルのデータをより高いレベル（この例ではリージョンレベル）に集約するために必要な時
間は、（エンドユーザーが直接触れることのない）Qlikのデータ更新プロセスで消費され、（エンドユーザー
が直接体験する）アプリケーションの実行時の応答時間を短縮します。一般的に、エンドユーザーが経験す
る応答時間を短縮することは有利ですが、データ更新とアプリケーション実行時の消費時間のトレードオフは、
パフォーマンス要件とデータ更新サイクルを考慮して評価する必要があります。

6. QAPOS 4: ストリームライン テーブルリンク
テキストキーを数字キーに置き換える。Qlikデータモデルの数値キーは、テキストキーに比べて消費スペース
が少なく、実行時のパフォーマンスも速くなる可能性があります。
前述の戦略（ファクト行の統合）と同様に、実行時の応答時間とデータ更新時間の間のトレードオフを評価
する必要があります。テキストキーを数字キーに変換する（通常、Qlik AutoNumber機能を使用する）こと
で、エンドユーザーへの実行時の応答が速くなる可能性がありますが、周期的なデータ更新時間が長くなる可
能性があります。
QAPOS 5: 冗長なデータや未使用のデータの削除
データモデル内のフィールドで、チャート、UIオブジェクト、変数などで使用されていないものは、システムリソ
ースを消費しますが、何のメリットもありません。このような未使用のフィールドを特定して削除することで、
パフォーマンスを向上させることができます。
また、ETLプロセスの欠陥により、データモデル内のレコードが重複することがあります。例えば、1,000万人の
顧客がいることがわかっているのに、QlikのデータモデルのCustomersテーブルに2,000万件のレコードがある
場合、ETLプロセスのどこかでレコードの重複が発生している可能性があります（Qlikの前のETLプロセスや、
Qlikのロードスクリプト自体の中にある可能性もあります）。
理想的には、ETLプロセスを分析して、どの時点で重複したレコードが発生するかを理解し、ソースで問題を
修復する必要があります。分析に十分な時間が取れない場合は、Qlik LOADスクリプトコマンドのプレフィックス
を明確にすることで、アプリケーション構築プロセスのどの時点でも、重複レコードを排除することができる便利な
方法です。

7. QAPOS 6: キャッシュウォーミング
キャッシュウォーミングとは、アプリの公開時間と実際の人間のユーザーが最初にアクセスする時間の間に、Qlikアプリにアク
セスするユーザーをシミュレートするための自動化されたメカニズムを使用することです。Qlikアプリが公開され、キャッシュが
温められた後、実際のユーザーが同じQlikアプリにアクセスすると、計算結果は「最初から」計算されるのではなく、Qlikサ
ーバーのキャッシュから取得されます。そのため、実際のユーザーに提供される応答時間は、キャッシュが暖められなかった
場合よりも短くなります。
キャッシュを暖めるためのユーザー・シミュレーション・メカニズムは、以下のいずれかになります:
1. 一連のアクションを介してWebブラウザを駆動することができる任意の自動化されたメカニズム。
2. QSSTで構築されたQlik Sense Scalability Toolsのシナリオ。
a. 「プリキャッシング」という言葉が使われている資料がありますが、QlikSenseの場合はそれらの資料へのリン
クです。
キャッシュウォーミングを実装するために
アプリケーション自体を変更する必要が
ないため、キャッシュウォーミングは真の
アプリケーション最適化ではなく、運用
上の手順であると合理的に主張する
ことができます。
しかし、キャッシュウォーミングは、アプリ
ケーションの状態を最適化するための
メカニズムと考えることができます。
つまり、デプロイされたアプリケーションの
キャッシュ状態をコールドからウォームに
積極的に変更することで、エンドユーザー
により良いパフォーマンスを提供します。

8. QAPOS 7: アプリケーションのセグメント化
1つの論理アプリケーションを複数の物理的なQVWまたはQVFファイルに分割し、各ファイルをシームレスに
「オンデマンド」でロードすることができます。分割されたQVWやQVFは、単一のQVWやQVFよりもサイズ
が小さくなり、チャート式の集計対象となるレコードの数も少なくなるため、物理的に分割することで、エン
ド・ユーザーへの応答時間を短縮することができます。
1. ソフトウェア開発において、分解とは、大きなソフトウェアをより小さなコンポーネントに分割し、パフォ
ーマンスの向上やメンテナンスを容易にすることである。例えば、Microsoft Outlookは、単一のファ
イルではなく、ディスク上の80以上の個別ファイルで構成されています。多くのファイルで構成されて
いるとはいえ、Outlookは1つのアプリケーションです。
2. Qlikのアプリケーション開発は、ソフトウェア開発の一種であるため、Qlikのプロジェクトに分解の技術を
適用することで、レスポンスタイムを短縮してユーザーエクスペリエンスを向上させることができます。
3. 1 つの論理的な Qlik アプリケーションを複数の物理的なファイル (QVF または QVW) に分割 (「セグメ
ント化」) し、必要なときに各ファイルをシームレスにロードすることができます。セグメント化されたQVファイ
ルは、単一のモノリシックなQVファイルよりもサイズが小さく、チャート式の集約対象となるレコードのセット
も小さくなるため、この分解によりパフォーマンスが向上します。
1. アプリケーションのセグメンテーションは、2つの異なる方法で実行できます:
a. 先験的に、定期的に行われるデータ更新プロセスでアプリケーション・セグメントを構築する場合
b. aposteriori (アプリケーションセグメントがエンドユーザーの要求に基づいてアプリケーションのランタイムに構
築される)
c. 先験的なアプローチは従来から「ドキュメントチェイニング」と呼ばれ、後験的なアプローチは
「ODAG」（オンデマンドアプリ生成）と呼ばれることが多いです。しかし、どちらのアプローチも、
実際には複数のQVWを連鎖させて（またはリンクさせて）、まとまったナビゲーションパスを作
っていることに注意してください。a prioriアプローチとa posterioriアプローチの唯一の違いは、
アプリケーションセグメントのQVWの作成が、仕様に基づいてプロアクティブに行われるか、ユー
ザーのランタイムリクエストに基づいてリアクティブに行われるかということです。
d. 先験的なアプローチ（「ドキュメントチェイニング」）は、ユーザーがデータをスライスする方法
が限られている場合に最も効果的であり、したがって、ユーザーの分析要件を満たす管理
可能な数のアプリケーションセグメントを作成するためのスケジュールを設定することができま
す。
e. 事後的なアプローチ（ODAG）は、ユーザーがデータをスライスする方法が非常に多く、すべ
てのスライスを事前に作成されたセグメントで実装すると、セグメントの数が増えすぎてしまい、
その多くが定期的に使用されない可能性がある場合に適したオプションです。ODAGでは、作
成されるセグメントの数は、ユーザーがダッシュボードの実行時に要求したものに限定されます。

9. Appendix 1: CalcTimeによるユニットパフォーマンステスト（QlikViewのみ)
QlikViewダッシュボードの開発中に、
CalcTimesを使って、変更によるパフォーマンス
への影響を簡単にテストすることができます。オ
ブジェクトレベルのCalcTimesは、各シートのプ
ロパティで確認できます。CalcTimeは、ユーザ
ーのアクション（クリック）からオブジェクトが計算
結果を表示するまでのミリ秒単位の壁時計の
時間です。
シートのプロパティでは、オブジェクトのリストをCalcTimeでソートすることができます。最も高いCalcTimeは、応答時間を
表しています。応答時間とは，ユーザーがクリックしてからシート上のすべてのオブジェクトの計算が完了するまでの時間を
指します。並行処理のため、オブジェクトの計算時間は加算されません。むしろ、最も高い計算時間がエンドツーエンドの
応答時間を示します。例えば、上のスクリーンショットでは、最後に完了したアクションのレスポンスタイムは3994ミリ秒であり、
これは最後のオブジェクトであるCH01が計算を完了した時間であることを示しています。
QV DesktopとQV Serverの両方に同等のサイズのハードウェアプラットフォームがあると仮定すると、QlikView
Serverを介してエンドユーザーが経験する応答時間（キャッシュされない計算の場合）は、ネットワークのレイテンシ
ーと複数のユーザー間のリソースの競合のために、一般的にQlikView DesktopのCalcTimesに反映されているベ
ストケースの数値よりも高くなります。いずれにしても、CalcTimesは、代替の実装オプションの比較ユニットパフォー
マンステストのための有用なメカニズムを提供します。
QlikView ServerとQlik Sense Serverは、クロスセッションキャッシングを提供しています。特定のアプリの計算結果や、
特定のユーザーの選択状態を保存し、後から他のユーザーに非常に素早く提供することができます。4
QlikView
Desktopでは、2回目の選択を行う直前にキャッシュをクリアしないことで、クロスセッション・キャッシングによるメリットをシ
ミュレートすることができます。キャッシュされていない状態とその結果としての高い計算時間をシミュレートするために、開
発中にClearCacheボタンを使用することができます。このClearCacheボタンは、以下のように定義されたマクロを呼び
出す必要があります:
sub ClearCache
ActiveDocument.ClearCache
msgbox
"Cache has been
cleared."end sub
4 キャッシングが最も効果を発揮するのは、複数のユーザーが共通のデータセットを使って分析する場合です。
セクションアクセスによって各ユーザーが個別のデータセットに制限される場合は、クロスセッションキャッシングは
適用されません。

10. Appendix 2: PMPTによるユニットパフォーマンステスト（QlikViewのみ)
マルチユーザーシステムのパフォーマンステストでは、パフォーマンスデータを客観的に収集します。これら
のテストは、Qlik SenseまたはQlikView Scalability Toolsで実行できます。しかし、開発者はシステ
ムテスト環境が利用可能になる前に、パフォーマンスの最適化に取り組むことを望むかもしれません。
PMPTは、QlikView Desktopの中で実行し、分析することができます。PMPTは、システム・テストの前に開
発者が実行するユニット・パフォーマンス・テスト・ユーティリティです。
Qlik Consultingから入手できるPMPTは、前のセクションで説明したCalcTimeテストよりも高いレベルの自動
化を実現しており、QlikSenseやQlikViewのScalabilityツールよりも設定の手間が少ない。