cybozu developer network

カテゴリー内の他の記事

kintoneのテーブルの行数とレコード一覧・詳細画面の描画時間との関係

(著者:サイボウズ 性能検証担当)

Index

はじめに

kintone のアプリで利用できる「テーブル」フィールド(以下、テーブル)は、
「表」形式でのデータの管理を可能にする便利な機能です。

テーブル内に複数のフィールドを保持することができ、必要に応じて入力行を増やすことができるので、
予め入力するデータの行数が決まっていない場合などにご活用いただけます。

そんな便利なテーブルですが、必要に応じて入力行を増やせるため、1レコードあたりのデータ量が大きくなりやすいです。

1レコードあたりのデータ量が大きくなると、レコードが表示されるまでの時間が長くなるなど、利用者に影響が出てしまいます。

そこで、本記事ではテーブルの行数を増加させることで、
レコード一覧画面(以下、一覧画面)とレコード詳細画面(以下、詳細画面)の描画時間にどのような影響があるのかを検証しました。

検証を実施するにあたって

テーブルの行数を増加させることで一覧画面と詳細画面が表示されるまでの時間にどれくらい影響があるかを確認するため、
以下の条件で検証を行いました。

検証環境

  • 2021年 4月版
  • cybozu.com 検証環境

検証端末

  • CPU : Intel(R) Core(TM) i5-7300U CPU @ 2.60 GHz 2.71 GHz
  • メモリ : 8.00 GB
  • OS : Windows 10 Pro バージョン 20H2
  • ブラウザ : Google Chrome (91.0.4472.77)

検証条件

次の条件で、テーブルの行数ごとにアプリを4つ新規作成しました。

  •  対応履歴アプリ
    • テーブルの行数 : 10行、50行、100行、1,000行
    • レコード数 : 100,000件で統一
    • アクセス権の設定 : なし
    • 一覧画面の絞り込み条件:なし(すべてのレコード)
    • 一覧画面の表示項目:レコード番号、文字列(1行)
    • 一覧画面の表示件数:20件

アプリのフォームの配置は以下の画像の通りです。

「会社名」フィールド(文字列1行フィールド)と、「テーブル」フィールド(日付、文字列1行、数値フィールドを内包)で構成されます。

アプリの詳細画面の画像です。文字列(1行)フィールドと、その下にテーブルフィールドが配置されています。

検証内容

対応履歴アプリの一覧画面と詳細画面の画面表示にかかった時間を計測する

「一覧画面の画面表示」とは

以下の1枚目の画像のようにポータル画面から該当するアプリをクリックし、2枚目の画像のように一覧画面が開いてレコードが表示されるまで、
と本記事では定義します。

「詳細画面の画面表示」とは

以下の1枚目の画像のように一覧画面から任意のレコードを選んで左端のアイコンをクリックし、2枚目の画像のように詳細画面でテーブルの末尾が表示されるまで、
と本記事では定義します。

計測方法

次の手順1~5を3回実行し、その平均値を計測結果とします。

  1. Google Chrome の Developer Tools を開き、Performance パネルの計測開始ボタンを押す
  2. ポータル画面から該当のアプリをクリックして開く(一覧画面の描画時間を記録)
  3. 一覧画面から任意のレコードをクリックして開く(詳細画面の描画時間を記録)
  4. Performance パネルの計測停止ボタンを押す
  5. 記録された内容から以下の項目を抽出し、差分の時間を描画時間とする
    • 開始 : 上記手順2と手順3のタイミングに記録された「Event: click」
    • 終了 : 画面の読み込みが終わったタイミングをスクリーンショットから判断し、その付近にある「Composite Layers
  •  

 

 

下の画像は、詳細画面の計測開始のタイミングを取得する方法を示した画像です。

start_timing.png

下の画像は、詳細画面の計測終了のタイミングを取得する方法を示した画像です。

stop_timing.png

 

計測結果

一覧画面の計測結果は以下のグラフの通りです。

result_view.png

テーブルの行数増加に従って、一覧画面の描画時間が増加していることがわかります。

今回の検証では一覧画面にテーブルを表示していませんでしたが、そのような場合でも、
テーブルの行数増加によって一覧画面の描画に少し影響が出ることがわかりました。

 

続いて、詳細画面の計測結果は以下のグラフの通りです。

result_show.png

詳細画面も一覧画面と同じく、テーブルの行数が増加すればするほど描画時間も増加しています。

しかし、詳細画面は一覧画面と比較して、テーブルの行数増に伴う描画時間の増加幅が大きいことがわかります。
詳細画面では、テーブル行数が1000行の時、描画に約20秒もかかる結果となりました。

詳細画面ではテーブル行をすべて描画する挙動になっているため、一覧画面よりも描画時間に対するテーブル行数増の影響を強く受けると考えられます。

まとめ

今回はテーブルの行数が異なるアプリを用意し、それぞれ一覧画面、詳細画面の描画時間を計測しました。

テーブルの行数を増加させることで、一覧画面と詳細画面の描画時間に影響があること、
特に詳細画面の描画時間への影響は、一覧画面の描画時間への影響よりも大きいことがわかっていただけたかと思います。

傾向を掴むための検証なので、テーブルに入力するデータ量は実運用と比べて少ないですが、
テーブルの行数を増やせば増やすほど、レコードの描画時間に影響がある
ということを数値で確認できました。
アプリの構成によっては、数百行でもレコードの処理に影響します。

現在テーブルをご活用いただいている環境でレコードの描画時間が遅いと感じている方は、
1レコード当たりのテーブルの行数が多すぎないかご確認いただき、必要に応じて運用方法の見直しを行っていただけると幸いです。

なお、本検証はお客様環境とは異なる検証環境を利用したものであることにご注意ください。

 

この検証は、2021年4月版 kintoneで実施したものになります。

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

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

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