komagataのブログ

スケーラブルWebサイト
オライリー・ジャパン(2006-12-26)
オライリー・ジャパン
(著)Cal Henderson
(翻訳)武舎広幸
(翻訳)福地太郎
(翻訳)武舎るみ
定価：￥ 3,570
新品価格：￥ 3,570
中古価格：￥ 2,825
ASIN：4873113113

Webサービスの開発プロセス全体についてまんべんなく書いてありました。それぞれのトピックスに関してはもっと濃い本を参照する必要があるけどプログラマでも別ジャンルだった人がWebを始めるときに読んだらかなり助かるんじゃないかなーと思いました。

特に、「早過ぎる最適化は悪」っていうのはホントに同意。パフォーマンスに問題が出たからつって、真っ先に、カーネルチューニングとかテーブル分割とかRAMディスクとか言い出すのは暇人か金持ち。（言い過ぎ）

実践ハイパフォーマンスMySQL
オライリージャパン(2004-10)
オライリージャパン
(著)ジェレミ・D. ザウドニ
(著)デレク・J. ベリング
(原著)Jeremy D. Zawodny
(原著)Derek J. Balling
(翻訳)林秀幸
定価：￥ 3,780
新品価格：￥ 3,780
中古価格：￥ 3,300
ASIN：4873112095

MySQLモデリングについてマルチカラムインデックスをちゃんと勉強しないといけないなあとおもったので（前に持ってたにもかかわらず）実践ハイパフォーマンスMySQLを注文しました。

1人（MAX３人）でWebサービスを作ることに焦点を合わせて考えると、パフォーマンスに関してもかなり効率的に（手っ取り早く）対処しないといけない。小～中規模Webアプリのボトルネックは圧倒的にDB、それもSQLとインデックスにかかってる気がする！（91%ぐらいの割合で）

それなのに、MySQLだとあんまり勘が利かないんですよね。ポスグレだと、EXPLAINの結果もインデックスの作用も大体予想通りだし、遅い部分があっても、「そうなるわな」って感じなのにMySQLだと「え？そこが？」みたいな。

別にポスグレで独自の難しい機能を使ってるとかじゃなくて、MySQLでは単に「１テーブル１インデックス問題」のせいじゃないんかと。もし勉強してみてマ（略）スをうまく使えば対応可能だったら安心だけど、そうじゃなかったら（非正規化が必要ということだったら）ポスグレ移行も考えたい。

Debian—Debian “etch” Release Information
Debian GNU/Linux 4.0 (a.k.a. etch) was released April 8th, 2007. The release included many major changes, described in our press release and the Release Notes.

To obtain and install Debian GNU/Linux 4.0, see the installation information page and the Installation Guide. To upgrade from an older Debian release, see the instructions in the Release Notes.

Debin etchが昨日リリースされたみたいです。

FirefoxがIceWeaselになったりThundrbirdがIceDoveになったりしてますが、この間デスクトップ環境を入れてみた感じはUbuntuじゃなくてもいいかもと思えるぐらい良さそうでした。

サーバー環境に関しては慣れの問題だとは思いますが、もう体が溶けるほど使い易しぃ・・・。ノンストレスです。依存症です。

それとDebian JP Projectのページが何か綺麗になっとる。Software Designに寄稿された武藤さんのインストールドキュメントなんかもあって非常に分かり易い。素晴らしい仕事！

最近衝撃を受けた小さいこと。

Photoshopとかのこういうシリアル入れる欄。

1034-2321-4323-6518-6985-8733

これはこういうテキストをペーストすると一気に全部入る！！！

eringi blog: Pear/Net_Url_Mapper
今はたいていのフレームワークにURLをルーティングする機能が備わってるけど、その機能だけを抜き出したようなパッケージ。やっつけで作ったオレオレフレームワークに組み込んだり、いまいち使い方が分からないEthnaのステキURLを代替できそう。

おお、Railsみたいに書けちゃうのかよ。

おれのもはや見たくもない大量のrewrite ruleゴッソリ減りそう。

p0t: １テーブル１インデックス
オライリーの「実践ハイパフォーマンスMySQL」には

「MySQLでは、1つのクエリを実行する時、１つのテーブルにつき１つのインデックスしか使用できない」

と書いてあります。同じような内容を公式リファレンスマニュアルからは見つけられなかったんですが、実際に試して見る限りそのようです。他のRDBの感覚で言うと１テーブル１インデックスしか使われないのでは現実的な速度が出ない気がします。

この問題について。

何人かの人に聞いて回ったりしてるんですが、はっきりしたことはわかってません。

現状の俺の結論としてはこんな感じです。

MySQLモデリングは実在する！（他のDBより非正規化を早い段階で行う）
データモデリング手法の中には（この問題のせいで）MySQLでは機能しないものもある。
MySQLでは非正規化でパフォーマンスを上げる。

眠たいことを言ってもしょうがないので断言気味です。

元々、通常のプログラミングとDBでは（インデックスのせいで）パフォーマンスの良い設計っていうのが感覚的に結構違う気がします。MySQLの非正規化は（DBAに対して）プログラマ側の考え方で、自分の慣れた理論にもってけるので特に文句が出てないんじゃないのかと思いました。

オンメモリのテーブルとか、レプリケーションとかレベル２のテーブル分割とか、それって、「1テーブル１インデックス問題」のせいでいろいろやらなきゃいけなくなってんじゃないの？とか怪しんでます。

関連エントリー：

Plnetでサービスをカテゴリー分けできるようにしました。

サービスをドラッグしてカテゴリ分けします。

何かいい見せ方がないか考え中です。

パフォーマンス改善を正しくやりたいとか言っておいて、Plnetがあまりに重く、使い物にならなくなっていたので焦ってまた勘で対応していまいました・・・。

しかも効果がありまくりで・・・。

mysqlがslow-query出しまくりなのでページキャッシュを入れまくりました。Mojavi2なんでこういうSmartyプラグインを作った感じです。

&lt;?php
if (!defined(CACHE_LITE_DIR)) define('CACHE_LITE_DIR', '/tmp/');
if (!defined(CACHE_LITE_AUTO_CLEANING)) define('CACHE_LITE_AUTO_CLEANING', 128);

function smarty_function_mojavi_action($params, &$smarty)
{
    $id = $params['module'].'_'.$params['action'];

    if (isset($params['lifetime'])) {
        include_once 'Cache/Lite.php';
        $cache =& new Cache_Lite(array(
            'cacheDir' =&gt; CACHE_LITE_DIR,
            'lifeTime' =&gt; $params['lifetime'],
            'automaticCleaningFactor' =&gt; CACHE_LITE_AUTO_CLEANING,
            'automaticSerialization' =&gt; true
        ));

        $cache_id = $id.'_'.
            (isset($params['cache_id']) ? $params['cache_id'] : '');
        if ($data = $cache-&gt;get($cache_id)) {
            return $data;
        }
    }

    $controller =& Controller::getInstance();
    $actionChain =& new ActionChain();
    $actionChain-&gt;register($id, $params['module'], $params['action']);
    $actionChain-&gt;execute($controller, $controller-&gt;request, $controller-&gt;user);
    $data = $actionChain-&gt;fetchResult($id);
    if (isset($params['lifetime'])) $cache-&gt;save($data, $cache_id);
    return $data;
}
?&gt;

なんでDBが重いのにmysql serverがCPU食わないんだろう。clientの方ばっかり食ってることになってる。

とりあえずcocoitiさんにスケーラブルWebサイトを借りたので読んで悔い改めたいと思います。

スケーラブルWebサイト
オライリー・ジャパン(2006-12-26)
オライリー・ジャパン
(著)Cal Henderson
(翻訳)武舎広幸
(翻訳)福地太郎
(翻訳)武舎るみ
定価：￥ 3,570
新品価格：￥ 3,570
中古価格：￥ 2,913
ASIN：4873113113

吉田電車
講談社(2007-01-12)
講談社
(著)吉田戦車
定価：￥ 540
新品価格：￥ 540
中古価格：￥ 243
ASIN：4062756315

筆者吉田のますますおっさんくさい、楽しみや全然グルメじゃない旨さがおかしい。仕事とはいえ一人で楽しげなところにいろいろ出かけて家族の者（大）や（小）は怒らないんだろうかと心配してしまいます。

そもそも“正しいパフォーマンス改善”とは何なのか。

要するに勘で良いとされることを手当たり次第やるんじゃなくて、原因に基づいて対策をしたい。

前回のとこのzionicさんのコメントとエントリが参考になりました。

zionicの日記
wa(I/O Wait)は0なので、とりあえず無視する。us(User Space)がやたら高い。基本的にはCPU食いすぎ、と考えてよいと思われる。

色々対策したい部分はあるけれど、兎に角CPUを食わないようにしなきゃいけない！

エントリにあるようにeAcceleratorが効きそう。構文解析しない分CPUの負荷は減るはず。

手元の環境で試してみました。

$ sudo apt-get install php4-dev
$ wget 'http://bart.eaccelerator.net/source/0.9.5/eaccelerator-0.9.5.tar.bz2'
$ tar jxf eaccelerator-0.9.5.tar.bz2
$ cd eaccelerator-0.9.5
$ phpize
Configuring for:
PHP Api Version:         20020918
Zend Module Api No:      20020429
Zend Extension Api No:   20050606
$ ./configure --enable-eaccelerator=shared --with-php-config=/usr/bin/php-config
$ make
$ sudo make install
Installing shared extensions:    /usr/lib/php4/20020429/ 
$ sudo vi /etc/php4/apache2/php.ini
[eaccelerator]
zend_extension="/usr/lib/php4/20020429/eaccelerator.so" 
eaccelerator.shm_size = "32" 
eaccelerator.enable = "1" 
$ mkdir /tmp/eaccelerator
$ chmod 0777 /tmp/eaccelerator

apache2-utilsのApache BenchでeAccelerator有り／無しで測ってみた。

eAccelerator無し：

$ sudo ab -c 5 -n 100 http://plnet/komagata/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking plnet (be patient).....done

Server Software:        Apache/2.2.3
Server Hostname:        plnet
Server Port:            80

Document Path:          /komagata/
Document Length:        21964 bytes

Concurrency Level:      5
Time taken for tests:   35.508370 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2235600 bytes
HTML transferred:       2196400 bytes
Requests per second:    2.82 [#/sec] (mean)
Time per request:       1775.418 [ms] (mean)
Time per request:       355.084 [ms] (mean, across all concurrent requests)
Transfer rate:          61.48 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   79 281.9      0    1781
Processing:   318 1669 2986.9    680   20417
Waiting:        0  750 1461.3    366    8742
Total:        318 1748 3033.9    701   20417

Percentage of the requests served within a certain time (ms)
  50%    701
  66%    899
  75%   1125
  80%   1651
  90%   5874
  95%   8144
  98%  12675
  99%  20417
 100%  20417 (longest request)

eAccelerator有り：

$ sudo ab -c 5 -n 100 http://plnet/komagata/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking plnet (be patient).....done

Server Software:        Apache/2.2.3
Server Hostname:        plnet
Server Port:            80

Document Path:          /komagata/
Document Length:        21964 bytes

Concurrency Level:      5
Time taken for tests:   18.760849 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2236800 bytes
HTML transferred:       2196400 bytes
Requests per second:    5.33 [#/sec] (mean)
Time per request:       938.042 [ms] (mean)
Time per request:       187.608 [ms] (mean, across all concurrent requests)
Transfer rate:          116.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       1
Processing:   520  928 596.4    859    6521
Waiting:      241  637 590.1    553    6212
Total:        520  928 596.5    859    6522

Percentage of the requests served within a certain time (ms)
  50%    859
  66%    925
  75%    978
  80%    996
  90%   1122
  95%   1227
  98%   1832
  99%   6522
 100%   6522 (longest request)

Requests per secondが2.82 [#/sec]　→　5.33 [#/sec]で倍近くに増えてる。これは良さそうだ。

昨日の1時頃、Plnet.jpに入れてみました。

あんまり変ってないな・・・。

あと気になる点はmysqlのslow-queryがバリバリ出てるとこ。しかしtopでmysqlは全然あがってこないのでCPUに関係無いと思う。それともmysqlが遅いとそれに関係したapacheがCPUを使うってことがあるのかな？

いちおうtop：

top - 11:51:08 up 190 days,  3:46,  1 user,  load average: 9.55, 7.71, 5.17
Tasks:  67 total,   2 running,  65 sleeping,   0 stopped,   0 zombie
Cpu(s): 85.1% us, 14.9% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    971496k total,   757916k used,   213580k free,    52888k buffers
Swap:  2000084k total,    51384k used,  1948700k free,   536868k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
24948 www-data  15   0 53868  15m  47m S  1.0  1.7   0:00.49 apache2
24883 www-data  15   0 56740  17m  47m S  0.6  1.9   0:01.81 apache2
24815 www-data  16   0 54360  18m  47m S  0.3  1.9   0:01.22 apache2
    1 root      16   0  1504  420 1352 S  0.0  0.0   0:13.74 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.14 ksoftirqd/0
    3 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 events/0
    4 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 khelper
   15 root       5 -10     0    0    0 S  0.0  0.0   3:40.75 kblockd/0
   51 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
   50 root      15   0     0    0    0 S  0.0  0.0   6:45.89 kswapd0
  187 root      25   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
  293 root      15   0     0    0    0 S  0.0  0.0  17:48.87 kjournald
  554 root      15   0     0    0    0 S  0.0  0.0   0:00.03 kjournald
  555 root      15   0     0    0    0 S  0.0  0.0   9:14.08 kjournald
  556 root      15   0     0    0    0 S  0.0  0.0   3:44.86 kjournald
  557 root      15   0     0    0    0 S  0.0  0.0   5:29.24 kjournald
  711 root       6 -10     0    0    0 S  0.0  0.0   0:00.00 ata/0
  712 root      23   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_0
  713 root      23   0     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_1
  761 root      15   0     0    0    0 S  0.0  0.0   0:00.00 khubd
 1819 daemon    15   0  1612    4 1440 S  0.0  0.0   0:00.00 portmap
 2182 root      16   0  2260  432 2092 S  0.0  0.0   1:13.34 syslogd
 2185 root      17   0  2444    4 1344 S  0.0  0.0   0:00.07 klogd
 2193 root      16   0  2628  232 2192 S  0.0  0.0   0:00.08 rpc.dracd
 2223 Debian-e  16   0  5128  312 4752 S  0.0  0.0   0:00.85 exim4
 2229 root      15   0  2240    4 2084 S  0.0  0.0   0:00.00 inetd
 2246 daemon    16   0  1684   48 1520 S  0.0  0.0   0:00.00 atd
 2249 root      16   0  1764  228 1576 S  0.0  0.0   0:01.59 cron
 2260 root      17   0  1500    4 1336 S  0.0  0.0   0:00.00 getty
 2261 root      17   0  1500    4 1336 S  0.0  0.0   0:00.00 getty
 2262 root      16   0  1500    4 1336 S  0.0  0.0   0:00.00 getty
 2263 root      16   0  1500    4 1336 S  0.0  0.0   0:00.00 getty
 2264 root      16   0  1500    4 1336 S  0.0  0.0   0:00.00 getty
 2265 root      16   0  1500    4 1336 S  0.0  0.0   0:00.00 getty
21946 root      16   0 11728  912 7792 S  0.0  0.1   0:02.78 miniserv.pl
 1952 root      16   0 11872  216 7792 S  0.0  0.0   0:00.00 miniserv.pl
17964 root      16   0  3468  336 3092 S  0.0  0.0   0:43.35 sshd

komagataのブログ

スケーラブルWebサイト

マ（略）を勉強したい

Debian etchリリース

シリアルの簡単ペースト

PEAR Net_Url_Mapper

MySQLモデリングの違和感

カテゴリー分け

パフォーマンス改善を正しくやりたい3

吉田電車

パフォーマンス改善を正しくやりたい2