Contents
パフォーマンスとスケーラビリティ
Bubbleチームは、スケーラビリティとパフォーマンスの最適化を常に目指しています。これは、何千もの Bubble アプリをすべて処理するための Bubble プラットフォーム（私たちのスケーラビリティとパフォーマンス）と、Bubble アプリがエンドユーザーに良い体験を提供するためのプラットフォームの両方に対する改善を意味します。
Bubbleアプリのパフォーマンスとスケーリングは、アプリの構築方法に大きく影響されます。このページでは、アプリのパフォーマンスとスケーラビリティの概要を説明するとともに、具体的なヒントを提供します。
パフォーマンスに関する一般原則とヒント
・取得するデータが少なければ少ないほど、パフォーマンスが向上する
ページロード時に100個のデータを取得するページは、100万個のデータを取得するページよりも高速にロードされます。同様に、数値などの単純なデータ型のフェッチは、MB単位のデータをフェッチするよりも高速になります。
・同様に、少数の複雑なページを持つより、多数の小さくてシンプルなページを持つ方が高速になる
・ソートやフィルタリングは、できるだけ元の検索に近い状態で行ってください。
Bubbleはすでに多くの方法でデータベースクエリを最適化しているが、データベースレベルでソートやフィルタを実行することは非常に効率的である。つまり、:sort や :filter を適用したクエリは、結果に対して何らかの操作を行った後にソートやフィルタを行うクエリよりも効率が良くなる傾向があります（例: search:count を行う方が search:group by:count よりも効率が良くなります）。
・高度なフィルタを使用すると、クエリの速度が低下することがある
基本的な原則は、もしフィルター（またはソート）が「データベース上で」実行できるなら、バブルがデータベースから最初のデータセットを取得した後に実行しなければならないフィルター（またはソート）よりも高速になるということだ。どのフィルタがデータベース上で実行され、どのフィルタが実行されないのですか？検索パレット（”Do a search for “をクリックすると表示されるサイドバー）に表示されるフィルターは、データベース上で行われるため、一般に高速です。また、:filter で適用されるフィルタは、一般に「高度な」フィルタであり、一般に速度が遅くなります。
・連鎖したクエリは並列ではなく、直列に実行される
Bubbleでは、ある検索結果を別の検索の制約条件として利用することなどが可能です。これらの検索は並列ではなく直列に実行されるので、最初の検索で多くのデータを返すと、2番目の検索が遅くなるといった具合になります。
・バブルはすでに多くのパフォーマンス最適化を行っている
Bubbleは、データベース上でクエリーを実行し、サーバー上で画像のサイズを変更し、ブラウザにJavascriptのキャッシュを指示するなど、適宜試行錯誤している。比較的単純で、比較的少量のデータを取得するクエリの実行速度が非常に遅い場合は、以下のガイダンスを参考にして、アプリのデータ階層またはクエリに何らかの最適化が可能かどうかを確認してください。
・一般に、クエリを表現する方法は単純な方が高速です
必ずしもそうとは限りませんが、経験則としてはよいでしょう。Bubbleは、最も一般的なパターンに対するデータベースの最適化に常に取り組んでいる
・ページロードのたびにデータを変更することを避ける
要素の状態を変更することは、同じ動作を実現するためにデータベースを追加で呼び出すよりもパフォーマンスが高い
・高価な計算を裏のスケジュールワークフローに移行してみる
スケジュールされたワークフローは、重いクエリを実行した後、結果をどこかに保存して後で使用することができます。これは、ページロード時に重いクエリを実行するよりもパフォーマンスが高くなります。
・ワークフローアクション「Make changes to the list of X」は慎重に使用すること
このアクションは、短いリストを素早く変更する場合には良いのですが、リストの数が増えてくると、ワークフローがタイムアウトする危険性が一気に高くなります。このアクションでタイムアウトが発生する場合は、代わりに “Schedule API Workflow on a list” を検討してください。このアクションはリストを取得し、リストの各項目に対して個別に実行する API Workflow をスケジュールするので、よりパフォーマンスが高くなります（つまり、タイムアウトのリスクが低くなります）。
Bubbleアプリのデータベースは、非常に柔軟で強力です。しかし、1つのフィールドに多くのデータを格納しようとすると、そのフィールドに関連するパフォーマンスの問題につながる可能性があります。たとえば、Blog データ型に Contents というフィールドがある場合、ブログの投稿を適切に処理できるはずです。しかし、Wikipediaのすべてのコンテンツをそのフィールドに詰め込もうとすると、おそらくうまく動作しないでしょう。より現実的には、Base64エンコードされた画像（大量のテキストです）をテキストフィールドに格納しようとすると、パフォーマンスの低下や予期せぬ動作につながる可能性があります。
ページロード時に何が起こるか？
Bubbleがページを読み込む際の大まかな流れは以下の通りです。
１．Bubbleは、すべての要素（可視および不可視）のコードを送信します。
２．Bubbleは、ページ上のすべての可視要素を描画する
３．Bubbleは、可視要素に必要なすべてのダイナミックデータを取得する
つまり
・不可視の要素は、後で表示されるまで描画されない。
・ただし、可視アイテムが不可視アイテムのデータソースを参照している場合はこの限りではありません。(ある可視の要素を別の可視の要素にかぶせることは、この文脈では後者の要素を “不可視 “にはしないことに注意してください!)
・ページの読み込み速度には、要素の種類よりも要素の数が大きく影響する
すべてのエレメントタイプは、2つの例外を除いて、性能の面でかなり似ています。
１．繰り返しグループは、レイアウトスタイルプロパティによって読み込まれるデータ量が異なります。また、繰り返し表示されるグループの各セルに含まれる要素が多いほど、ページのレンダリングにかかる時間が長くなることに注意してください。
1.2つの要素を持つ10個のセルからなる繰り返しグループは、20個の別々の要素よりも高速だが、3つの要素よりも低速である
2.ネストした繰り返しグループは、要素数に乗じる効果があるのです
２．プラグインは、使用されているかどうかにかかわらず、各ページの読み込み時にコードが含まれます。Bubble はプラグインが使用されていない場合はレンダリングしないので、これはパフォーマンスに大きな影響を与えませんが、一般的に、アプリが使用していないプラグインをアンインストールするのは良い考えです。
パフォーマンスに関する補足説明
再利用の優位性
・あるページが複数の場所で同じ検索を行う場合、Bubbleは自動的にそれらを組み合わせて一度にクエリを実行します
・スタイルズの活用がパフォーマンスの向上に貢献
・特に重い検索を実行した最初の数回は、今後の実行よりも少し遅くなるかもしれません。重いクエリが数回実行されるのを見た後、Bubbleはインデックスを構築し、今後の検索を大幅に高速化するはずです（インデックスの構築には最大で1時間ほどかかる場合があります）。
X vs Y:
・1つのフィールドを変更する12個のアクションよりも、12個のフィールドを変更するアクションの方が効率が良い
・比較的小さなリストであれば、リストを変更することは高速ですが、大きなリストでは、APIワークフローの方が、ワークフローのタイムアウトのリスクがないため、スケーラブルになります。
・大きなリストを変更する場合、リスト上の後続のアイテムに対してAPIワークフローを再帰的に呼び出すと、リスト全体に対してAPIワークフローを一度に実行するより、若干遅くなりますがスケーラブルです。
・link 要素を使用して新しいページに移動する場合、一般的に少し速くなります。これは、移動するワークフローのアクションが、ページを変更する前に他のワークフローのデータ保存を待機するためです。
・データ型Aが複数のBに接続している場合(例えば、投稿はカテゴリを持つが、投稿ごとに1つのカテゴリのみ。A = カテゴリ、B = 投稿)、Bに属するAを参照するフィールドを持つ方が一般的に優れています。A に属するすべての B をリストアップするフィールドを持つことは、そのリストが非常に長くなる場合には、あまりうまくいきません。
・APIワークフローの場合、ワークフローが処理しなければならないアイテムの数は、各アイテムのサイズよりもパフォーマンスに大きな影響を及ぼします。
容量について
技術的なことではないのですが、「容量」とは、アプリが一定時間内にどれだけの「もの」を処理できるかを示すものです。Webサイトにアクセスしてくるユーザーは、わずかな容量を使いますが、大勢のユーザーがアクセスしてくる場合は、もっと多くの容量を使います。データベースを呼び出すと容量を消費します。重いデータベースクエリーを大量に実行すると、さらに多くの容量を消費します。特定のワークフロー（サーバー上で発生するもの）を実行すると容量を使用します。同様に、アプリのAPIを呼び出すと容量を使用します。
Bubbleでは、容量の「単位」に言及することがあります。ユニット」とは、Bubbleのシステムが使用するさまざまな希少資源を重み付けして測定したもので、サーバーCPU時間、データベースCPU時間、他のバックエンドシステムなどの要素が含まれる。ユニット」の正確な計算式は、Bubbleがバックエンドシステムを追加、削除、改善するにつれて変化します。Bubbleの目標の1つは、1ユニットの容量が提供するユーザー向けパフォーマンスの量を向上させることです。
特定の Bubble 価格帯（すなわち Hobby および Personal）では、アプリは「Basic」サーバー容量を持ちます。これは、これらの価格帯の他のすべての Bubble アプリと同じコンピューティング リソースを共有することを意味します。アプリが「Professional」および「Production」階層にアップグレードされると、アプリは、そのアプリのために確保された専用または「reserved」単位の容量を得ます。容量を超えると、アプリはレート制限を受けます。専門的でない言葉でもう一度言うと、アプリは一定時間内にそれほど多くの「もの」を実行できなくなり、アプリに対するユーザーのリクエストは事実上スローダウンします。したがって、一般に、容量が多いということは、多くの「もの」が進行している場合に、アプリがより多くの「もの」を実行できることを意味します。
これには、ちょっとした工夫がある。キャパシティは、食料品店に何本のレジがあるかということに例えることができます。レジの列を増やせば、より多くのお客さまを同時にチェックアウトさせることができます。しかし、何百点もの商品をカートに入れたお客さまが来店すれば、そのお客さまはしばらくの間、レジの列を占有することになります。また、レジの列が増えたからといって、そのリソースが多いお客さまが早く終わるわけではありません。同様に、容量が増えたからといって、非常に複雑なデータベースクエリをそれほど速く実行できるわけではありません。それは、カートにたくさんの商品を入れてチェックアウトする一人のお客さんのようなものです。(Bubbleは、大規模なクエリがアプリの容量をすべて消費することを検出すると、アプリの残りの部分の妥当なユーザー体験を維持しようと、そのクエリの速度を下げます（これには注意事項があります）。したがって、特定の状況下では、容量を追加することで大きなクエリを高速に実行できる可能性があります)。
ユーザーは、左サイドナビの「ログ」から、アプリの使用容量を確認することができます。最初のグラフは、アプリが最大容量に達した時間、2番目のグラフは、最大容量に対してアプリが使用した容量が表示されます。このページのさらに下には、過去24時間以内にアプリのさまざまな部分で使用された容量の内訳を示す「サーバー容量使用状況の詳細」チャートがあります。アプリの動作が遅く、容量の限界に達している場合、予約した追加容量を購入することで解決できる場合があります。
私たちのサーバーロギングプロバイダ、AppOpticsは、我々は最大容量のグラフに使用するメトリックに制限があります。非常にアクティビティの高いバブル アプリが、長期間 (30 日間など) のログを照会しようとすると、この制限に達する可能性があります。アプリでこの現象が発生した場合は、グラフの日付範囲をより短い期間（たとえば 7 日間）に設定することを検討してください。
専用インスタンスについては？
専用インスタンスは、主に3つの方法でパフォーマンスを向上させることができます。
1.地理的条件 – 専用インスタンスは、地理的にユーザーの近くに配置することができるため、大規模な静的資産のパフォーマンスに貢献します。
2.重いデータ処理 – 専用インスタンスで大幅に高速化できます。
3.安定性 – 専用インスタンスでは、専用インスタンスをアップグレードする前にメインの Bubble クラスタでアプリをテストできます。これは、Bubble の新しいバージョンでのアプリの安定性を確保するのに役立ち、また Bubble 全体の停止リスクを排除することができます。
ただし、専用プランにすることでしかパフォーマンスが上がらないということではなく、ほとんどの場合、そうではありません。容量」セクションで説明したすべてのヒントは、アプリが専用インスタンスにあるかどうかに関係なく適用されます。
最後に
結局のところ、上記は一般的なガイドラインであり、パフォーマンスに影響を与える要因をある程度明らかにすることを目的としています。しかし、これはあくまでガイドラインです。もし、あなたのアプリの特定のケースでパフォーマンスが重要であれば、経験的に異なるアプローチをテストして、何がより速いかを確認してください。
参考英語サイト
https://manual.bubble.io/help-guides/optimizing-an-application/performance-and-scaling