teratail header banner
teratail header banner
質問するログイン新規登録

質問編集履歴

5

誤字

2020/11/24 08:49

投稿

kwmr8416
kwmr8416

スコア6

title CHANGED
@@ -1,1 +1,1 @@
1
- djangoでページング機能を実装した一覧表示の表示スピードを上げたい
1
+ Djangoでページング機能を実装したリストの表示スピードを上げたい
body CHANGED
File without changes

4

ごじ

2020/11/24 08:49

投稿

kwmr8416
kwmr8416

スコア6

title CHANGED
File without changes
body CHANGED
@@ -2,7 +2,7 @@
2
2
  表題の通り、一覧表示の表示スピードを上げる必要があり、どのような対応をしたらいいのか検討がつかない状況にあります。
3
3
  これまでにAWSで1GB(ローカルでは100MB)のCSVファイルをインポートし一覧表示させました。
4
4
  この一覧表示はページングで7項目のレコード20件を1ページとして表示させていますが、
5
- 以下のように、
5
+ 以下のように、ブラウザで表示されるまでの時間として
6
6
  ```
7
7
   t2.micro→50秒
8
8
   t2.xlarge→25秒
@@ -17,7 +17,7 @@
17
17
  ```
18
18
  これは、最初のSELECT文のCOUNTメソッドでレコード件数を取得し、次のSELECT文で当該レコード20件分を読み込んでいます。ここでは表示項目(7項目)だけではなく全項目読み込んでおり、models.pyで記述したソートが実行されています。
19
19
 
20
- ローカルでCSVファイルの読み込みが100MBまでしかできておらず環境別で比較できない状況ではありますが、1GBのデータが入ったAWS上のデータベースに上記の2つのSQL文を直接実行し結果が返ってくるまでの時間を計測ました。
20
+ ローカルでCSVファイルの読み込みが100MBまでしかできておらず環境別で比較できない状況ではありますが、1GBのデータが入ったAWS上のデータベースに上記の2つのSQL文を直接実行し結果が返ってくるまでの時間を計測ました。
21
21
  ```
22
22
  t2.micro→
23
23
  SELECT COUNT(*) AS "__count" FROM 対象テーブル ~:17秒

3

誤字

2020/11/24 07:33

投稿

kwmr8416
kwmr8416

スコア6

title CHANGED
File without changes
body CHANGED
@@ -20,10 +20,10 @@
20
20
  ローカルでCSVファイルの読み込みが100MBまでしかできておらず環境別で比較できない状況ではありますが、1GBのデータが入ったAWS上のデータベースに上記の2つのSQL文を直接実行し結果が返ってくるまでの時間を計測ました。
21
21
  ```
22
22
  t2.micro→
23
- SELECT COUNT(*) AS "__count" FROM ~:17秒
23
+ SELECT COUNT(*) AS "__count" FROM 対象テーブル ~:17秒
24
24
  SELECT 対象項目,.... FROM 対象テーブル ~: 17秒
25
25
  t2.xlarge→
26
- SELECT COUNT(*) AS "__count" FROM ~:8秒
26
+ SELECT COUNT(*) AS "__count" FROM 対象テーブル ~:8秒
27
27
  SELECT 対象項目,.... FROM 対象テーブル ~: 1秒
28
28
  ```
29
29
  この結果と冒頭の一覧表示(ブラウザで表示)にかかった時間を差し引くとSQLの実行処理とは別に15秒ほど他の処理に時間がかかっているということになります。

2

誤字

2020/11/24 07:28

投稿

kwmr8416
kwmr8416

スコア6

title CHANGED
File without changes
body CHANGED
@@ -3,8 +3,10 @@
3
3
  これまでにAWSで1GB(ローカルでは100MB)のCSVファイルをインポートし一覧表示させました。
4
4
  この一覧表示はページングで7項目のレコード20件を1ページとして表示させていますが、
5
5
  以下のように、
6
+ ```
6
7
   t2.micro→50秒
7
8
   t2.xlarge→25秒
9
+ ```
8
10
  と、スペックを上げると約半分になりましたが、かなり遅いです(時間は大体です以下同様)。
9
11
 
10
12
  調査した内容ですが、
@@ -16,13 +18,14 @@
16
18
  これは、最初のSELECT文のCOUNTメソッドでレコード件数を取得し、次のSELECT文で当該レコード20件分を読み込んでいます。ここでは表示項目(7項目)だけではなく全項目読み込んでおり、models.pyで記述したソートが実行されています。
17
19
 
18
20
  ローカルでCSVファイルの読み込みが100MBまでしかできておらず環境別で比較できない状況ではありますが、1GBのデータが入ったAWS上のデータベースに上記の2つのSQL文を直接実行し結果が返ってくるまでの時間を計測ました。
21
+ ```
19
22
  t2.micro→
20
23
  SELECT COUNT(*) AS "__count" FROM ~:17秒
21
24
  SELECT 対象項目,.... FROM 対象テーブル ~: 17秒
22
25
  t2.xlarge→
23
26
  SELECT COUNT(*) AS "__count" FROM ~:8秒
24
27
  SELECT 対象項目,.... FROM 対象テーブル ~: 1秒
25
-
28
+ ```
26
29
  この結果と冒頭の一覧表示(ブラウザで表示)にかかった時間を差し引くとSQLの実行処理とは別に15秒ほど他の処理に時間がかかっているということになります。
27
30
 
28
31
  このようにまだ調査しかしておらずこれからどのように対応したらいいのかがわかりません。何かヒントになることまたは見落としているポイントがあれば、教えてください。

1

追記、誤字

2020/11/24 06:54

投稿

kwmr8416
kwmr8416

スコア6

title CHANGED
File without changes
body CHANGED
@@ -13,7 +13,7 @@
13
13
  (0.063) SELECT COUNT(*) AS "__count" FROM "working_list_nippotable"; args=()
14
14
  (0.172) SELECT "working_list_nippotable"."id", "working_list_nippotable"."workday", "working_list_nippotable"."serialno", "working_list_nippotable"."productname", "working_list_nippotable"."productno", "working_list_nippotable"."workcontents", "working_list_nippotable"."worktypecd", "working_list_nippotable"."starttime", "working_list_nippotable"."endtime", "working_list_nippotable"."biko", "working_list_nippotable"."createday", "working_list_nippotable"."createname", "working_list_nippotable"."updatename", "working_list_nippotable"."draftflg", "working_list_nippotable"."updateflg", "working_list_nippotable"."approvalflg" FROM "working_list_nippotable" ORDER BY "working_list_nippotable"."workday" ASC, "working_list_nippotable"."starttime" ASC, "working_list_nippotable"."endtime" ASC, "working_list_nippotable"."updatename" ASC LIMIT 20 OFFSET 20; args=()
15
15
  ```
16
- これは、最初のSELECT文のCOUNTメソッドでレコード件数を取得し、次のSELECT文で当該レコード20件分を読み込んでいます。ここでは表示項目(7項目)だけではなく全項目読み込んでおり、model.pyで記述したorderinが実行されています。
16
+ これは、最初のSELECT文のCOUNTメソッドでレコード件数を取得し、次のSELECT文で当該レコード20件分を読み込んでいます。ここでは表示項目(7項目)だけではなく全項目読み込んでおり、models.pyで記述したソートが実行されています。
17
17
 
18
18
  ローカルでCSVファイルの読み込みが100MBまでしかできておらず環境別で比較できない状況ではありますが、1GBのデータが入ったAWS上のデータベースに上記の2つのSQL文を直接実行し結果が返ってくるまでの時間を計測ました。
19
19
  t2.micro→
@@ -81,6 +81,36 @@
81
81
  {% endif %}
82
82
  </div>
83
83
  ```
84
+ models.py
85
+ ```
86
+ from django.db import models
87
+
88
+ # 日報テーブル
89
+ class nippotable(models.Model):
90
+ #actcd = models.IntegerField('アカウントコード') /外部キー
91
+ workday = models.DateField('作業日')
92
+ serialno= models.CharField('製番(製造番号)', max_length=20)
93
+ productname = models.CharField('製品品名(仕事名)', max_length=50)
94
+ productno = models.CharField('製品NO.', max_length=3)
95
+ workcontents = models.CharField('工程(業務)名', max_length=50)
96
+ worktypecd = models.IntegerField('工程(業務種別)コード')
97
+ starttime = models.DateTimeField('開始時間')
98
+ endtime = models.DateTimeField('終了時間')
99
+ biko = models.CharField('備考', max_length=50)
100
+ createday = models.DateField('作成日')
101
+ createname = models.CharField('更新者', max_length=20)
102
+ updatename = models.CharField('作成者', max_length=20)
103
+ draftflg = models.BooleanField('下書きフラグ')
104
+ updateflg = models.BooleanField('更新フラグ')
105
+ approvalflg = models.BooleanField('承認フラグ')
106
+
107
+ class Meta:
108
+ ordering = ['workday', 'starttime', 'endtime', 'updatename']
109
+
110
+ def __str__(self):
111
+ return self.workday
112
+ ```
113
+
84
114
  ap:Django
85
115
  db:PostgreSQL
86
116
  web:Nginx(Gunicorn)