VPS performans testi nasıl yapılır?

Bir VPS'i kıyaslamanın anlamı

Bir VPS'i kıyaslamak için dört unsuru ölçersiniz: tek bir CPU çekirdeğinin çalışma hızı, makinenin bellek bant genişliği, depolama biriminin saniyede gerçekleştirdiği küçük rastgele disk işlemleri ve ağ bağlantısının sağladığı veri aktarım hızı. yabs.sh ile yapılan tek bir çalıştırma, yaklaşık on dakika içinde CPU, disk ve ağ sonuçlarını verir; bellek bant genişliği için aşağıdaki ayrı bellek testini kullanın. Sonuçları okumak daha zor kısımdır, çünkü bir VPS (sanal özel sunucu) fiziksel donanımı diğer kiracılarla paylaşır; bu nedenle aynı makine 03:00'te bir değer, 20:00'de ise çok farklı bir değer rapor edebilir.

Buradaki plan, hızlı bir genel bakış için yabs.sh aracını çalıştırmak ve ardından altındaki araçları manuel olarak kullanmaktır. Araçları kendiniz çalıştırmak, bir bayrağı (flag) değiştirmenize, sayının nasıl değiştiğini izlemenize ve bu sayının gerçekte neyi ölçtüğünü öğrenmenize olanak tanır. Bunu makine kurulduktan sonra yapın, önce değil. Yeni bir VPS'teki ilk on dakika içindeki adımlar önceliklidir, çünkü ilk güncelleme turunu henüz tamamlayan bir sunucu, donanımla ilgisi olmayan nedenlerden dolayı kötü kıyaslama sonuçları verecektir.

Ölçüm yapmadan önce makineyi inceleyin

Kötü bir performans testinin yarısı, yazarın anlamadığı bir makineden kaynaklanır.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM tam sanallaştırma anlamına gelir, bu sayede kendi çekirdeğinizi çalıştırırsınız. systemd-detect-virt üzerinde lxc veya openvz yazdığını görmek, bunun yerine konteyner sanallaştırması kullanıldığı anlamına gelir: ana makine çekirdeğini paylaşırsınız ve CPU ile bellek limitleriniz sanal donanım yerine cgroup (kontrol grubu) ayarlarıdır. Bir cgroup v2 sisteminde, CPU limitini konteynerinizin cgroup'undan okuyabilirsiniz; aşağıdaki yol, bu cgroup /sys/fs/cgroup dizinine bağlandığında geçerlidir.

cat /sys/fs/cgroup/cpu.max

max 100000, bu cgroup'un kendine ait bir kotası olmadığı anlamına gelir; ancak üst cgroup'lar yine de bir kota uygulayabilir. 200000 100000, her 100000 mikrosaniyelik periyotta 200000 mikrosaniyelik CPU kullanabileceğiniz anlamına gelir; bu da iki çekirdek değerinde bir kotaya denk gelir. İki çekirdek kotası ile 4 vCPU olarak pazarlanan bir plan, asla dört çekirdek performansı veremez. Performans testi araçları bu kısıtlamayı tespit edebilir: VoxelBench, CPU kotalarını raporlar ve ana makine, sunucunun kullanabileceğinden çok daha fazla CPU gösterdiğinde paylaşımlı veya kısıtlanmış (throttled) CPU uyarısı verir.

df -hT / farklı bir nedenden dolayı önemlidir: Type sütunu. Eğer bu sütunda overlay yazıyorsa bir konteyner içindesiniz demektir ve disk sonuçlarınız, o katmanın altında yer alan depolama birimini yansıtacaktır. Bunu şimdi not edin.

Steal time değerini sürekli izleyin

Steal time, sanal CPU'nuzun hipervizör tarafından zamanlanmadığı durumlarda istemsizce bekleyerek geçirdiği sürenin payıdır. Bu değer, kullanılamayan CPU süresi için yararlı bir sinyaldir; ancak meşgul komşular ile sağlayıcının uyguladığı CPU kotası arasında ayrım yapmaz.

vmstat 1 10

Sağ taraftaki st sütununu okuyun. Sürekli yüksek steal time, CPU süresinin konuk makine için kullanılamadığını gösterir; ancak %5'in üzerindeki bir değer, ana makinenin aşırı yüklendiğini kanıtlamaz. Sağlayıcılar, CPU kotası kısıtlamalarını kasıtlı olarak steal time olarak yansıtabilir. top, CPU satırındaki %st ile aynı rakamı gösterir. Kıyaslama (benchmark) yaparken ikinci bir SSH oturumunda vmstat 1 aracını çalışır durumda tutun ve her sonuç için steal time değerini not edin.

yabs.sh ile başlayın

yabs.sh (Yet Another Bench Script), fio, iperf3 ve Geekbench araçlarını çalıştıran ve tek bir özet raporu sunan bir kabuk betiğidir. Eğer sistemde yüklüyse fio ve iperf3 araçlarını kullanır, yüklü değilse statik ikili dosyaları indirir. VPS performans karşılaştırmalarında ortak bir dil haline geldiğinden, yabs çıktısı başka bir kullanıcıyla sonuçları kıyaslamanın en hızlı yoludur.

Projenin kendi tek satırlık çalıştırma komutu şöyledir.

curl -sL yabs.sh | bash

Bu komut, URL'nin o an sunduğu içeriği doğrudan bir kabuğa aktarır. Dosyayı indirin, içeriğini inceleyin ve ardından çalıştırın.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Bayraklar, -s -- ile borulama (pipe) yaparken veya yerel bir kopyayı çalıştırırken dosya adından hemen sonra eklenir. Kullanışlı olanlar şunlardır: -f disk testini atlar, -i ağ testini atlar, -g Geekbench testini atlar, -r iperf3 lokasyonlarını üçe indirir, -j sonuçları JSON formatında yazdırır ve -w results.json bu JSON çıktısını bir dosyaya kaydeder.

bash yabs.sh -r -w yabs-run1.json

İlk çalıştırmadan önce bilinmesi gereken iki husus vardır. Geekbench sonuçlarınızı yükler ve herkese açık bir browser.geekbench.com URL'si oluşturur; bu bağlantıya sahip herkes CPU modelinizi ve puanlarınızı görebilir. -g bu testi tamamen atlar. İkinci olarak, iperf3 aşaması çeşitli bölgelerdeki sunuculara gerçek trafik gönderir ve bu durum aylık bant genişliği kotanızdan düşer. 1 Gbit/s hızındaki bir bağlantıda tam bir ağ testi aşaması onlarca gigabayt veri tüketebilir; bu nedenle düşük kotalı paketlerde -r, ölçümlü (metered) bağlantılarda ise -i bayrağını kullanın.

Yabs çıktısının her bir bölümü ne anlama gelir

Disk bölümü, 4k, 64k, 512k ve 1m olmak üzere dört farklı blok boyutunda, yüzde 50 okuma ve yüzde 50 yazma karışımıyla fio çalıştırır. Her biri için IOPS (saniye başına giriş/çıkış işlemi) ve bant genişliği değerlerini raporlar. Veritabanı, posta sunucusu veya çok sayıda küçük yazma işlemi yapan herhangi bir uygulama için 4k satırı dikkate alınmalıdır; çünkü çoğu sunucu G/Ç işlemi küçük ve dağınıktır. 1m satırı ise uzun veri bloklarının taşındığı yedekleme ve video işlemleri içindir.

Ağ bölümü, iperf3 aracını kullanarak çeşitli bölgelerdeki genel sunuculara karşı, her iki yönde ve paralel akışlarla test gerçekleştirir. Buradaki düşük sayıları kesin bir sonuçtan ziyade bir soru işareti olarak değerlendirin; çünkü genel iperf3 sunucuları paylaşımlıdır ve genellikle yoğunluk altındadır, bu nedenle düşük bir sonuç karşı taraftan kaynaklanıyor olabilir.

Geekbench bölümü, tek çekirdek ve çoklu çekirdek puanı verir. Tek çekirdek puanı; bir isteğin, bir derleme işleminin veya bir sorgunun ne kadar hızlı tamamlanacağını öngörür. Çoklu çekirdek puanı ise büyük ölçüde gerçekte kaç çekirdeğe sahip olduğunuzu gösterir.

Disk: fio aracını kendiniz çalıştırın

fio (flexible IO tester), yabs disk bölümünün temelindeki araçtır; aracı doğrudan kullanmak, bayrakların (flags) anlam kazandığı noktadır.

sudo apt update && sudo apt install -y fio sysbench iperf3

İlgilendiğiniz dosya sistemi üzerinde, 32 kuyruk derinliğinde (queue depth) 4k rastgele okuma testi:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

Çıktıdan okunması gereken özet satırı şu şekildedir.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Bunun altında fio bir clat percentiles bloğu yazdırır. Yüzde 99.00'luk dilim (99.00th percentile) referans alınması gereken değerdir, çünkü bu değer yüz istekten en yavaş olanının ne kadar beklediğini gösterir. Ortalama gecikme süresi, kullanıcının fark ettiği takılmaları gizler.

• --direct=1 dosyayı O_DIRECT ile açar, böylece okuma işlemleri kernel sayfa önbelleğini (page cache) atlar. Bu bayrak olmadan, 8G RAM'e sahip bir makinede 2G'lik bir dosya üzerinde yapılan ikinci geçiş bellekten servis edilir ve fio milyonlarca IOPS raporlar. Bu sayı gerçektir ancak bir bellek performans değeridir.
• --ioengine=libaio asenkron istekler gönderir; --iodepth=32 değerinin 32 isteği aynı anda işleme almasını sağlayan budur. psync gibi senkron bir motorla, 1'den büyük bir iodepth değeri hiçbir işe yaramaz; bu durumda istekleri tek tek ölçersiniz.
• --time_based --runtime=60 sabit bir iş miktarı yerine sabit 60 saniye boyunca çalışır; böylece hızlı ve yavaş diskler aynı süre boyunca test edilir ve karşılaştırma adil kalır.
• --size=2G test dosyası boyutunu belirler. Bu boyutu yol üzerindeki tüm önbelleklerden daha büyük tutun ve önce yeterli boş alanınızın olduğundan emin olun.

Rastgele yazma testi, --rw=randwrite bayrağı ile aynı komuttur. Testi ayrı olarak çalıştırın ve ardından dosyayı silin.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Gerçek trafiğe daha yakın bir karışım için --rw=randrw --rwmixread=70 kullanın. Hangi depolama sınıfı üzerinde olduğunuz, bu sonuçları herhangi bir bayraktan daha fazla değiştirir; bu ayrım bir VPS üzerinde NVMe ve SATA SSD depolama arasındaki fark bölümünde ele alınmıştır.

fio, Unknown error -1 hatası ile durduğunda

Direct IO her dosya sisteminde kullanılamaz; bu nedenle fio, --direct=1 ayarı etkinleştirilmiş halde ilk isteğinde başarısız olduğunda, elenmesi gereken ilk seçenek Direct IO'dur. Hata şu şekilde görünebilir:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Öncelikle df -hT . komutunu çalıştırın. Docker'ın varsayılan olarak bir container'a atadığı overlay türündeki bir Type, tek başına hatanın nedeni değildir. overlayfs, O_DIRECT bayrağını altındaki dosya sistemine iletir ve yalnızca o dosya sistemi Direct IO işlemini desteklemediğinde reddeder; bu nedenle --direct=1 --ioengine=libaio, ext4 veya xfs üzerinde çalışan bir overlay üzerinde sorunsuz çalışır. Test dosyasının bulunduğu dosya sistemi gerçekten Direct IO desteklemediğinde, fio dosyayı açarken genellikle şu hatayı verir: fio: looks like your file system does not support direct=1/buffered=0. Bu durumda --filename parametresini bind mount edilmiş bir volume gibi gerçek bir yerel depolama yoluna yönlendirin veya fio'yu container içinde değil, doğrudan ana makine üzerinde çalıştırın. Gerçek depolama birimine erişim yoksa, arabelleğe alınmış (buffered) senkron bir çalıştırma en azından komutun kendisinin doğru olduğunu kanıtlar.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Bu çalıştırmanın ne olduğu konusunda dürüst olun. İlk geçişten sonra 256M boyutundaki dosya page cache içinde kalır; dolayısıyla elde edilen IOPS değeri RAM performansınızı yansıtır. Bu yöntemi yalnızca fio'nun yüklü olduğunu ve bayrakların doğru ayrıştırıldığını doğrulamak için kullanın. Bunu asla bir disk sonucu olarak raporlamayın.

Neden dd bir disk performans testi aracı değildir

dd birçok VPS tartışmasında karşımıza çıkar ve tek bir dar kapsamlı soruya yanıt verir.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Bu komut, tek bir iş parçacığı ve tek bir aktif istek ile sıralı yazma hızını ölçer. Makul bir temel kontrol yöntemidir. Rastgele G/Ç (random IO) performansı veya aynı anda 32 istek geldiğinde ne olacağı hakkında hiçbir bilgi vermez. oflag=direct parametresini kaldırdığınızda yazma işlemleri sayfa önbelleği (page cache) üzerinden gerçekleşir; ancak conv=fdatasync parametresi, komut tamamlanmadan önce verinin depolama birimine yazılmasını zorunlu kılar. Bunu da kaldırırsanız, elde edilen sonuç büyük oranda çekirdeğin veriyi belleğe ne kadar hızlı kabul ettiğini ölçer. Forum gönderilerinde paylaşılan absürt dd değerlerinin nedeni budur.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Dikkate alınması gereken değer events per second'dir. İlk olarak tek iş parçacıklı (single-threaded) testi çalıştırın. Bu değer, bir PHP isteğinin ne kadar hızlı tamamlanacağını veya bir derleme işleminin ne kadar sürede biteceğini belirleyen ve aynı fiyattaki sunucular arasında en çok değişkenlik gösteren metriktir. Ardından tüm iş parçacıklarıyla testi çalıştırın; bu, iş hacminin (throughput) atanan vCPU'lar üzerinde nasıl ölçeklendiğini gösterir.

Bu testin neyi ölçtüğü konusunda net olun: sysbench cpu, deneme bölme yöntemiyle sürekli olarak asal sayıları bulur. Her aday sayı için çift duyarlıklı bir karekök alır, ardından 64 bitlik tamsayı modülo işlemiyle bölenleri test eder ve her böleni bu kayan noktalı limit ile karşılaştırır. Dolayısıyla tamsayı ve kayan noktalı işlem yükünü bir arada kullanır. Bellek bant genişliğini, vektör birimlerini veya önbelleği gerçek bir iş yükünü andıracak şekilde zorlamaz; bu nedenle iki sunucuyu kıyaslamak için iyi, uygulamanızın nasıl çalışacağını tahmin etmek için ise yetersizdir.

Ubuntu 24.04, test adının başta yer aldığı sysbench 1.0.20 sürümüyle gelir. Eski bir kaynaktan --test=cpu içeren bir komutu kopyalarsanız WARNING: the --test option is deprecated hatası alırsınız. sysbench 0.4 ve sysbench 1.0'dan elde edilen puanlar kesinlikle kıyaslanamaz; bu nedenle sürüm bilgisi belirtilmeyen yayınlanmış bir değerle kendi sonuçlarınızı asla karşılaştırmayın.

Bellek: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

Sonuç MiB/sn cinsindendir. --memory-block-size değerini 1M seviyesinde tutun ve karşılaştırma yaptığınız her sunucuda aynı kalmasını sağlayın. 1K değerinde sayı düşüşe geçer; çünkü işlem başına düşen ek yükü bin kat daha fazla ödersiniz ve sonuçta bellek bant genişliği yerine döngü maliyetini ölçmüş olursunuz. Bu, yayınlanan bellek skorlarında en sık yanlış eşleştirilen bayraktır.

Ağ: iperf3

Veri aktarım hızını test etmenin en güvenilir yolu, kontrolünüz altındaki ikinci bir makine kullanmaktır; böylece her iki uçta da ne yapıldığından emin olursunuz.

Uzak uçta:

iperf3 -s

Bu komut TCP 5201 portunu dinlemeye başlar. Portu yalnızca test yapacağınız adrese açın ve işlem bittiğinde kapatın. VPS üzerinde temel ufw güvenlik duvarı kuralları bölümü söz dizimini açıklar.

Test edilen VPS üzerinden:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

İlk komut, test edilen makineden karşıya yükleme hızını ölçer. -R bayrağı yönü tersine çevirerek indirme hızını ölçer. -P 8 bayrağı ise sekiz paralel akış açar.

Hem tek akışlı hem de paralel sürümü çalıştırın, çünkü bu testler farklı sorulara yanıt verir. Bir TCP bağlantısı, pencere boyutu izin verdiği kadar onaylanmamış veri taşıyabilir; bu nedenle hız sınırı kabaca pencere boyutunun gidiş-dönüş süresine (RTT) bölünmesiyle hesaplanır. 80 ms gecikme ve 4 MB pencere boyutu ile bu sınır, alttaki bağlantı ne kadar hızlı olursa olsun yaklaşık 400 Mbit/s civarındadır. Tek akışlı değer, tek bir indirme işleminin alacağı hızı gösterir. Paralel değer ise bağlantının toplam kapasitesini ortaya koyar.

Bu testleri yaparken bant genişliği kotanızı takip edin. 1 Gbit/s hızında otuz saniyelik bir test yaklaşık 3.75 GB veri tüketir ve bu testi her iki yönde birkaç kez tekrarlayacaksınız.

Referans değerler ve kendi sonuçlarınızı nasıl okumalısınız

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

Yayınlanan sonuçlarda yerel bir NVMe birimi genellikle 180,000 4k rastgele okuma IOPS değerine yakın bir performans sergiler. Yerel bir SATA SSD ise yaklaşık 90,000 civarındadır. Her isteğin diske ulaşmadan önce bir ağ üzerinden geçtiği ağ tabanlı blok depolama (network attached block storage) 12,000 değerine daha yakındır; dönen diskler (spinning disk) ise her rastgele istek için fiziksel bir okuma kafasını hareket ettirmek zorunda olduklarından yaklaşık 180 değerini yönetebilir.

Bunlar, tek bir sunucudan alınan ölçümler değil, her depolama sınıfı için yayınlanan tipik değerlerdir. Bu değerleri yalnızca tek bir amaç için kullanın: kendi sonucunuzun doğru büyüklük mertebesinde olup olmadığını kontrol etmek. NVMe olarak satılan bir plan, 4k IOPS testlerinde düşük binli değerler veriyorsa, öncelikle --direct=1 özelliğinin açık olduğundan emin olun. Eğer açıksa, planın IOPS limitlerini ve burst kredilerini, ayrıca depolama üzerindeki yoğunluğu ve reklamı yapılan donanımı kontrol edin.

Neden tek bir çalıştırma kıyaslama (benchmark) sayılmaz

Tek bir sonuç, paylaşımlı bir makinede geçen bir dakikanın anlık görüntüsüdür. Bunu tek bir örneklem olarak değerlendirin.

• Her testi en az beş kez çalıştırın; bu çalıştırmaları farklı saatlere ve en az iki farklı güne yayın. Medyan değerini ve dağılımı kaydedin. Dağılım bilgisi içermeyen bir sonuç, pazarlama verisidir.
• Her çalıştırmanın yanına steal time değerini kaydedin. st değerinin yüksek olduğu çalıştırmaları saklayın ve bunların çekişmeden mi yoksa planın CPU kotasından mı kaynaklandığını araştırın; bu verileri göz ardı etmek, gerçekte aldığınız performansı gizleyebilir.
• Disk testini iki farklı sürede çalıştırın. Birçok plan, zamanla dolan bir burst IOPS kotası sunar; ancak ne 60 saniyelik bir fio çalıştırması ne de --runtime=600, taban performansını ölçtüğünüzü garanti eder. AWS gp2 kredileri, tam bakiyeden itibaren en az 30 dakika boyunca 3.000 IOPS değerini sürdürebilir, bu nedenle her iki çalıştırma da burst performansını ölçüyor olabilir. Sağlayıcının kredi modelini kontrol edin ve bir sonucu sürdürülebilir performans olarak nitelendirmeden önce kredi bakiyesini izleyin.
• Başka hiçbir şeyin çalışmadığından emin olun. Bir CPU testi sırasında unattended-upgrades ile bir apt işlemi başlatmak size gerçek puan kaybettirir ve her çalıştırmadan önce ps -e -o comm= | grep -E 'apt|dpkg' komutunu kullanmak bir saniyenizi alır.
• Her seferinde yalnızca bir değişkeni değiştirin. Farklı araç sürümleri, blok boyutları veya iş parçacığı sayıları, ne kadar benzer görünürlerse görünsünler birbiriyle kıyaslanamayacak sonuçlar üretir.

İki sağlayıcıyı kıyaslarken, testleri aynı günün aynı saatinde çalıştırın. Aksi takdirde, sadece günün saatini ölçmüş olursunuz.

Kendi iş yükünüzü en son kıyaslayın

Sentetik araçlar makineleri sıralar. Bir makinenin yeterli olup olmadığını yalnızca kendi iş yükünüz belirler. Gerçekte yaptığınız işi zamanlayın.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Bu işlem birkaç yüz megabaytlık veriyi sıkıştırır; böylece hem CPU hem de disk aynı anda test edilir ve herhangi birinde değişiklik olduğunda sonuç değişir. Removing leading / from member names uyarısı normaldir. Daha iyisi, kendi derleme işleminizi, en yavaş sorgunuzu veya kendi sayfa oluşturma sürecinizi zamanlamaktır. Bir sunucuda 4 dakika, diğerinde 7 dakika süren bir derleme işlemi, Geekbench ne derse desin sorunu çözmüştür. Bu ölçüm aynı zamanda, daha güçlü bir makineye ödeme yapmanın ne zaman anlamsız hale geldiğini de gösterir; bu bilgiyi bir VPS'in aylık gerçek maliyeti hakkında bilgi edinmeden veya iş yükünü özel bir sunucuya taşımadan önce bilmek faydalıdır.

FAQ

Neden her çalıştırdığımda farklı bir benchmark sonucu alıyorum?

Bir VPS, fiziksel CPU, depolama ve ağ kaynaklarını diğer kiracılarla paylaşır; bu nedenle sonucunuz, diğerlerinin o anki işlemlerine bağlıdır. Test sırasında vmstat 1 komutunu çalıştırın ve st sütununu inceleyin: "steal time" değeri, kullanılamayan CPU süresini kaydeder ancak bu durum hem sağlayıcının satın aldığınız CPU kotasını uygulamasından hem de ana makinedeki yoğunluktan kaynaklanabilir. %5 üzerindeki bir değer, sorunun kaynağını tek başına kanıtlamaz. Çözüm, ince ayar yapmaktan ziyade metodolojidedir. Her testi farklı saatlerde beş veya daha fazla kez çalıştırın, ardından medyan değeri ve dağılım aralığını raporlayın.

fio neden milyonlarca IOPS rapor ediyor?

Bu durum neredeyse her zaman --direct=1 parametresinin eksikliğinden kaynaklanır. Bu parametre olmadan fio, kernel sayfa önbelleği (page cache) üzerinden okuma yapar; dolayısıyla ilk geçişten sonra 2G boyutundaki bir test dosyası RAM üzerinden sunulur ve siz aslında bellek bant genişliğini ölçmüş olursunuz. --direct=1 parametresini ekleyin ve test dosyasını yoldaki tüm önbelleklerden daha büyük tutun. Eğer --direct=1 başarısız olursa df -hT . komutunu çalıştırın ve test dosyasının hangi katman üzerinde durduğunu kontrol edin. Bir overlay türü tek başına sorun değildir, çünkü overlayfs, O_DIRECT komutunu alttaki depolama birimine iletir. Test dosyasını yalnızca alttaki dosya sistemi doğrudan IO (direct IO) işlemlerini reddediyorsa gerçek yerel depolama birimine taşıyın.

yabs.sh tek başına yeterli mi?

İlk inceleme için evet. Dört farklı blok boyutunda fio, her iki yönde iperf3 ve Geekbench testlerini çalıştırır; başkalarının da anlayabileceği tek bir özet rapor sunar. Test başına bayrakları (flags) değiştiremediğiniz için, bir sayının neden o değerde olduğunu anlamak istediğinizde yetersiz kalır. Bir yabs sonucu hatalı görünüyorsa, bunu doğrudan fio veya sysbench ile yeniden oluşturun ve her seferinde tek bir bayrağı değiştirerek test edin.

Uygulamamın performansını hangi tek bir sayı öngörür?

Çoğu web ve veritabanı iş yükü için öncelik sırasıyla tek çekirdekli CPU hızı ve 4k rastgele okuma gecikmesidir. İş hacmi (throughput) rakamları etkileyici görünse de nadiren belirleyicidir, çünkü tipik bir istek küçük boyutludur. Ortalama değer yerine fio clat percentiles bloğundaki 99. yüzdelik dilimi (99th percentile) baz alın; çünkü kullanıcıların fark ettiği, yüz istekten bir tane olan yavaş istektir.

Benchmark öncesinde herhangi bir şey kurmam gerekiyor mu?

fio, sysbench ve iperf3, Ubuntu ve Debian depolarında mevcuttur: sudo apt install -y fio sysbench iperf3. yabs.sh, Bash üzerinde çalışır ve indirme işlemleri için curl veya wget, Geekbench'i açmak için ise tar gerektirir; tar olmadan Geekbench adımı atlanır. Araçlar kurulu olduğunda fio ve iperf3'ü kullanır, kurulu olmadıklarında ise statik binary dosyalarını indirir. İşiniz bittiğinde tüm test dosyalarını silin; çünkü 20G disk üzerinde unutulan 2G boyutundaki bir fio dosyası, haftalar sonra birinin disk doluluk uyarısı haline gelebilir.