[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[kagemai-users:0421] 影舞のスケーラビリティ
福岡です。
影舞がどの程度の数のレポートを扱えるかは、影舞を使う人にとっては
それなりに気になるところだと思います。
0.8.5 の MySQL 対応をしているときに、スケーラビリティの改善が
期待できると思っていたので、0.8.4 との比較データを取ってみました。
* テスト環境
- CPU: Pentium4 2.4GHz
- Memory: 1G byte
- OS: SuSE Linux 9.1 professional
- Ruby 1.8.2
- Apache 2.0.49 + mod_ruby 1.2.4
- PostgreSQL 7.4.6 + ruby-postgres 0.7.1
- MySQL 4.0.18 + MySQL/Ruby 2.5.1 (テーブルのタイプは MyISAM)
* テスト方法
レポート数が 100, 500, 1000, 5000, 10000 のプロジェクトに対して、
- トップページのアクセスにかかる時間
- 「バグ」というキーワードを検索したときにかかる時間
をそれぞれ計測。クライアントマシンから、lynx を使ってページの取得
にかかった実時間を測る。(lynx は --dump オプションを使って、HTML
のレンダリングはしない。)
- 計測に使うプロジェクトの各レポートは、平均3個のリプライメッセージを持つ
- トップページには全レポートの約20%が表示される状態
- トップページの表示は、内部で HTML キャッシュが生成されるので、
キャッシュがないときと、キャッシュがあるときの両方を計測する
ただし、厳密なデータがほしいわけではないので、複数回データをとって
処理するとかはしてません。
* 0.8.4 （トップページへのアクセス）
N xml(1st) xml(2nd) pg(1st) pg(2nd)
-------------------------------------------------
100 0.9 0.3 1.1 0.1
500 2.2 0.1 4.0 0.1
1000 3.7 0.1 6.6 0.1
5000 26.4 0.2 34.2 0.2
10000 53.0 0.3 132.3 0.3
xml: XMLStore, pg: PostgresStore
1st: キャッシュ無効, 2nd: キャッシュ有効
単位は一回のアクセスにかかった時間（秒）です。
* 0.8.4 （検索）
N xml pg
---------------------
100 1.6 0.3
500 7.4 0.4
1000 15.9 0.5
5000 110.3 1.2
10000 273.3 2.1
* 0.8.5 (トップページへのアクセス)
N xml(1st) xml(2nd) pg(1st) pg(2nd) mysql(1st) mysql(2nd)
------------------------------------------------------------------------
100 0.8 0.3 0.5 0.1 0.3 0.1
500 2.1 0.1 1.3 0.2 0.6 0.1
1000 4.1 0.1 1.9 0.1 1.0 0.1
5000 29.0 0.2 6.9 0.2 5.7 0.2
10000 51.2 0.3 13.4 0.3 15.8 0.3
* 0.8.5 （検索）
N xml pg mysql
----------------------------
100 1.3 0.6 0.2
500 5.5 0.7 0.3
1000 11.9 0.8 0.3
5000 90.8 1.6 0.4
10000 200.6 2.2 0.6
0.8.4 と 0.8.5 を比較すると、XMLStore はだいたい同じ（なにも変更してないし）、
PostgresStore は N = 10000 のとき、 10 倍ぐらい速くなってます。
MySQLStore と PostgresStore では、トップページは同じぐらいで、検索は
MySQL のほうが速いですね。
ちなみに、XMLStore では、レポートやリプライの投稿時に、
トップページの表示（キャッシュが無効の場合）と同程度以上の
時間がかかります。PostgreSQL、MySQL ではレポート数によらず
ほぼ一定です。
今回の計測では、レポート数が 5000、10000 の場合トップページに
表示されるレポート数はそれぞれ 1000、2000 となっていますが、
そもそもトップページにレポートが 1000 も表示される状態だと、
表示時間がもっと速くても使い物にならないでしょうね。そういった
状態になるプロジェクト（短期間に多数のレポートが登録されるよう
なプロジェクト）では、現在の影舞とは異なった UI が必要なんだと
思います。
0.8.5 の PostgresStore、MySQLStore では、トップページに表示
される対象のレポート数が減れば、表示に必要な時間も減ります。
したがって、長い期間使った結果レポートの数が増えた場合など、
レポート数は多くてもトップページにはそれほどレポートがたまって
いないのであれば、総レポート数が 10000 を越えても十分実用的な
速度で動くような気がします。
トップページに数百以上のレポートが表示されるようなプロジェクト
での UI については、今後の課題ですね。というか、影舞にそこまで
求めている人がいるかにもよるんですが。
--
福岡ともゆき <fukuoka@xxxxxxxxxxxxx>
http://www.daifukuya.com/