cybozu developer network

カテゴリー内の他の記事

kintoneの性能 Vol.2 - 同時リクエスト数

本記事は kintone SIGNPOST パターン実践ガイドの「性能上の考慮点と改善策」をエンジニア向けに編集/追記した記事です。

Index

はじめに

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

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

同時リクエスト数とは

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

同時リクエスト数の考慮点

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

同時リクエスト数の改善策

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

ユーザーアクセスによる同時リクエスト数の改善策

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

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

REST API による同時リクエスト数の改善策

実行時間の見直し

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

中間処理結果の保存

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

差分処理

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

キャッシュ化

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

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

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

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

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

おわりに

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

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

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

このTipsは、2022年9月版で確認したものになります。

記事に関するフィードバック

記事のコメント欄は記事に対するフィードバックをする場となっております。
右の記事フィードバックのためのガイドを参照してコメントしてください。
記事のリンク切れなど、気になる点がある場合も、こちらのフォームからフィードバックいただけますと幸いです。

サインインしてコメントを残してください。