Tag Archives: apache

Permalink to single post

WordPressのベンチマーク

卒論とかやばい。にも関わらず鯖いじり。

現在atomでサーバー(自宅サーバー)やってみたりしてます。省電力だし、大してスペックもいらねぇだろうと思っていたからです。が、WordPressとかPukiWikiとかがやっぱり遅い。過去にWordPressの高速化を試みたりもしましたが、結局のところあまり成果は出ず。最終的にこれはAtomが原因なのかその他の要因があるのか区別するためにもベンチマークとってみました。

テスト環境

  • 環境A: 現行サーバー
    • Intel Atom N330 (1.6GHz Dual Core+HT)
    • メモリ 2GB(2GB DDR2一枚)
  • 環境B: デスクトップマシン
    • Intel Core 2 Duo E8500 (3.16GHz Dual Core)
    • メモリ 4GB(2GB DDR2二枚)

ソフトウェアは両方同じ。

  • Gentoo Linux
  • Apache/2.2.14
  • WordPress 2.9.1-ja

で、Apache Benchを使って計測。CPU能力はかるのが目的なので、ローカルホストからのアクセスのみ計測しました。

コマンドは

$ ab -n 100 -c 10 http://wordpressのトップページのURL/

です。

そしてその結果

  • 環境A (Atom)

Document Path:          /path/to/wordpress
Document Length:        5964 bytes

Concurrency Level:      10
Time taken for tests:   33.000 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      631600 bytes
HTML transferred:       596400 bytes
Requests per second:    3.03 [#/sec] (mean)
Time per request:       3300.000 [ms] (mean)
Time per request:       330.000 [ms] (mean, across all concurrent requests)

Transfer rate:          18.69 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:  1410 3227 561.2   3290    4610
Waiting:     1410 3224 561.4   3290    4610
Total:       1410 3227 561.2   3290    4610

Percentage of the requests served within a certain time (ms)
50%   3290
66%   3480
75%   3570
80%   3640
90%   3800
95%   4030
98%   4460
99%   4610
100%   4610 (longest request)

  • 環境B

Document Path:          /path/to/wordpress/
Document Length:        5610 bytes

Concurrency Level:      10
Time taken for tests:   8.536 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      585100 bytes
HTML transferred:       561000 bytes
Requests per second:    11.71 [#/sec] (mean)
Time per request:       853.649 [ms] (mean)
Time per request:       85.365 [ms] (mean, across all concurrent requests)

Transfer rate:          66.93 [Kbytes/sec] received

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   407  841 131.7    842    1237
Waiting:      407  841 131.7    842    1237
Total:        407  841 131.7    842    1237

Percentage of the requests served within a certain time (ms)
50%    842
66%    890
75%    916
80%    940
90%   1009
95%   1044
98%   1165
99%   1237
100%   1237 (longest request)

Core 2 duo E8500のが4倍近く早いですね。

結論

以前、wp-cacheを導入してみた時も4倍近く早くなりました。つまり、Core 2 Duo E8500の場合であればボトルネックは別のところ(ディスクアクセスとか?)に発生していると推定することもできます。

その推定が正しければ、このWordPressの速度のボトルネックはやっぱりAtomになってしまうようです。

WordPressだのWikiだの、Webプログラム使いまくる人にはやっぱりAtomはやや厳しいところがあるようです。

・・・まぁ当たり前っちゃ当たり前か。

ということで、WordPressを高速化するためにも新しいサーバーを買うことにするわけなのです。

Permalink to single post

Gentooのpostgresql

うちではdev-db/postgresqlを~x86に設定しています。
いろいろ使う機能があるからね。

でも、inspircdとか、apacheのmod_auth_pgsqlとかがどうも古いpostgresql(8.0)を参照してしまってインストールに困っていた。
とりあえずPostgreSQLのUSEフラグを無効にしたりしていたけど原因が判明。

virtual/postgresql-baseが古いままだったからっぽい。

多分初歩的な事なんだろうけど、全然気づかなかった。。。

ということで、package.keywordsに

=virtual/postgresql-base-8.2 ~x86

を追加して、インストールしなおしたらすんなり成功。

めでたしめでたし。

Permalink to single post

slicehostの速度改善

sunagae.netのサーバーがやたら反応遅く感じたて、調べてたら
どうやらメモリが足りなくなっていて、スワップ領域を使いまくってることが判明。

というかなぜ今まで気づかなかったんだ。。。
遠隔onlyだと結構そういうことも気づかないようですね。

現在のメモリ割り当て量は256MB。
増やすという手もあるが、金がかかるのでメモリ使用量削減という方向で探る。

  • apacheのプロセス数の設定を1/3ぐらいに減らす
  • 読み込むモジュールを削りまくる

とりあえずこの二つで使用量を200MB程度に抑えることができました。

レスポンスはかなり早くなった気がします。。

まぁいずれにせよ、いつかはメモリ増やすんだろうなぁ。。。