RackspaceCloud Apache Benchmark Testi

Rackspace Cloud Servers'ın 256MB ve 15.5GB sanal sunucularını ApacheBench (ab) ile sınadım. Aynı imaj, aynı Apache yapılandırması, farklı RAM tiyerleri, sonuçlar elastik bulutun gerçek karakterini gösteriyor.

Geçtiğimiz haftalarda Rackspace Cloud Servers tarafında bir denemeye giriştim. Amacım basit bir merak gidermekti: aynı imajı iki farklı RAM tiyerinde (en küçük 256MB ve en büyük 15.5GB) ayağa kaldırıp Apache üzerinde tek bir statik dokümanı ab (ApacheBench) ile yüklediğimde nasıl bir tablo çıkacak? Cloud sağlayıcıların pazarlama broşürlerinde yer alan “kullandığın kadar öde” ve “saniyeler içinde ölçeklenir” söylemleri çok güzel; ama mühendis olarak rakamı görmek istiyor insan.

Test ortamı şu şekilde kuruldu:

  • Rackspace Cloud Servers (DFW bölgesi)
  • Ubuntu 10.04 LTS (Lucid Lynx) 64-bit imajı
  • Apache 2.2.3 (varsayılan prefork MPM, default config)
  • Test edilen doküman: ~5 KB’lik tek bir statik sayfa
  • İstemci: aynı veri merkezindeki ayrı bir 512MB sanal sunucu (ağ gecikmesini minimumda tutmak için)

ApacheBench komutu her iki test için de aynıydı:

ab -n 10000 -c 10 http://<sunucu-ip>/

10.000 istek, 10 eş zamanlı bağlantı. Düşük bir eşzamanlılık, evet, ama benim asıl ilgilendiğim şey “tepe yük” değildi, sürekli rejimde yanıt süresi ve dengenin ne kadar tutarlı olduğuydu.

256MB tiyeri

İlk denek en küçük sanal sunucu: 256MB RAM, 10GB disk, 4 sanal çekirdek paylaşımlı. Çıktının önemli kısımları:

Server Software:        Apache/2.2.3
Document Length:        5043 bytes
Concurrency Level:      10
Complete requests:      10000
Failed requests:        0
Requests per second:    17.47 [#/sec] (mean)
Time per request:       572.361 [ms] (mean)
Time per request:       57.236 [ms] (mean, across all concurrent requests)
Transfer rate:          89.40 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      194  314  520.6    222    3246
Processing:   197  250  198.9    224    5219
Waiting:      196  249  198.9    223    5218
Total:        391  564  556.9    448    5455

Percentage of the requests served within a certain time (ms)
  50%    448
  75%    468
  90%    485
  95%   1116
  99%   3470
 100%   5455 (longest request)

Top çıktısında belleğin yarısından biraz fazlasının kullanıldığını gördüm: yaklaşık 161MB used, 90MB free. Apache prefork süreçleri uçuşan istekleri rahatça karşıladı, swap’a hiç düşmedi.

15.5GB tiyeri

Ardından zincirin diğer ucuna gittim: en büyük tek-sanal-sunucu paketi, 15872MB RAM. Aynı imaj, aynı Apache yapılandırması, aynı doküman.

Server Software:        Apache/2.2.3
Document Length:        5043 bytes
Concurrency Level:      10
Complete requests:      10000
Failed requests:        0
Requests per second:    15.90 [#/sec] (mean)
Time per request:       628.746 [ms] (mean)
Transfer rate:          81.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      184  365  701.5    230    9265
Processing:   187  261  154.6    232    2574
Waiting:      186  261  154.6    231    2573
Total:        375  627  717.4    464   10333

Percentage of the requests served within a certain time (ms)
  50%    464
  75%    500
  90%    538
  95%   1230
  99%   3501
 100%  10333 (longest request)

Top çıktısı: 15.4GB free, sadece 432MB kullanımda. Yani sunucu sıkıştırılmaktan çok uzak, bekleyen aslan gibi oturuyor.

Neyi görüyoruz?

İlk bakışta tuhaf gelebilir: 60 kat fazla RAM’e sahip sunucu, küçük kardeşinden bir miktar daha yavaş yanıt verdi (15.90 vs 17.47 rps). Sayılar paradoks gibi durabilir ama aslında öğretici.

1. Statik bir doküman için RAM darboğaz değil

5KB’lik bir HTML için Apache zaten neredeyse hiç bellek tüketmiyor. 256MB sunucudaki dosya OS sayfa önbelleğine düştükten sonra disk I/O yok, sadece socket işleme ve TCP turları var. Dolayısıyla RAM’i 60’a katlamak performansı düz çizgide tutuyor, beklenen sonuç, ama broşürdeki “büyük sunucu = hızlı sunucu” miti için iyi bir tokat.

2. Asıl darboğaz hipervizör ve ağ

Eşzamanlılık 10’a düşük tutulduğunda 1-1.5 saniyelik 95. yüzdelik kuyruğu görüyoruz. Bu, sanallaştırılmış ortamlarda “noisy neighbor” probleminin klasik imzası. Aynı host’ta paylaştığım fiziksel makinede başka bir kiracı disk veya CPU sıkıştırırsa, benim isteğim de o “duraklama”ya tabi oluyor. Bu, XenServer üzerinde çalışan tüm cloud sağlayıcıların ortak gerçeği, Rackspace burada özellikle kötü değil; sadece elastik altyapının doğası.

3. “Bulut” tek sunucu için bir kazanç değildir

Belki test edilmesi gereken en önemli sezgi bu. Cloud Servers’ı dedicated bir sunucu gibi tek başına kullanırsanız, çoğu zaman aynı parayı ödediğiniz fiziksel bir kiralık sunucudan daha düşük tepe performansı alırsınız. Bulutun değeri tek bir sunucunun rps’inde değil; talep arttığında ikinci, üçüncü, beşinci instance’ı 5 dakika içinde ayağa kaldırıp arkalarına bir load balancer (Rackspace Cloud Load Balancers veya kendi HAProxy’niz) koyabilmenizde. Yatayda ölçeklenirsiniz, dikey değil.

Pratik çıkarımlar

  • 256MB Cloud Server, basit bir kurumsal site veya WordPress blogu için bugünün koşullarında fazlasıyla yeterli. RAM kararını CPU veya rps üzerinden değil, çalıştıracağınız uygulamanın gerçek bellek ayak izine bakarak verin.
  • Yüksek tepe yükü olan bir uygulama bekliyorsanız tek sunucuyu büyütmek yerine, iki orta tiyer sunucu + load balancer kurgusu hem daha ucuza geliyor hem de aynı host arızasında ayakta kalma şansınız var.
  • ApacheBench iyi bir ısınma turu, ama gerçek üretim trafiğini taklit etmez. JMeter veya httperf ile keep-alive açık ve dağıtılmış istemcilerle de test edin.

Önümüzdeki haftalarda aynı testi Amazon EC2’nin micro ve large instance’ları üzerinde tekrarlamayı planlıyorum. Aynı imaj, aynı yük profili, farklı sağlayıcı, kıyas için faydalı bir tablo çıkacaktır.