« 2008年9月 | トップページ | 2008年11月 »

2008年10月25日 (土)

最近の画面解像度

サイトを作るときにはユーザービリティーを考えないといけない。

そう、本にも書いてあるし、その筋の人たちは口を酸っぱくして言う。

では、サイトの横幅はどういう設定がよいのか?

ものの本には、ユーザービリティを考慮して、可変長に表示できる画面が良いとか

800ピクセルにしておけば問題ないとか、いやいや、最近では960ピクセルでも良いとか。

ほんまかいな。

ということで。私が管理している某サイトのログを解析してみた。
月間30万ビュー程度のサイトだ。

1280x800      26.55%    
1024x768      23.08%    
1280x1024     13.15%    
1680x1050     10.17%    
1440x900     9.18%    
1920x1200    3.47%    
320x396      2.73%    
1152x870     1.74%    
1280x768     0.99%    
1280x960     0.99%

なんという結果だろう。

横幅が800なんていうのはない。

みんなワイド画面か、それとも携帯だ。

しかし、このサイトだけは上記の解像度を参考にして製作しないといけないのは間違いがない。

それにしても、昔(数年前)の常識が通用しない時代になってしまったのだけは確かだ。

2008年10月 7日 (火)

MySQL4のストレージエンジン

なにかと利用しているMySQL。
重要なストレージエンジンについてメモ。

[1] MyISAM

    デフォルトのストレージエンジン。IBMが開発したISAMモデルの拡張版。
  MyISAMのテーブルは3つの異なったファイルで構成されている。
  ・ frmファイル:テーブルの定義が格納
  ・ MYDファイル:未加工のデータが格納
    ・ MYIファイル:インデックスが格納

 ●特徴
  読み込みが非常に速く、書き込みも非常に速い。
  しかし、読み書きを同時にはできない。
  テーブルレベルのロッキングを使用。
  書き込みの並列性の最高レベルは低い。
  トランザクションはサポートしない。
 ●有用な機能
  FULLTEXTというインデックス型が利用できる。

[2] InnoDB
 トランザクションをサポート。ACID準拠(アシッドと呼ぶ)。
  ACIDとは以下の略。
   ・Atomicity(原子性):処理を全て実行するか全く実行しない状態に制御する
  ・Consistency(一貫性):異常時にもアトミック実行を保証し正しい状態を維持する
  ・Isolation(独立性):他のトランザクションの処理中の状態が参照できないよう分離する
  ・Durability(永続性):成功したトランザクションの結果だけが永久化される

  ●特徴
  ロックが、MVCC(Multi-Versioned Concurrency Control マルチバージョン並行処理制)により実行されるため、読み込みをまったくブロックすることなく行レベルのロッキングを素早く行うことができる。つまり、テーブルに書き込みが行われている間でも、そのテーブルからの読み込みを続けることができる。(並列性
また、テーブルの複数の部分に書き込みを行ってもお互いにブロックしあうことがない。
 InnoDBのテーブルの行データはディスク上で基本キーによって順序付けされているので、データをはるかに高速に基本キーの順序で連続して読み出せる。

 ●弱点
  MyISAMに比較して、スペースが3倍ほどになる。FULLTEXTインデックスが使えない。

[3] ヒープ
   別名メモリテーブル型。データをすべてメモリに保存。サーバを再起動するとヒープテーブルは空になる。スキーマ(定義)はディスクに保存される。

 ●特徴
  書き込みが高速であるため、並列性が高く、非常に高速。
  リアルタイムのイベントの待機など処理時間に厳しい制約がかかるデータに適している。

 ●弱点
  再起動の際にデータが失われてもかまわないという条件がつく。
  データベースのサイズはメモリに収まるものでないといけない。

2008年10月 4日 (土)

Xdebugを使ってみた

どうしてもレスポンスを出したい。
いろいろチューニングしてみたが、どこがボトルネックなのかよくわからん。

よし。ということで、Xdebug(http://xdebug.org/)をインストールしてみることに。

XdebugというのはWEBサーバのapacheの元で動くパフォーマンスモニターである。

インストールしたあとに、php.iniに次のように設定する。

        ;プロファイリングを有効に
        xdebug.profiler_enable = 1
       ;プロファイリング結果の出力ディレクトリ
        xdebug.profiler_output_dir = "/path/to/output/directory

出力ディレクトリは任意なものを指定する。
こうしておいて、WEBサーバを再起動する。
そうすれば、そのサーバで動作するスクリプトのパフォーマンスが逐一モニターされる。

結果は、出力フォルダから取り出して分析する。

ただし、テキストなのでちょっと見にくい。
Windowsに慣れてしまっているのでできればGUI環境で見られたらよいのだが。

と、いろいろ探したら、WinCacheGrind( http://wincachegrind.sourceforge.net/)というのを
見つけた。
ローカルのWindowsマシンにインストールして、上記の出力結果を開くと、エクスプローラーのような表示で、各ステータスを見ることができる。

これはいい。

でも、おそらくデータベースのI/Oでほとんどのレスポンスを喰ってるんだろうな。

しかし、ボトルネックを知っておくのは大切。

地道な作業を始めよう。

« 2008年9月 | トップページ | 2008年11月 »