[WIP][DO NOT MERGE] Optimized application

[kazeburo]

ベンチマークのために最適化をやってみる

初期

2019/08/26 22:34:05 main.go:131: === final check ===
{
  "pass": true,
  "score": 15840,
  "messages": [
    "/new_items/30.jsonで返している商品の情報に誤りがあります"
  ]
}

• indexの追加。root_category_idの追加
• categoryをstaticに
• userをpreloadする
• userSimple、itemSimpleのときは、selectするものを絞る
• getTransactionsのstatusは全部なので、where条件から外す
• getTransactionsのクエリをunionクエリに書き換え + index
• 不必要なtransaction削除
• shippment serviceを呼び出さない
• postbuyでトランザクション開始前にできるチェックはする + get_lockでトランザクション滞留回避

[kazeburo]

indexの追加。root_category_idの追加

2019/08/26 22:35:19 main.go:131: === final check ===
{
  "pass": true,
  "score": 16240,
  "messages": []
}

[kazeburo]

categoryをstaticに

2019/08/26 23:00:51 main.go:131: === final check ===
{
  "pass": true,
  "score": 16140,
  "messages": [
    "/new_items/30.jsonで返している商品の情報に誤りがあります"
  ]
}

変わらない

[kazeburo]

userをpreloadする

2019/08/27 00:07:43 main.go:131: === final check ===
{
  "pass": true,
  "score": 16240,
  "messages": []
}

[kazeburo]

• userSimple、itemSimpleのときは、selectするものを絞る
• getTransactionsのstatusは全部なので、conditionから外せる
• unionクエリに書き換え + index
• 不必要なtransaction削除
• shippment serviceを呼び出さない

[kazeburo]

timeline、アクセスが多いようであれば、専用テーブルとか考えられるのかも
getuserは何もやってない。
getTransactions の N+1はもう少しできる。limitはもう少し多くするとつらくなるのかも
getTransactionsにもう少しアクセス増やしたい
shippingテーブル必要？みたいなところはある
postbuyとbumpが重なるとdead lockしやすくなるのでおもしろいかも

[kazeburo]

キャンペーン機能がくると、もう少しやらなければならなそう