売れてないのは検索速度だけなのか？

3月にリニューアルして、商品の動きが悪いです。

検索速度の低下が一番の原因かと思われ。

リニューアル前はユーザビリティの向上を主体として開発してて、まさかオープンしてこんなに検索速度が下がるとは夢にも思ってなかった。

やっぱユーザが入ってくると予期せぬことが起こりますわ。

慌てて、リニューアル後、開発のコタと1ヶ月ばかりいろいろチューニングしてます。。。

apacheの設定もGIGAZINEのチューニング
GIGAZINEのLoadAverageを「27」から「2」へ下げた方法
を参考にやれる ことはやった。

PHP関連も
ZendOptimizer、eAcceralator
を採用してオーバーヘッドも小さくした。

DBも最速、最速のPostgreSQL8.3を導入して全文検索にLudia１.5もインストール。

SQLチューニングも今週末、コタの頑張りでLoadAverageがだいぶ小さくはなってきてます。
検索速度としては、リニューアル前に近づきつつありますが、なんだろうこの不安は。

使い慣れたサイトがごろっと変わるのは、利便性が向上したとか、しないとか言う前に使い方の習得に時間がかかるものなのかも。

DosTigresの小山さんも「リニューアルは3ヶ月は売上安定しないよー」とおっしゃられてたようにお客さんが慣れるまでは売上は戻ってこないのかもしれません。

お客さんにリニューアルについてのアンケートを回答してもらっても、（リニューアルして）良かった点と悪かった点が同じ項目が上がってきたりしてるとこもあるし。

たとえば検索結果一覧は前までは100件表示だったのを10件にしたところなど。
一人のお客さんはこれが使いやすいと回答してくれたけど、一人のお客さんは一気に見れるほうがいいとの意見。

五味とも話しをしてるんだけど、ユーザでサイトの使い勝手をカスタマイズできるようにすれば一番いいんだろうなあと話てる。

大掛かりなものは後回しになるけど、ちょっとしたアイデアで（ユーザがカスタマイズ）可能なところは見つけていきたいとおもとります。

ま、とにかく検索速度NO1を目指してチューニングしていきます。
次はDBの切り分けにトライっす。

Comments

[投稿情報: yokoyam]

DBのチューニング
というか、当初の設計の問題でもありますが、
ノウハウも必要だし、読みも必要。
コタさんの力量ももちろん問われますが、
どちらかというと、
クライアント様の割り切りも不可欠です。

便利な仕様はDBが冗漫になりがちです。
どうしたら便利とスピーディなDB設計の兼ね合いが実現できるか、
コタさんも適切に割り切り、
仕様切り落としも厳しくアドバイスするべきでしょう。
（ちゃんとやっておられたらゴメンナサイ＞コタさん）

クライアント様というものは、とにかく「便利に！」「高度に！」を望まれますが、それがDB全体のバランス的に見て不適切・頭でっかちになることが
よく起こります。
しゃちょうはシステムがものすごくよくわかってるし・欲張り（笑）なので、コタさんの苦労が目に浮かびます。

システムを全部入れ替える場合、本質的な改良だけリリースし、徐々に仕様をアップしていく方法論がもっともリスクが少なくなります。
いきなりドカンと何もかも変える場合、ヘタすると「影響3ヶ月」では済まなくなる可能性が高いです。

DBを叩くWebサイトでは、1つのセッションの未処理が次々に連鎖され、全てのセッションを処理できないボトルネックが生じます。
基本的にその解消方法は、狭窄がどこかを突き詰めていくと同時に水道管のパイプを太くするしかないです。
そのへん気がつくのは、走り始めてからでは遅いし、重々伝えてもイメージわかないクライアント様がほとんどです。

次回DB会議では、「アーカム：ぼく達の失敗」ネタで決まりですね。（笑）

[投稿情報: テツジ]

そうそう、カスタマイズ！
携帯もカスタマイズできたらええのに・・・
いらん機能は多いし、欲しい機能はしょぼなるし　ってなるよね。

[投稿情報: ひであき]

＞システムを全部入れ替える場合、本質的な改良だけリリースし、徐々に仕様をアップしていく方法論がもっともリスクが少なくなります。
いきなりドカンと何もかも変える場合、ヘタすると「影響3ヶ月」では済まなくなる可能性が高いです。

厳しいお言葉です。。。

お客様からのアンケートを元にカイゼンしていってます！
チューニングも今月中にはメドが立つ予定。

１ユーザとして、ご意見ください！

[投稿情報: ひであき]

＞いらん機能は多いし、欲しい機能はしょぼなるし

なにをユーザが欲してるのかってやっぱ聞かんとわからんよね。