本シリーズでは kintone の特性を知り、kintone を快適に利用するための考慮事項と改善策を案内します。
kintone の性能は、「同時リクエスト数」と「リクエストの処理時間」との掛け合わせで考えられ、リクエストの処理時間を短くし、同時リクエスト数も減らす構成が理想となります。

Vol.1 ではリクエストの処理時間について案内しました。
kintone の性能 Vol.1  - リクエストの処理時間
本記事では同時リクエスト数に関する考慮点と改善策について案内します。

「同時リクエスト数」は、ユーザーアクセスによるリクエスト数と、カスタマイズによる REST API リクエスト数の合計です。
ユーザーアクセスによるリクエスト数は、アクセスするページやカスタマイズの状況によって変わりますが、kintone を同時に利用する人数と読み替えてください。

性能への影響を抑えるために、カスタマイズによる REST API リクエストには制限を設けています。

1 つのドメインにつき 100 件まで同時実行が許可されており、101 件目以降のリクエストはエラーになります。
制限値を超過した場合、原因となったアプリだけではなく、ドメイン全体で REST API のリクエストがエラーとなるため、注意が必要です。
参考： kintone REST API 同時接続数の制限値はなぜあるのか

アクセスが始業/終業時など一定の時間に偏る場合、同時リクエスト数が増えます。
REST API によるリクエストが大量に送信されるシステム・カスタマイズを構築されている場合も同様に同時リクエスト数が増えます。
同じアプリや同じレコードにリクエストが集中する場合は、特に注意が必要です。

同時リクエスト数を減らせるかどうかは要件や運用に依存します。
ここでは同時リクエスト数を減らすアイデアを紹介します。

お知らせのアプリは必要最低限にする

ポータルやスペースのお知らせにアプリを貼り付けている場合、アクセス時にアプリへのリクエストが発生します。
貼り付けるアプリ数が多い場合は、不要なものがないか検討します。

実行時間の見直し

業務時間中に実行する必要のない処理は業務時間外や夜間など、利用者の少ない時間帯に実行します。

中間処理結果の保存

大量データを集計、加工して表示するような場合は中間結果を別の kintone アプリに保存します。
これにより REST API による総リクエスト数を減らせないか検討します。

差分処理

定期的に処理する場合は毎回全レコードを対象にするのではなく、前回実行分との差分のみを処理します。
たとえばレコード取得を「更新日時が前回の実行日時以降」という条件で実行します。

キャッシュ化

同じユーザーが何度もアクセスする場合はデータをセッションストレージなどに保存します。
2 回目以降のアクセス時はセッションストレージのデータを参照します。

アクセス時にリクエストしない

画面表示時に REST API を実行する場合はボタンクリックなどの操作を挟み、意識的にデータを見たい場合のみ REST API を実行します。

リクエストの処理時間を短くする

Vol.1 で紹介した「リクエストの処理時間を短くするための改善策」を実施します。
リクエストの処理時間が短くなると同時リクエスト数の減少にもつながります。
kintoneの性能 Vol.1 - リクエストの処理時間

Vol.1 と Vol.2 を通して kintone の性能や考慮事項、改善策を案内しました。

Vol.1 でもお伝えしたとおり、kintone は数千ユーザーでの利用実績も増え、一般的な業務システムやコミュニケーション用途で性能問題が発生することはほとんどありません。
しかし、同時リクエスト数が多い場合やアプリの設定が複雑な場合はその限りではありません。

kintone の特性を知り、適切に設計・実装することで、快適に kintone を使いましょう！