永田順伸のブログ

年末、osCommerceを使用しているお客様からメールが届いた。
内容はよくあるスパムメールだった。 まるでお客様が管理している
osCommerceからスパムメールが送信されたようだった。
そのときは、念のため注意喚起のメールを送信した。原因がわからないため、
管理側のIDやパスワードを変更してもらった。
さらに別のお客様のosCommerceからもスパムメールが届いた。
こちらにも注意喚起のメールを送付しておいた。

年が明けて風邪をひいた重たい頭でメールを確認していたところ、
先のお客様のosCommerceからさらに複数のメールが届き始めた。
間違いなくお客様のosCommerceを利用して大量にスパムメールが送信されている。
風邪で起きていられないのでLet’snoteを布団の中で手に持って検索してみると、
英語版のosCommerceのあるバージョンだけにバグがあり、そこから登録会員宛に
スパムメールを大量に送信していたことがわかった。
日本語版を使用している場合は問題ないことがわかりひと安心。

先ほども、はじめての方（海外）から相談のメールが届いた。
被害は世界中に広がっているようだ。

ASPIRE5720G は、購入したときより調子よく動作するようになった。
レジストリが壊れて動作が不良になるので、調子が悪くなったら、良かったところまで戻すことで、調子を維持できるようになった。こまめに不要なファイルをCCleanerを使ってきれいにして、ハードディスク内部をデフラグで整理して使っていた。

ところが 、最近、動画を見ると妙に熱くなるようになった。触れないくらい熱い。
そうなると、いきなりシステムがダウンして、再起動、さらにダウンして再起動を繰り返す。
Windowsを起動するまえに再起動するのできっと熱が原因だということはわかるが、
どうすればいいのかわからず、不自由しながら使っていた。

動画を連続して見ていると30分程度でダウンしてしまう。
CPUのあたりが触れないくらいに熱くなっている。
CPUファンがダメになったのかもしれない。交換は面倒だし、新しいものを購入することもできないので、  きょうは、裏蓋を開けて確認してみた。
すぐに目に付いたのが、CPUファンの汚れ。
ほこりで白っぽいのでエアダスターで吹き飛ばした。
ファンがエアダスターの風を受けて回転し始めるとさらにほこりが飛び出してくる。
ファンからほこりが出なくなったら、熱を逃がす排気口に向かって風をぶつけると、一瞬だが、まるで小麦粉に息を吹きかけたようにほこりが飛び出した。これを2回繰り返すと、まったくほこりがでなくなった。そこでフタを元に戻して、電源を入れてみた。

なんと、まったく熱くならない。

試しに動画をいくつか同時に見てみてもまったく熱が気にならなくなった。

osCommerceの商品部分のなかでオプションは特に面倒な部分だ。
そのお客様の使用しているバージョンでは、項目選択肢を使うと在庫数のチェックが正確にできなかった。ソースを確認すると項目選択肢はまったく考慮されていないようだった。項目選択肢を有効にすると商品型番に{nd:数字}が、在庫選択肢を有効にすると{md:数字}のような文字列が追加される。在庫選択肢は、この文字列を考慮した仕組みがはじめから実装されていたが、項目選択肢を考慮した機能はなかった。

{nd:数字}と{md:数字}が付いている場合
{nd:数字}が付いている場合
商品型番のみまたは商品型番に{md:数字}が付いている場合

のように３パターンにして、文字列から商品型番を抜き出して、同じ商品の場合は数量を加算することで、うまく在庫を確認することができた。

これでうまく動作すると思ったが、注文側で、商品番号が勝手に変わっていることがわかった。osCommerceのオプションは本当に面倒だ。

私の仕事ではほとんどメールのやりとりのみで作業が完了する。
先日、ひさしぶりに顧客のひとりから電話がかかってきた。こういうときは、緊急の依頼が多い。話を聞いてみると、やはり、そうだった。ある理由で管理画面に入れなくなったという。いつもお世話になっているお客様なので休日だったがすぐに仕事にとりかかった。
いくつか方法を検討して、管理者用のIDとパスワードを登録するプログラムを作って、数時間後無事解決した。

今回の作業は簡単な方だった。別のお客様だが、コンテンツを全部削除してしまい、何とかして欲しいといわれたことがある。このときは、データベースとトップページののデザイン画面が残っていたので、画像を切り出してトップページを作り、残ったデータベースの内容からosCommerceのバージョンを推測して翌日にはすべて復旧した。
コンテンツの消失は、Zen Cartでも一度あり、このときもバラバラに保存されていたデータをかき集め、もとどおりにした。
緊急の案件は大変だけど、お客様に喜んでいただけるのでやりがいがある。

お困りのことがあればinfo@ynagata.com宛ご連絡ください。
ただし、緊急の作業は高くなりますので、
日頃から、ファイルやデータをバックアップしておくと安心です。

データベースを調整すると驚くほど処理が速くなるが、ページキャッシュを適切に設定するとさらに速くなる。

ページキャッシュは、カテゴリメニューなどに使用され、データベースの負荷を下げる機能がある。たとえば、トップページのカテゴリメニューは画面が表示されるたびにデータベースから値を取得して、PHPで整形してHTMLとして正しい形式にして出力される。

他のページを見て、再度、トップページを表示させても同じ処理が実行される。この部分だけでもアクセスが多いサイトだと負荷がかかる。このカテゴリメニューの部分だけをはじめの処理のときにファイルに保存して、2度目にこのページを表示するときはデータベース処理やPHPでの整形処理は省いてファイルから直接読み出して、処理を速くする機能がページキャッシュだ。

osCommerceでは、ページ全体をキャッシュせず、負荷が予想される部分にキャッシュ機能が適用されている。
設定するには、基本設定の「ページキャッシュ」画面を表示させて、「キャッシュを使用」を「true」にする。
注意が必要なのが「キャッシュ・ディレクトリ」に設定するパスだ。

お客様から依頼を受けて調べてみるとまったくページキャッシュが使用されていないことが多い。動作しない理由の大半がパスが適切ではないためだ。この部分が適切に設定されていないとページキャッシュは動作しない。
ここにはページキャッシュ用のファイルを格納するディレクトリ名を設定する。Webから見たパスではなくて、OSのファイルシステムから見たフルパスを設定する。設定したパスはプログラム側から書き込めるように書き込み権限を追加しておく。
正常に動作すると、ブラウザでページを閲覧することで、キャッシュ用ファイルがディレクトリ内に作成されていく。ファイルが生成されていれば設定は成功だ。

これから先は、PHPのプログラミングがわからないと難しいが、トップページの状況に応じてページキャッシュの範囲を広げるとさらに効果的だ。
osCommerceには、処理時間を計測する機能があるので、これでページごとの処理時間がわかる。

最近の私の経験では、トップページの表示に2秒かかっていたがインデックスの追加で0.241秒になり、ページキャッシュを拡張して対応することで、0.063秒になった。