プラットフォームパフォーマンスのベストプラクティス

お知らせ：当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の英語版を参照してください。

Zoho Creator は、1 つの要件に対して複数の解決方法を選択できるプラットフォームです。ケースによっては、あるアプローチの方がパフォーマンスや効率の面で優れていることがあります。この記事では、同じ要件を実現する方法が複数ある場合に、最適な方法を選ぶための実践的なポイントを解説します。

パフォーマンス向上のための Do / Don't

要件	避けるべきこと	推奨される解決策
複数フォームで同じ項目を扱う場合	同じデータのために、フォームごとに別の項目を追加しないでください。	ルックアップ項目を使ってフォーム間のリレーションを構成してください。
比較処理	バックエンドでの計算量が多くなり、パフォーマンス低下につながるため、'contains' 演算子の使用は避けてください。'equals' 組み込み関数の方が相対的に高パフォーマンスです。	Deluge の組み込み関数 'equalsIgnoreCase' を使用してください。
複数レコードの更新	すべてのデータを取得し、コレクションをループして各レコードを個別に更新する方法は避けてください。各更新は個別のトランザクションとして扱われるため、オーバーヘッドが増え、利用可能なトランザクション数をすぐに消費してしまいます。	一括更新 Deluge タスクを使用し、1 回のトランザクションで複数の項目を更新してください。
データコレクションに対する処理	すべてのデータを取得してからループして処理を行う、またはすべてのデータを取得した後に IF チェックを行う方法は避けてください。	条件を指定し、必要なデータのみを取得するようにしてください。取得条件に、'必須' や '重複不可' に設定された項目を使用すると、パフォーマンスが向上します。同様に、システム項目（追加日時、更新日時など）を条件に利用することでも、パフォーマンス改善が期待できます。
	データをループして項目値を取り出し、計算を行う方法は避けてください。	集計関数をフェッチタスク内で直接使用してください。たとえば、sum 関数を使えば、データ取得時に合計値を計算でき、取得後に別途計算する必要がなくなります。同様に、getAll() を使用して、取得処理の一部として値をまとめて取得し、別途データをループして値を取り出す処理を避けてください。
	大量データを処理する際に、レポートのカスタムアクションボタンを使用することは避けてください。これらは同期的に実行されるため、通常利用時のアプリケーションパフォーマンスに影響を与える可能性があります。	そのようなスクリプトは、代わりにスケジュール機能を使って、営業時間外に実行するよう設定してください。
API コールの実行	コードブロック内に API スクリプトが含まれている場合、ワークフローは次のステートメントに進む前に API レスポンスを待機します。このような API コールがユーザー操作中に実行されると、ユーザーにとって目に見える遅延が発生する可能性があります。	API コールを含むワークフローは、営業時間外に実行されるようスケジュールしてください。メモ: レスポンスを待たずにスクリプトを実行できる非同期タスクも開発中です。リリース状況を確認することができます。
API コールの実行	既に用意されている Deluge タスクで実行できる処理に、API を使用しないでください。	API コールに頼るのではなく、Deluge タスクを使用し、その後に Function を呼び出して実行後ロジックを処理してください。
ページ内での計算処理	ページスクリプトなど、リアルタイムでユーザーの同時アクセスが多くなる可能性が高い場面で計算処理を行うことは避けてください。これらはページ操作中に実行されるためです。	そのような計算処理はワークフロー側に移し、ページでは計算済みの値を表示するだけにしてください。
同一フォーム内の項目に対する計算・連結	必要なすべての項目が同じフォーム内にある場合、スクリプトで計算や文字列連結を行うことは避けてください。	代わりに数式項目を使用してください。入力時にフォーム内で計算が行われるため、フォーム送信後に同じデータを取得して別途計算・値の設定を行う場合と比べて、はるかに効率的でオーバーヘッドも抑えられます。
データ更新用スケジュールの設定	「追加日時」などの項目を基準に実行されるフォームベースのスケジュールでは、フォーム内のすべてのデータを更新しないでください。複数ユーザーが同時にデータを追加したり、データをインポートしたりすると、複数のスケジュールが並行して実行され、一括更新を試みることでタイムアウトが発生する可能性があります。この問題は、複数のスケジュールが同時にトリガーされる可能性があるあらゆるシナリオで起こり得ます。	一括更新ではなく、その時点で対象となるレコードのみを更新するようにしてください。
他サービスの API 利用	複数の API コールを組み合わせて複雑なロジックを実装するのではなく、必要な計算を 1 回、または少ない回数の API コールで処理できる専用キーが用意されている場合は、それを利用してください。	たとえば Zoho Books では、複数の API を呼び出してデータをループし、請求書の総数や合計金額を計算する代わりに、response_option キーを使用して、API 側で直接計算を行うことができます。これにより、重いスクリプト処理を避け、API コールの回数も削減できます。

スクリプト最適化の例

例 1

❌ 次のようにデータを取得してから各レコードをループ処理する方法は、最も効率的とはいえません。

fetchInvoices = Invoice_form[<criteria>];
if(fetchInvoices。件数() > 0)
{
for each 請求書 in fetchInvoices
{
<操作>
}
}

✅ フェッチ処理の一部として、直接データをループする方が効率的です:

for each 請求書 in Invoice_form[<criteria>];
{
<操作>
}

例 2

❌ 次のように、値を取得するためだけにデータをループする方法:

paymentList=List(); // リスト変数を作成
for each 請求書 in PaymentAgainstInvoice[<criteria>] // 取得したデータをループ
{
paymentList。追加する(請求書。ID); // 各ループで ID を取り出し、リスト変数に追加
}

✅ 同じ処理は、組み込み関数を使うことでより効率的に実行できます:

paymentList = PaymentAgainstInvoice[<criteria>].ID。getAll(); // 上記 3 つの処理を 1 行のステートメントで実現

例 3

❌ 同様に、以下のスクリプトのようにデータをループして件数を取得するのではなく、

recordcount = 0
fetchInvoices = Invoice_form[<criteria>];
for each lineitemcount in fetchInvoices
{
recordcount = recordcount + 1;
}

✅ 代わりに集計関数を使用します:

recordcount = Invoice_form[<criteria>].件数(ID);

例 4

❌ まずデータを挿入し、その後で条件チェックを行ってから挿入したデータの値を変更する。

billID = insert into 受取請求書
[
Added_User=Zoho。loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = 受取請求書[ID == billID];
if(patient_Type == '無料')
{
fetchBill。Total_Price=0;
fetchBill。Bill_Status='完了済み';
}

✅ 代わりに、データを挿入する前に条件チェックを行います:

if(patient_Type == '無料')
{
Total_Price=0;
Bill_Status='完了済み';
}
billID = insert into 受取請求書
[
Added_User=Zoho。loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];

例 5

❌ API を使用してデータを更新し、更新後ロジックをトリガーする。

rec = Form[ID = <record_ID>];
rec。Single_line = <値>;
updateapi = Zoho。creator。updateRecord(<owner_name>, <app_link_name>, <report_link_name>, rec。ID, <new_input_values>, <other_api_params>, <connection_link_name>);

✅ 代わりに、Deluge の「データを更新」タスクを使用し、関数を使って更新後ロジックをトリガーします:

rec = Form[ID = <record_ID>];
rec。Single_line = <値>;
rec。番号 = <値>;
functionscript = thisapp.<function_with_on_success_code>(int rec。ID);

パフォーマンスに関する一般的なヒント

スクリプトの過度なネストは避けてください。
複数の独立した If 条件ではなく Else-If 構造を使用し、一致する条件が見つかった時点で評価が停止するようにします。
可能な限り組み込み関数を使用します。これらはパフォーマンス向けに最適化されています。
Try-Catchステートメントを使用して、コード内の例外を処理できます。
リアルタイムで実行する必要のないタスクは、スケジュールに移動するか、非同期タスクで処理するようにします。
バッチワークフロー機能を使用して、大量または反復的な処理を効率的かつ定期的、自動的にデータに対して実行します。データは設定したスケジュールに基づいて処理され、最大 1000 件までの小さなバッチに分割できます。これにより、大量データを一度にループ処理することを避け、営業時間外に処理を行うことができ、全体的な効率が向上します。
Environments機能を使用して変更内容をテストし、営業時間外に本番環境へ反映することで、ユーザーへの影響を最小限に抑えます。
実装前にアプリケーションとワークフローを十分に設計・モデリングしてください。多くのパフォーマンス問題は、アプリケーションロジックの設計不備に起因します。
ページなど、複数ユーザーの共通の操作ポイントとなるコンポーネントから書き込み処理を行うことは推奨されません。これらは同時に複数の書き込み処理をトリガーし、パフォーマンス問題を引き起こす可能性があります。同様に、自動採番項目でも、高い同時実行性により連番生成が同時に行われることで、遅延や競合が発生する場合があります。
システム変数（Zoho。appuri や Zoho。appname など）を活用し、この種の値をハードコーディングしないようにします。これにより、アプリケーションのリンク名や担当者名が変更されても自動的に反映されます。これは、コンポーネントを埋め込むために HTML ページ内で Deluge スクリプトを使用する場合に特に有用です。
可能な限りスクリプトではなく組み込み機能を活用してください。例えば:

値を逆方向に関連付けるスクリプトを記述する代わりに、項目プロパティの双方向ルックアップを使用する
初期値はスクリプトではなく項目プロパティで設定する
計算が必要な場合は、可能な限りスクリプトではなく数式項目を使用する

条件でインデックス付き項目を使用すると、関連データをより高速に取得できます。インデックス作成はバックエンド処理となるため、有効化の支援が必要な場合はサポート@zohocreator.com までお問い合わせください。

ロック、デッドロック、タイムアウト

Zoho Creator では、次のような競合シナリオを回避するための仕組みを採用しています:

ロック: 特に高い同時アクセスがある環境で、データの完全性と一貫性を維持するための重要かつ標準的な手順です。例えば、あるユーザーがデータを編集している間は、別のユーザーが同じデータを同時に変更できないようにする必要があります。そうしないとデータ破損につながる可能性があります。同様に、フォーム内で項目の追加・削除・更新（必須項目への変更など）を行っている間は、そのフォームに対するクエリはフォームレベルでロックされます。この期間中に対象フォームへ行われたクエリは、フォームが変更完了後に解放されるまで、実行に時間がかかったり、タイムアウトにより失敗したりする場合があります。
デッドロック:2 つ以上のリクエストが互いにロックの解放を待ち合うことで依存関係のループが発生し、その結果いずれかのリクエストが失敗する状況です。例えば、2 つのワークフローがそれぞれ 2 件のデータ（データ A とデータ B とします）を更新するとします。ワークフロー 1 が先にデータ A、次に B を更新し、ワークフロー 2 が先にデータ B、次に A を更新するような場合、両方のワークフローが同時に実行されるとデッドロックが発生する可能性があります。このケースでは、ワークフロー 1 は A を更新した後 B を待ちますが、B はワークフロー 2 が更新処理中のためロックされています。一方、ワークフロー 2 は B を更新した後 A を待ちますが、A はワークフロー 1 によってロックされており、ワークフロー 1 は B の更新が完了するまでデータ A を解放できません。この結果、いずれかのワークフローが失敗します。これを防ぐには、データ更新の順序を一貫させることが重要です。つまり、両方のワークフローで「先にデータ A、次にデータ B」を更新するように構成します。

タイムアウト: リクエストが長時間待機した場合に発生します。これは、接続性の問題のほか、ロックの解放待ち、レスポンス待ち、またはトランザクションが定められた時間制限を超えて実行されている場合などが原因となります。

Zoho Creator におけるタイムアウトの詳細:

タイムアウト	時間制限	説明
データロックタイムアウト	30 秒	リクエストがデータロックの解放を待機できる最大時間。この制限を超えると、リクエストは失敗します。
バッチワークフローのトランザクションタイムアウト	1 分	バッチワークフローが実行できる最大時間。この制限を超えると、トランザクション全体がロールバックされます。
通常ワークフローのトランザクションタイムアウト	5 分	その他すべてのワークフロータイプが実行できる最大時間。この制限を超えると、トランザクション全体がロールバックされます。
外部 API 呼び出しの読み取りタイムアウト	40 秒	API 呼び出しがタイムアウトする前にレスポンスを返すことができる最大時間。

ベストプラクティス

ロックの保持時間を最小限に抑えるため、リクエストにかかる時間を短く保つようにしてください。
Environments を使用してワークフローをテストし、実行時間を確認して潜在的な問題を洗い出します。また、各ワークフローで影響を受けるデータ件数も確認し、この件数を少なく保つことで処理時間を短縮できます。
大きなコードブロックは、小さく独立したチャンクに分割してください。
一貫したロック順序: フォームデータを編集するワークフローでは、循環待ちを避けるために、常に同じ順序でロックを取得するようにします。
同一ワークフロー内で過度に多くの API 呼び出しを行うことは避けてください。ロックの保持時間が長くなりやすくなります。

アプリのパフォーマンスの追跡

アプリのパフォーマンス

通常、すべてのアプリ画面は 2 秒以内に読み込まれるよう最適化されています。これを大きく超える遅延が発生する場合は、パフォーマンスの問題がある可能性があります。ただし、これはアプリの複雑さ、バックエンドで実行されているタスク数、コードの最適化状況などにも左右されます。効率的なアプリケーションロジックがなければ、アプリケーションを最適な状態で動作させることはできません。さらに、パフォーマンス低下の原因となっている可能性のある操作失敗を特定するために、アプリケーションログを確認できます。

プラットフォームの稼働状況

ステータスページでは、プラットフォームの稼働状況をリアルタイムで確認できます。このページでは、サービスの稼働状況、現在の応答時間、およびプラットフォームのパフォーマンス指標を確認できます。応答時間の急激な増加は、パフォーマンスの問題を示している可能性があります。これにより、パフォーマンス低下がサービス全体で発生しているのか、特定のアプリケーションに限定されているのかを判断できます。後者の場合は、アプリケーションロジックのさらなるデバッグやコードの最適化が必要になることがあります。