sakuraとslicehostの簡単な評価の続き

sakuraとslicehostの簡単な評価の続き。

ぱっと見てメモリのswapで遅くなっている雰囲気だったので、passengerの起動数を抑制する。

$ sudo vi /etc/apache2/httpd.conf
RailsMaxPoolSize 2

再度10並列の実験。

$ ab -n10 -c10 "http://slice/..."
:
Concurrency Level:      10
Time taken for tests:   14.465143 seconds
Complete requests:      10
Failed requests:        0
Write errors:           0
Total transferred:      1670090 bytes
HTML transferred:       1664720 bytes
Requests per second:    0.69 [#/sec] (mean)
Time per request:       14465.144 [ms] (mean)
Time per request:       1446.514 [ms] (mean, across all concurrent requests)
Transfer rate:          112.68 [Kbytes/sec] received

2倍はやい!?

もしかして富豪的プログラマーにお薦め?

まとめ

apacheのチューニングもなしに静的なページにアクセスしたりsqlite3的なrailsを叩いたりして簡単に測定した。

静的ページではsakuraが良かったが、動的ページでは$20のslicehostの方が同等もしくはそれ以上の結果を出した。以上の結果を踏まえて結論を出すには尚早だが、計算を行うサーバとしてslicehostはなかなか使えそうだ。

過去にrailsなどのサービスを提供するための専用サーバサービスの選び方にてロジックと画像のサーバを分ける検討をした。ロジックはslicehost、画像はsakuraに置く手法を用いればスケーラブルで応答の良い安価なサービスが展開できるかもしれない。railsでは画像やスタイルシートのサーバを別に定義することができる(ex. config.action_controller.asset_host)。

今後の評価次第だが、画像を用いない、応答性を要求しないサービスであれば、slicehostを検討すべきかもしれない。

カテゴリー: チラシの裏 パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください