質問編集履歴
5
誤字
title
CHANGED
@@ -1,1 +1,1 @@
|
|
1
|
-
|
1
|
+
Djangoでページング機能を実装したリストの表示スピードを上げたい
|
body
CHANGED
File without changes
|
4
ごじ
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
誤字
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
誤字
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
追記、誤字
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項目)だけではなく全項目読み込んでおり、
|
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)
|