トーク

ユーザー画像
2021/11/22 17:53

1行当たり30フィールドくらいあるテーブルがあるのですが、さらに各フィールドに関数などを設定しています。
編集画面で30行くらい追加していくと、かなり動作がもっさりしてきてなかなか使うに堪えない感じになるのですが、同様の方いらっしゃいますか・・?


この投稿を共有する
閉じる
URLをコピー URLをコピー
3件のコメント (新着順)
ユーザー画像
ユーザー画像
ほり(hori hiromi)
2021/11/24 21:53

1行に30フィールドもあるのであれば、私ならテーブル部分を別アプリにして、関連レコードで紐づける方法を取るかな~と思いました。
でも関連レコード読み込みもそこそこ時間かかるんだったら解決にはならないのかも?
テーブル内でテーブル外の項目を使った関数を使っているのであれば、別アプリにすること自体が無理なのかもしれませんね。

そうなると、描画や読み込み、処理のどこがネックになっているのかが肝ですね。
西村さんがアドバイスしているように、どこに時間がかかっているのか切り分けるのが良いかと思います。


ちなみに弊社にも
テーブル1行=
日付・ドロップダウン・複数行文字列・複数行文字列・数値
のテーブルがあるアプリがありますが、30行くらいから確かにもっさりしてきますね。

50行超えるとだいぶストレス感じるくらいになります。
ですが、このアプリは大抵10行以内に収まることが多く、もっさりするほど登録するのは稀なので我慢して使っています。
上記に書いたように別アプリにするのも考えてますが、大多数は運用上支障がないのでそのままです(;)


ユーザー画像
ユーザー画像
ジャッカル
2021/11/23 09:27

描写に関しては、PC依存のような気もしますね。
テーブルに関してではないですが、同じ様に、「なかなか表示されない」という事象が社内でも起きていました。
その方のPCは5~6年前のモバイルpcで、処理能力等が低スペックではありました。



ユーザー画像
ユーザー画像
まんじねこ
2021/11/24 09:32

どうも、サイボウズのサーバー側の処理が遅いためのように思うのですが。。


ユーザー画像
ユーザー画像
西村 志郎
2021/11/23 09:21

まんじねこさん

1行当たり30フィールドくらいあるテーブルがあるのですが、さらに各フィールドに関数などを設定しています。

えっと、「1レコードに、約30フィールドをもつテーブルがあり関数も設定している」ということであってますか?
ちがうかもしれませんが、以下テストしてみました。

テーブルにひとつの数値フィールドと30個の計算フィールドを使ったアプリを作成

計算フィールドの計算式(関数)は

計算01の計算式:数値+1
計算02の計算式:計算01+1
計算03の計算式:計算02+1
:
計算30の計算式:計算29+1

要するに最初の数値フィールドの値をおとなりの計算フィールドで順番に足していく感じです。
で、数値を1~30まで入力した30行のテーブルを作成したレコードを登録

結果
レコード登録後の表示にテーブル30行を描画する際、一呼吸ある感じ。
作業中の入力は特にストレスは感じない。

まんじねこさんのおっしゃる「もっさり」のタイミングがどのような状況なのか、どのような関数を利用されてるのか
もう少し具体的な情報があれば、またなにか協力できるかもしれません。^^



ユーザー画像
ユーザー画像
まんじねこ
2021/11/24 09:32

えっと、「1レコードに、約30フィールドをもつテーブルがあり関数も設定している」ということであってますか?

西村さん、ありがとうございます。ご認識の通りです。
正確には、関数ではなく以下のプラグインによる計算式を設定しています。
https://qiita.com/rex0220/items/ae83c6d5ce50ff7a9a73
テーブル以外にも、150フィールド程度あり、そのうちの30フィールド位に計算式を設定しています。


ユーザー画像
ユーザー画像
西村 志郎
2021/11/24 12:30

まんじねこさん

なるほど。プラグインなのですね。たしかにプラグインは汎用性を持たせるなどの理由でオーバーヘッド(主処理以外の処理)がかかる可能性はあります。ので純粋な関数利用よりは処理時間がかかるかもしれませんね。

しかしながら、テーブル以外にも150フィールド程度あるとの事ですので、プラグインを用いた関数が原因とも言い切れないなと思います(それもひとつの要素ではありますが)。

ジャッカルさんのおっしゃるように描画速度についてはクライアントPCの処理能力も一因として考えられます。

ただおそらくkintoneでは、1レコード内で150フィールド+30x30のテーブルを標準的な使い方としては考えていないからではないかと思います。特に描画のあたりは大量のフィールド表示を想定したつくりにはなっていないようですね。

私なら、まずアプリ自体のフィールドを減らせないか運用や仕様の見直しを検討します。
それがなかなか難しい場合は、落としどころを探るためにも、そもそものボトルネックはどこかを順番に詰めていきます。

関数(プラグイン)が原因と思うのであれば一旦すべての関数を外して改善されるかを確認します。すべて外しても速度に変化を感じなければプラグインが原因の可能性は低いですよね。

大量のフィールドもしくは30x30のテーブルが原因であると思うのであればフィールドなどを減らしていってどれくらいレスポンスが改善するのかを確認します。ちょっとづつ減らしていくと、どっかのタイミングで実運用に耐えうるスピードになるはず。

以上の作業を色々試して原因の大きなものを見つけたらそれについて対策を講じる感じですかね。ちょっと手間ですけど。^^;

例えばもしプラグインが原因であるのなら(あきらめるを含めて)その対策を考えるか、その処理が運用や仕様上必須であれば相応の処理をJSカスタマイズするかもしれません(JSカスタマイズしたら必ず早くなるというわけでもないですが^^;)。

またフィールドの個数が原因であればその代替案を考えるか、もしかしたら、一定条件におけるその両方の複合要因、またはそれ以外の要因があるかもしれませんので、そのあたりも含めてちょっとづつ調べるかなーという感じです。

う~ん^^;。まんじねこさんのアプリ自体を拝見しているわけではないですので、結局一般的な回答になってしまって恐縮ですが、なにかのヒントになれば幸いです。^^