kintone(キントーン)の性能の改善
こんにちは。kintone(キントーン)導入支援のギャンです。
今回は「kintone(キントーン)の性能の改善」というテーマでお送りいたします。
kintoneは、たくさんの企業や自治体において、日常的に利用されており、一般的な業務において性能が問題になることはありません。しかし、大量のデータを扱ったり、同時にたくさんの処理が集中するような使い方の場合、「表示が遅い」、「時間がかかる」などkintoneの性能が問題となる可能性があります。
目次
kintoneの性能とは
クラウドサービスにおける性能は、一般的に「同時リクエスト数」と「リクエストの処理時間」の掛け合わせの影響を受けます。kintoneにおいても同様に「同時リクエスト数」と「リクエストの処理時間」によって性能に影響を受けますので、「同時リクエスト数を減らす」、「リクエストの処理時間を短くする」ことが理想となります。
同時リクエスト数とは
「同時リクエスト数」は、ユーザーアクセスによるリクエスト数と、カスタマイズによる REST API リクエスト数の合計です。ユーザーアクセスによるリクエスト数は、アクセスするページやカスタマイズの状況によって変わりますが、kintoneを同時に利用する人数と読み替えてください。性能への影響を抑えるために、カスタマイズによる REST API リクエストには制限を設けています。
同時リクエスト数の制限
1 つのドメインにつき 100 件まで同時実行が許可されており、101 件目以降のリクエストはエラーになります。制限値を超過した場合、原因となったアプリだけではなく、ドメイン全体で REST API のリクエストがエラーとなるため、注意が必要です。
同時リクエスト数の改善策
アクセスが始業/終業時など一定の時間に偏る場合、同時リクエスト数が増えます。REST API によるリクエストが大量に送信されるシステム・カスタマイズを構築されている場合も同様に同時リクエスト数が増えます。同じアプリや同じレコードにリクエストが集中する場合は、特に注意が必要です。同時リクエスト数を減らせるかどうかは要件や運用に依存します。ここでは同時リクエスト数を減らすアイデアを紹介します。
- お知らせのアプリは必要最低限にする
ポータルやスペースのお知らせにアプリを貼り付けている場合、アクセス時にアプリへのリクエストが発生しますので、不要なアプリがないか検討します。 - 実行時間の見直し
業務時間中に実行する必要のない処理は業務時間外や夜間など、利用者の少ない時間帯に実行します。 - 中間処理結果の保存
大量データを集計、加工して表示するような場合は中間結果を別の kintone アプリに保存します。これにより REST API による総リクエスト数を減らせないか検討します。 - 差分処理
定期的に処理する場合は毎回全レコードを対象にするのではなく、前回実行分との差分のみを処理します。たとえばレコード取得を「更新日時が前回の実行日時以降」という条件で実行します。 - キャッシュ化
同じユーザーが何度もアクセスする場合はデータをセッションストレージなどに保存します。2 回目以降のアクセス時はセッションストレージのデータを参照します。 - アクセス時にリクエストしない
画面表示時に REST API を実行する場合はボタンクリックなどの操作を挟み、意識的にデータを見たい場合のみ REST API を実行します。
リクエストの処理時間とは
「リクエストの処理時間」は 1 件ずつのリクエストの処理に要する時間で、よくあるケースとして次の要因によって処理時間が変動します。
- レコード件数
- 絞り込み・ソート条件
- アプリ構成(フィールド、アクセス権など)
「同時リクエスト数」と「リクエストの処理時間」はお互いに影響し合います。同時リクエスト数が増えると kintone への負荷がかかる傾向があります。その結果、リクエストの処理時間も長くなる可能性が高くなります。
リクエストの処理時間の改善策
レコード件数が多くなるにつれ、リクエストの処理時間が長くなります。利用者の快適さを考慮すると、レコード件数は多くても 100 万レコードが目安となります。絞り込み・ソート条件やアプリ構成によっては数万レコードでも性能に影響が出る場合もあります。ここではリクエストの処理時間を短くするアイデアを紹介します。
レコード件数
不要なレコードを削除できないか、利用頻度の低いレコードを CSV に書き出して保管できないか検討してください。また、アプリの分割も有効です。分割方法の案を 2 つ紹介します。
- 時系列で分割
年ごと、もしくは複数年ごとにアプリを分ける。 - 所属で分割
利用者の所属でアプリを分ける。
絞り込み・ソート条件
不要な絞り込み・ソート条件がないか確認してください。初期表示される一覧はアクセスされる頻度が高くなりますので、絞り込み・ソート条件の設定数が少ない一覧で代用できないか検討してください。ソート条件はフィールドタイプによって処理時間が変わりますので、処理時間が短いフィールドタイプに変更できないか検討してください。特に処理時間が長いのは、ラジオボタンとドロップダウンですので、他のフィールドタイプへ変更できる場合は偏向してください。詳しくは「ソート条件に適用するフィールドの種類による処理時間の違い」を参照下さい。また、取得するフィールドを少なくすれば API の実行時間を短縮できますので、必要なフィールドのみを取得刷るようにして下さい。詳しくは「取得するフィールドを指定することで、kintone のレコード一括取得の時間を短縮する」を参照して下さい。
アプリ構成
不要なフィールドを削除できないか検討してください。また、アクセス権の設定数を減らせないか検討してください。アクセス権の設定数については、ユーザー単位の設定ではなく、組織やグループごとの設定にできないかを検討して下さい。詳しくは「kintone SIGNPOST 最軽量のアクセス権設定」を参照下さい。
kintoneの性能の改善のまとめ
今回、kintoneの性能の改善というテーマで、kintoneの性能に影響を与える「同時リクエスト数」と「リクエストの処理時間」について、改善策をまとめてみました。また、直接的ではありませんが、kintoneを利用するインターネット環境や、kintoneを動かすPCやモバイル端末などの性能もkintoneを快適に利用するためには影響がありますので、改善できる点はないかを確認してただければと思います。また、プラグインや連携サービスを利用している場合、プラグインや連携サービスが影響を与えている可能性もありますので、注意が必要です。同様にJavaScriptカスタマイズを行っている場合も注意が必要です。以上、参考になれば幸いです。