「ちゃんとやるだけ」大規模ECサイト（その４）
さて前回から、ぼちぼち「具体的な対策」について触れていますが、
個々の内容については大して難しいコトはやってないです。
ただ、中には前回の「【２】「CSV１行単位でbegin,comit」の是非」のような、
実装に際して「トレードオフ」の一面を持つ対策も結構あったりします。
例えば―――
———————————————–
【１】CSV商品登録など
「CSV１行単位でbegin,comit」しているものを、
「ループ前後で１回きり」とした場合。
登録速度はかなり早くなるが、途中で何かあった場合。
前者は「成功した場所から」（「どこまでやったか」が判ればですが）
後者は「最初からやり直し」
———————————————–
【２】メールマガジン配信時
「１通毎にdtb_send_historyに成功の可否を記録」をオミット。
配信速度はかなり速くなるが、途中で何かあって止まった場合。
前者は「どこまで配信処理を行なったかが判る」
後者は他にどこかに記録しない限りはサーバ上のmaillogを見ないと判らない。
※ただし前者でも「送信処理を行なったかどうか」までしか判らない。
「本当に送信処理に成功したか」については結局maillogを確認する必要がある。
———————————————–
【３】ランキング表示
ランキング表示の際、
「定期的に更新されるサマリーデータファイル」を読み込むようにし、
表示の度に集計を行なわないようにする。
表示内容にリアルタイム性がなくなるがDBアクセス回数減。
特に「共通して表示されるブロック」など表示頻度が高い部分ほど効果大。
———————————————–
【４】メーカー名，出演者名，ジャンル一覧
一覧表示の際「定期的に更新される一覧データファイル」を読み込むようにし、
表示の度に集計を行なわないようにする。
上記【３】同様、表示内容にリアルタイム性がなくなるがDBアクセス回数減。
特に「共通して表示されるブロック」など表示頻度が高い部分ほど効果大。
———————————————–
などなど。
まぁ、まさに「塵も積もればなんとやら」です。
ただ、これらは実装するに際して、お客様の要望，意図するところ異なる場合もあり、
「処理が速くなるから」と言って勝手に実装すると、後々もめたりするケースも考えられます。
こういう時こそ、お客様に「ちゃんと」メリット，デメリットを説明し、
意識のズレが生じないよう「ちゃんと」コミュニケーションをとることが大切です。
今回の大規模案件を手掛ける中で技術的なことだけでなく―――
お客様に「共にサイト，システムを創りあげる」という意識を持ってもらえると
「色々と動きやすくなる」
ということを、改めて再認識させてもらったという点も、
自分としては収穫だったと思っています。
ただ上記の「塵」が積もっただけでも、
まだ「普通のレスポンス」とは結構隔たりがありました。
その辺りにつきましては後程。。。
個々の内容については大して難しいコトはやってないです。
ただ、中には前回の「【２】「CSV１行単位でbegin,comit」の是非」のような、
実装に際して「トレードオフ」の一面を持つ対策も結構あったりします。
例えば―――
———————————————–
【１】CSV商品登録など
「CSV１行単位でbegin,comit」しているものを、
「ループ前後で１回きり」とした場合。
登録速度はかなり早くなるが、途中で何かあった場合。
前者は「成功した場所から」（「どこまでやったか」が判ればですが）
後者は「最初からやり直し」
———————————————–
【２】メールマガジン配信時
「１通毎にdtb_send_historyに成功の可否を記録」をオミット。
配信速度はかなり速くなるが、途中で何かあって止まった場合。
前者は「どこまで配信処理を行なったかが判る」
後者は他にどこかに記録しない限りはサーバ上のmaillogを見ないと判らない。
※ただし前者でも「送信処理を行なったかどうか」までしか判らない。
「本当に送信処理に成功したか」については結局maillogを確認する必要がある。
———————————————–
【３】ランキング表示
ランキング表示の際、
「定期的に更新されるサマリーデータファイル」を読み込むようにし、
表示の度に集計を行なわないようにする。
表示内容にリアルタイム性がなくなるがDBアクセス回数減。
特に「共通して表示されるブロック」など表示頻度が高い部分ほど効果大。
———————————————–
【４】メーカー名，出演者名，ジャンル一覧
一覧表示の際「定期的に更新される一覧データファイル」を読み込むようにし、
表示の度に集計を行なわないようにする。
上記【３】同様、表示内容にリアルタイム性がなくなるがDBアクセス回数減。
特に「共通して表示されるブロック」など表示頻度が高い部分ほど効果大。
———————————————–
などなど。
まぁ、まさに「塵も積もればなんとやら」です。
ただ、これらは実装するに際して、お客様の要望，意図するところ異なる場合もあり、
「処理が速くなるから」と言って勝手に実装すると、後々もめたりするケースも考えられます。
こういう時こそ、お客様に「ちゃんと」メリット，デメリットを説明し、
意識のズレが生じないよう「ちゃんと」コミュニケーションをとることが大切です。
今回の大規模案件を手掛ける中で技術的なことだけでなく―――
お客様に「共にサイト，システムを創りあげる」という意識を持ってもらえると
「色々と動きやすくなる」
ということを、改めて再認識させてもらったという点も、
自分としては収穫だったと思っています。
ただ上記の「塵」が積もっただけでも、
まだ「普通のレスポンス」とは結構隔たりがありました。
その辺りにつきましては後程。。。
