アプリのパフォーマンスに影響する基本コンセプトを読み、理解するようにしてください。同期のパフォーマンス改善に集中することで、アプリのエンドユーザーに非常に良い影響を与えることができます。
この記事では、すべてのアプリに影響する読み取り専用の同期に焦点を当てています。データの更新も対象となる同期の速度を改善する方法については、データベース更新時の同期速度を改善するで説明しています。
同期速度とパフォーマンスを改善するには、以下の方法を検討してください。
- 効率の良いデータ プロバイダを選ぶ
- 同期中に転送されるデータの量を減らす
- 同期中に行われる（スプレッドシートの数式や仮想列での）計算の量を減らす
- データを並行して取得または計算する（アプリ内のテーブルが多い場合、またはコストのかかる仮想列が多い場合）
- より高速なネットワークを使用する（デバイスと AppSheet サーバー間の接続について）
- ユーザーが同期の開始を待たなくていいよう同期をバックグラウンドで実行する
AppSheet プラットフォームには、アプリのパフォーマンスを把握、分析、改善するためのツール（Performance Profile など）があります。
1. 効率の良いデータ プロバイダを選ぶ
AppSheet では、多くのデータ プロバイダをサポートしています。すべてのデータ プロバイダにおいて、リクエストへの応答における初期レイテンシは異なります。一般的な経験則から、以下のことが言えます。
- データベース プロバイダは、一般的にファイル システム プロバイダまたはスプレッドシート プロバイダより優れています。
- 数あるスプレッドシートのファイル システムの中でも、ウェブベースの同時実行データアクセスをサポートするためにゼロから構築された Google スプレッドシートは特に高性能です。
- Excel を使用している場合は、Dropbox や Box などの純粋なファイル システムではなく、Office365 を使用するとより効率的です。Office365 では、スプレッドシートの数式が Office365 によりクラウド内で実行されますが、Dropbox と Box では、AppSheet が Excel ファイル全体をダウンロードして数式をローカルで評価する必要があります。
現実的には、選択の余地がないかも知れません。データセットがすでに特定のデータ プロバイダ内にある場合もあるからです。
2. 転送されるデータの量を減らす
転送されるデータの量を減らすには、次のいずれか 1 つ以上を行います。
不要なデータを削除する
まず、テーブルまたはワークシート自体にある不要なデータを削除します。
- 空の行（スプレッドシートの下にある空の行も含む）を削除する。
ワークシートに空の行が大量にある場合は、これらを削除することでパフォーマンスを大幅に改善できます。 - 空の列（スプレッドシートの右にある空の列も含む）を削除する。
ワークシートに空の列がある場合は、これらを削除することでパフォーマンスを大幅に改善できます。
スプレッドシートのワークブック（つまりファイル）には、ワークシートが 1 シート以上あります。そのため、スプレッドシートのワークブックに不要なデータがないか確認します。
-
アプリケーションに必要なワークシートだけを残し、他は削除する。
余分なワークシートがあると、データ プロバイダがリクエストされたデータを取得する際にオーバーヘッドが生じます。これらのワークシートに対して行われた変更も、キャッシュの最適化を阻害する原因となります。 -
読み取り専用のテーブルはそれぞれ独立したワークブック内に配置する。
読み取り専用のテーブルをキャッシュに保存する機会が多いため、それぞれ独立したワークブックに配置すると、更新された場合にプラットフォームがより正確に追跡できます。
セキュリティ フィルタを使用する
While security filters are primarily meant to be a security feature, they can also be used as a scalability feature, as described in the following sections:
[列 X] = USEREMAIL() など）は、そのフィルタをデータソースからのデータ取得に「プッシュ」できます。つまり、データソースからのデータ取得もより効率的になり、AppSheet プロバイダに転送されるデータも少なくなります。データ パーティショニングを使用する
データをパーティションに分割して、非常に大きなデータセットを管理します。各ユーザーが必要とするのは 1 つのパーティション内のデータのみであるため、結果として、転送するデータの量が大幅に少なくなります。データ パーティションを使用して拡張するをご覧ください。
データ キャッシュを設定する
アプリは、冗長なデータ転送を回避することにより、転送されるデータ量を暗黙的に削減することもあります。アプリが前回の同期でキャッシュに保存された最新データのコピーをすでに取得している場合は、データ転送が冗長になります。キャッシングを効果的に行うために、システムはキャッシュにコピーが保存された日時を記録し、それ以降にデータソースが更新されたかどうかを確認する必要があります。
データ キャッシュの設定方法
- アプリエディタでアプリを開きます。
- [Settings] > [Performance] を選択します。
- [Sync: Cloud to Data Source] で設定します。
- アプリを保存します。
デフォルトでは新しいエディタが有効になっていますが、いつでも以前のエディタに戻すことができます。
以前のナビゲーションをお使いの場合
データ キャッシュの設定方法
- アプリエディタでアプリを開きます。
- [Behavior] > [Offline/Sync] を選択します。
- [Sync: Cloud to Data Source] で設定します。
- アプリを保存します。
| 設定 | 説明 |
| Server caching | AppSheet サーバーは、キャッシュに保存された読み取り専用テーブルのコピーを最大 5 分間維持できます。アプリが変更頻度の低い参照データに依存する場合は、テーブルを読み取り専用にして Server caching を有効にしてください。 |
| Delta sync |
最後にテーブルが取得された時間のタイムスタンプを維持するには、このオプションを有効にします。AppSheet サーバーは同期のたびに、タイムスタンプより後にテーブルが更新されたかどうかを判断しようとします。そのうえでクラウド データソースからテーブルデータを取得します。 セキュリティ フィルタを使用するテーブルに関しては、Delta sync 設定は無視されます。
|
注意: Delta sync のオプションを使用することで同期速度が大幅に向上する可能性がありますが、計算されたフィールドに古い値が残ってしまう原因になることもあります。
- Delta sync は、Google スプレッドシートと AppSheet データベースを基にしたテーブルにのみ適用できます。これはファイルの
LastModifiedTimeプロパティをチェックして、ファイルが更新されたかどうか判断します（更新はスプレッドシートに直接行われることもあります）。Google ドライブのようなクラウド ファイル システムの場合、このタイムスタンプは絶対に正確というわけではありません。 - 外部ソースからデータを取得する数式がスプレッドシートに含まれる場合、ファイル内の計算されたデータは変更される可能性がありますが、ファイル自体に変更されたタイムスタンプが反映されない可能性があります。このデータにのみ依存している仮想列は、 再計算されません。
3. 計算の量を減らす
同期中に、次の 2 か所で計算が発生します。
- スプレッドシートの数式
- AppSheet の仮想列
これらはいずれも同期の時間に大幅なオーバーヘッドを生じさせます。
スプレッドシートでは、データの計算に数式が使用されます。一部の数式は非常に高コストで、実行する際に時間がかかります。こういった数式は大幅な遅延の原因となり、最悪の場合は AppSheet を使用している際にタイムアウトが発生する場合もあります。
- スプレッドシートでは、シンプルで低コストな数式のみ使用するようにしてください。
- スプレッドシートをまたがる数式や、外部サービス（Google Finance など）を使用している数式は、同期のパフォーマンスに大きな影響を与える可能性があります。
- AppSheet サーバーは Excel ワークシートを読み取るたびにこういった数式を再計算する必要があるため、Dropbox または Box 内にある Excel をデータソースとして使用する場合は、ワークシートの数式を最低限にすることが特に重要です。
テーブル内の仮想列はアプリの数式によって定義され、同期のたびに AppSheet サーバーによって計算されます。アプリの数式は非常に強力で機能性に優れていますが、記述されるアプリの数式がとても非効率的な場合もあります。たとえば、3 つのテーブル（Products、Customers、Orders）のある Order Capture アプリに、同一 Product の Customer が注文した過去のすべての Orders の合計を調べるための Order テーブルに定義された仮想列があると仮定します。データセット全体に対してこの計算を行うと、アプリ内のデータ量によっては非常に高額になります。仮想列が同期の時間に多大な影響を与える場合は、Performance Profile にそのことが表示されます。
4. データを並行して取得または計算する
ここまで、ほとんどのアプリには複数のテーブルがあることについては触れてきませんでした。アプリにテーブルが 5 つあると仮定します。これらはデータソースから順に取得されるでしょうか。それとも並行して取得されるでしょうか。できる限り完全に並行して行われることが理想ですが、AppSheet サーバーで多くのリソースが必要になります（サーバーでそれぞれの同時リクエストに計算の同時進行スレッドが必要になります。また、同時に実行できるスレッドの合計数には上限があります）。したがって、Google はアプリのオーナーのサブスクリプション プランに基づいて並列処理を制御します。料金の高いプランほど多くの並列処理が可能です。
仮想列の値の計算に対しても、似たアプローチが取られます。
並列処理を増やしても同期が高速になるとは限りません。例えば、テーブルが 3 つあり、2 つは取得に 1 秒、もうひとつは取得に 1 分かかる場合、並列処理を増やしても認識できるほどの違いはありません。取得に 1 分かかるテーブルが他のすべてのアクティビティに影響を及ぼします。
アプリエディタ内でホストされるアプリ エミュレータで、並列処理を増やした場合の効果を試すことができます。効果はテーブル内のデータの量によって異なることにご注意ください。初期データセットでアプリを開発する際の効果は最小限ですが、アプリが使用されデータセットが成長するとより効果を発揮するようになります。
5. より高速なネットワークを使用する
多くの人は、より高速なネットワークならより速く同期できると直感的に考えます。また、同期における最大のボトルネックにも、モバイル デバイスで使用するデータ ネットワークの速さ（例えば 2G か LTE か）が関係すると考えがちです。ですが多くの状況において、この考えは単純すぎると言えます。
Google の見解
- 一般的に、同期が遅くなる最大の理由はクラウド プロバイダのレイテンシです。クラウド プロバイダと AppSheet サーバーの間の実際のデータ転送は、非常に効率的です（インターネットのスループットが高いため）。
- デバイスと AppSheet サーバーの間のネットワーク レイテンシによっても、大幅な遅延が発生する可能性があります。これは、AppSheet サーバーのクラウドから地理的に離れているお客様によく見られるケースです。
- AppSheet サーバーからモバイル デバイスへの実際のデータ転送は、通常、非常に効率的に行われます（モバイル ネットワークのスループットが優れていない場合でも、転送されるデータのボリュームに対しては十分です）。AppSheet は転送前にデータを圧縮するためです。
これらの見解は重要です。AppSheet のアプリのデータのボリュームは、一般的に比較的小さいからです。基盤となるデータセットが非常に大きいものであっても、アプリを使用する個々のユーザーが必要とするのはデータのごく一部であり、これはセキュリティ フィルタやデータ パーティショニングといったメカニズムにより可能となっています。
6. 同期をバックグラウンドで実行する
ここまで主に、同期での実際のレイテンシの軽減について説明してきました。しかし、一番重要なのはエンドユーザーが認識するレイテンシです。同期を遅らせるか、バックグラウンドで実行することによって、同期のレイテンシがユーザーに与える影響を最小限に抑えることができます。
このようにすると、トレードオフが発生します。アプリは高速で実行しているように見えても、データが古い場合があります。AppSheet にシステムの挙動を指示するには、アプリに適したバランスを選び、同期のさまざまなオプションを活用する必要があります。同期のオプションを選択する際は、次のことを検討してください。
- 同期のすべてのオプションを無効にすると、アプリはデフォルトで行が追加、更新、削除されるたび直ちに同期を行う。
- [Sync on start] を有効にして、再起動のたびにアプリが同期するようにする。これは、データが更新されない期間の上限を制限できる優れたメカニズムです。
- [Delayed sync] を有効にして、更新を直ちに同期するのではなくキューに追加する。このオプションは、離れた場所（インターネット回線が整っていない場所など）で使われるアプリに適しています。ユーザーはネットワーク状況の良い場所（オフィスなど）に戻り、[Sync] を明示的にクリックして、待機状態のすべての更新をバックエンドに同期できます。同じデータを他のユーザーが更新する可能性があるため、同期と同期の間が長くなるほど、データの競合が発生しやすくなります。
- [Automatic updates] を有効にして、データが更新されない状態を回避しレイテンシを感じさせなくする。このオプションは、ネットワークの接続性が良好な環境に適しています。アプリによる更新については、バックエンドで直ちに同期が開始されますが、ユーザーはアプリを使い続けることができます。アプリによる更新がない場合でも、システムは定期的に同期を実行して、最新のデータを保つようにします。このオプションを使うことにより、バッテリー、ネットワーク、サーバー リソースの消費が増え、必要以上に同期が行われる可能性があります。これは、ユーザーが同期を待たずにアプリを常に最新に近い状態に保つことのメリットと比較検討する必要があります。