2009/4/25

「ちゃんとやるだけ」大規模ECサイト(その4)


さて前回から、ぼちぼち「具体的な対策」について触れていますが、
個々の内容については大して難しいコトはやってないです。

ただ、中には前回の「【2】「CSV1行単位でbegin,comit」の是非」のような、
実装に際して「トレードオフ」の一面を持つ対策も結構あったりします。
例えば―――



———————————————–
【1】CSV商品登録など

「CSV1行単位でbegin,comit」しているものを、
「ループ前後で1回きり」とした場合。

登録速度はかなり早くなるが、途中で何かあった場合。
前者は「成功した場所から」(「どこまでやったか」が判ればですが)
後者は「最初からやり直し」
———————————————–
【2】メールマガジン配信時

「1通毎にdtb_send_historyに成功の可否を記録」をオミット。

配信速度はかなり速くなるが、途中で何かあって止まった場合。
前者は「どこまで配信処理を行なったかが判る」
後者は他にどこかに記録しない限りはサーバ上のmaillogを見ないと判らない。

※ただし前者でも「送信処理を行なったかどうか」までしか判らない。
 「本当に送信処理に成功したか」については結局maillogを確認する必要がある。
———————————————–
【3】ランキング表示

ランキング表示の際、
「定期的に更新されるサマリーデータファイル」を読み込むようにし、
表示の度に集計を行なわないようにする。

表示内容にリアルタイム性がなくなるがDBアクセス回数減。
特に「共通して表示されるブロック」など表示頻度が高い部分ほど効果大。
———————————————–
【4】メーカー名,出演者名,ジャンル一覧

一覧表示の際「定期的に更新される一覧データファイル」を読み込むようにし、
表示の度に集計を行なわないようにする。

上記【3】同様、表示内容にリアルタイム性がなくなるがDBアクセス回数減。
特に「共通して表示されるブロック」など表示頻度が高い部分ほど効果大。
———————————————–

などなど。
まぁ、まさに「塵も積もればなんとやら」です。

ただ、これらは実装するに際して、お客様の要望,意図するところ異なる場合もあり、
「処理が速くなるから」と言って勝手に実装すると、後々もめたりするケースも考えられます。

こういう時こそ、お客様に「ちゃんと」メリット,デメリットを説明し、
意識のズレが生じないよう「ちゃんと」コミュニケーションをとることが大切です。

今回の大規模案件を手掛ける中で技術的なことだけでなく―――

 お客様に「共にサイト,システムを創りあげる」という意識を持ってもらえると
 「色々と動きやすくなる」

ということを、改めて再認識させてもらったという点も、
自分としては収穫だったと思っています。

ただ上記の「塵」が積もっただけでも、
まだ「普通のレスポンス」とは結構隔たりがありました。
その辺りにつきましては後程。。。


運営者

  • 株式会社エスキュービズム
  • 〒105-0011 東京都港区芝公園2-4-1芝パークビル A館 4階
  • TEL : 03-6430-6730(代表)
  • HP:https://s-cubism.jp/