Bir arka ucu nasıl karşılaştırırız: tekrarlanabilir bir metodoloji

Rakip bir duyarlı arka ucun yayıncısı olan Convex, teknik ekibinin veritabanı sağlayıcıları arasındaki "çubuk grafik savaşı" olarak adlandırdığı durumdan kendisini açıkça uzaklaştırdı. Formülü doğrudan: "Bu ölçeklendirme tiyatrosu, ölçeklendirme değil" - tiyatroyu ölçeklendirmek, gerçek ölçeklendirme değil (stack.convex.dev/on-competitive-benchmarks, Stack teknik blogu, 23 Ağustos 2026'da erişildi).

Temel argümanı: Farklı tutarlılık, topoloji veya fiyatlandırma modeli garantilerine sahip iki sistemi karşılaştıran bir kıyaslama, bunu iddia etse bile çoğu zaman aynı şeyi test etmez - "kıyaslama aslında aynı şeyi test etmez". Bu refleksin sektörde bir adı var: kıyaslama, metodolojik titizliğinden ziyade pazarlama etkisi nedeniyle seçilen bir rakamı yayınlamak.

Cevabımız ölçüm yapmayı reddetmek değil; bir rakamı süresiz olarak yayınlamayı reddetmek, kanıtlanmamış bir rakamı yayınlamak kadar sahtekârlık olur. Herhangi bir şeyi ölçtüğümüzü iddia etmeden önce, öncelikle nasıl, hangi araçlarla, hangi koşullar altında ölçüm yapacağımızı belgelemek. Bu aynı zamanda yararlı bir karşılaştırmayı (doğrulanabilir mimari farklılıkları belgeleyen Aurabase ile Appwrite karşılaştırmamızgibi) ortak bir protokol olmadan performans rakamlarının karşılaştırmasından ayıran şeydir.

Bu, bir teknik komitede arka uç seçimini savunması gereken bir teknik lider veya CTO için özellikle önemlidir: bir yönteme kadar izi sürülemeyen bir figür, biraz ısrarcı olan ilk soruda hayatta kalamaz. Belgelenmiş bir protokol kendini savunur; betiği, test edilen sürümü gösterebilir ve gerekirse testi birinin önünde tekrar çalıştırabilirsiniz.

Sistematik olarak iki tuzak ortaya çıkıyor: farklı topolojileri raporlamadan karşılaştırmak ve kullanıcı için en önemli duraklamaları tam olarak gizleyecek şekilde gecikmeyi ölçmek.

İlk noktada, PlanetScale donanım eşlik kısıtlamasını açıkça belgeliyor: karşılaştırılan her ortam, aynı bulut bölgesinde, referans örneğine eşit veya ondan daha büyük bilgi işlem kaynakları (vCPU, RAM) üzerinde çalışmalıdır (planetscale.com/benchmarks, “Telescope” metodolojisi, 23 Ağustos 2026'da erişildi). Bu disiplin olmadan, gecikme boşluğu daha hızlı bir mimariyi değil, daha büyük bir makineyi yansıtabilir.

Aynı prensip önbellek durumu ve ağ topolojisi için de geçerlidir. Yeni başlayan bir örnek (soğuk Postgres önbelleği, boş bağlantı havuzu, henüz önbelleğe alınmamış sorgu planı), kararlı yük altında bir saat boyunca çalışan bir örnekten yapısal olarak daha yavaş yanıt verir. Veritabanıyla aynı bölgeden gelen bir sorgu, yapısal olarak bölgeler arası bir sorgudan daha hızlı yanıt verir. Her ikisini de belirtmeyen iki kıyaslama, aynı birimleri gösterseler bile kesinlikle karşılaştırılamaz.

İkinci noktada ise tuzağa koordineli ihmal adı veriliyor. Gil Tene tarafından oluşturulan gecikme ölçümüne ilişkin referans proje olan HdrHistogram, bunu şu şekilde açıklıyor: Bir yük oluşturucu, bir sonraki isteği (kapalı döngü) göndermeden önce bir isteğin yanıtını beklediğinde, bir hizmet duraklaması, duraklatma sırasında gönderilen isteklerin sayısını ve dolayısıyla kaydedilen yüksek gecikme ölçümlerinin sayısını otomatik olarak azaltır (github.com/HdrHistogram/HdrHistogram, Erişim tarihi: 23 Ağustos 2026). Proje somut ve sayısal bir örnek veriyor: Gecikmesini 200 saniye boyunca her 10 ms'de bir örnekleyen varsayımsal bir sistemde, testin ortasındaki 100 saniyelik tek bir duraklama, düzeltme olmaksızın, yanıtların yaklaşık %99,99'unun 1 ms'nin altına sığdığı görünen bir histogram üretmek için yeterlidir - gerçek zamanın yarısı bu tek duraklamada geçmiş olsa bile.

Yirmi istekten biri beş kat daha uzun sürdüğünde ortalama gecikme mükemmel görünebilir. Yüzdelik dilimlerin ortaya çıkardığı ve ortalamanın yapısal olarak gizlediği şey tam olarak budur.

Mekanik olarak yüzdelik dilimde gizemli bir şey yoktur: ölçülen tüm gecikmeleri artan düzende sıralayın ve ardından ilgili konumdaki değeri alın. Sıralanan 1000 sorgudan p50 500'üncü, p95 950'inci, p99 ise 990'ıncı değerdir. 1000 istek arasında anormal derecede yavaş olan tek bir istek, p99'u hareket ettirmek için yeterlidir - onu faydalı kılan şey tam olarak nadir durumlara olan duyarlılığıdır, burada aynı izole isteğin ortalama üzerinde neredeyse hiçbir etkisi yoktur.

Anlatılan işaret: Resmi PostgreSQL kıyaslama aracı olan pgbench'nin varsayılan olarak görüntülediği metin raporu yüzdelik değerleri değil ortalama ve standart sapma verir (postgresql.org/docs/current/pgbench.html, 23 Ağustos 2026'da erişildi). Resmi belgeleri aynı zamanda şu uyarıyı da yapıyor: "Yalnızca birkaç saniye süren hiçbir teste asla inanmayın" - yalnızca birkaç saniye süren bir teste asla inanmayın; bu, seçilen ölçüm için olduğu kadar süre için de geçerlidir.

Paketimizin 2. düzeyi için kullandığımız yükleme aracı k6, bunu yüzdelik olarak ifade edilen eşiklerle çözer: p(95)<500 sözdizimi, doğrudan test yapılandırmasında bir başarılı/başarısız kriterini tanımlar — isteklerin %95'i 500 ms içinde yanıt vermelidir — (grafana.com/docs/k6, 23 Ağustos'ta danışıldı, 2026).

Gerçek araçlar olmadan bir metodoloji yayınlamak tiyatronun başka bir biçimi olacaktır. Aurabase deposundaki benchmarks/ klasörü zaten yapısında halka açık Supabase metodolojisinden ilham alan 3 seviyeli bir paket içeriyor; araçlar mevcut, ölçülen ve tarihlenen sonuçlar henüz mevcut değil.

Seviye 1 — Mikro Kıyaslamalar Criterion.rs

Kargo çalışma alanı'nin üç kasası CPU'ya bağlı özel kıyaslamalara sahiptir: aura-crypto (Argon2 karma, JWT HS256 — PostgREST, AES-GCM şifreleme için oluşturma, doğrulama ve imza), aura-db-adapters (filtreleri ayrıştırma ve PostgREST formatında select — eq., gte., in.(), ilişki yerleştirmeleri) ve aura-core (JSON serileştirme, schema_nameçözümleme, UUID doğrulaması).

// Depodan gerçek alıntı
let mut group = c.benchmark_group("jwt/hs256");

group.bench_function("generate", |b| {
    b.iter(|| jwt::generate_access_token(
        black_box(user_id), black_box(project_id),
        black_box("authenticated"), black_box(SECRET),
    ))
});

group.bench_function("validate", |b| {
    b.iter(|| jwt::validate_token(black_box(&token), black_box(SECRET)))
});

aura-db-adapters özellikle PostgREST formatı sorgularının ayrıştırılma maliyetini ölçer - filtreler için dört durum (simple_4, complex_10, or_group, in_large_50 50 değerle) ve select için dört durum (tek sütunlar, *, bir ilişki yerleştirme, beş yerleştirme). Bu, küresel yük testinde görülmeyen türden bir maliyettir: karmaşık bir or.(...) filtresinin analizindeki bir regresyon, az kullanılan bir uç noktanın p95'inde neredeyse hiçbir şeyi değiştirmez, ancak yüksek trafiğe sahip bir uç noktada ölçülebilir hale gelir; dolayısıyla onu yalnızca seviye 2'ye güvenmek yerine bir mikro kıyaslamada izole etmeye olan ilgi.

aura-core farklı bir yaklaşım benimser: ham zamanı ölçmek yerine, ağ geçidi ile hizmetler arasında alınıp verilen dahili NatsRequest/NatsResponse iletilerinin JSON serileştirmesi ve seri durumdan çıkarılmasındaki verimini (Throughput::Bytes) ölçer - üç gerçekçi yük boyutuyla (minimum istek, iç içe JSON gövdesine sahip bir istek, 50 satırlık bir istek) yanıtı listele).

group.throughput(Throughput::Bytes(
    serde_json::to_vec(&small).unwrap().len() as u64
));
group.bench_function("NatsRequest/small", |b| {
    b.iter(|| serde_json::to_vec(black_box(&small)).unwrap())
});

Criterion.rs yalnızca bir döngüyü zamanlamaz. Öncelikle CPU/OS önbelleklerini doldurmak için bir ısınma aşaması çalıştırır, aykırı değerleri Tukey yönteminin değiştirilmiş bir versiyonuyla tespit eder (bunları veri kümesinden hariç tutmadan), çok sayıda yeniden örneklenmiş örnek üzerinde önyükleme yaparak güven aralıklarını hesaplar ve istatistiksel olarak anlamlı olmayan varyasyonları göz ardı etmek için yapılandırılabilir bir gürültü eşiğiyle (tipik olarak ±%1) Öğrenci istatistiksel testi ile iki çalıştırma arasındaki performans gerilemelerini tespit eder () bheisler.github.io/criterion.rs/book/analiz.html, 23 Ağustos 2026'da erişildi).

Seviye 2 – k6 yük testi

Sekiz k6 komut dosyası, veri düzlemi tarafındaki ağ geçidini kapsar: health (gecikme temel çizgisi), auth-flow (kayıt → oturum açma → yenileme → oturumu kapatma), crud-read ve crud-write, storage (yükleme/indirme), realtime-ws, breakpoint (arızaya kadar yük artışı) ve supabase-compare. Yedi tanesi özel bir Makefile hedefine bağlanmıştır — supabase-compare.js depoda mevcuttur ancak henüz bir hedefi yoktur; bu makale onu gizlemek yerine olduğu gibi belgeleyen bir durumdur.

export const options = {
  scenarios: {
    crud_read: {
      executor: 'ramping-vus',
      startVUs: 10,
      stages: [
        { duration: '30s', target: 50 },
        { duration: '1m', target: 200 },
        { duration: '30s', target: 0 },
      ],
    },
  },
  thresholds: THRESHOLDS_READ,
}

Paylaşılan konfigürasyon, işlem türüne göre eşikleri tanımlar. Bunlar, testin her çalıştırıldığında kontrol ettiği başarılı/başarısız kriterleridir; halihazırda ölçülen sonuçlar değil:

Seviye 3 — Doğrudan PostgreSQL ve API karşılaştırması

Bir Python betiği (direct_vs_api.py), doğrudan psycopg2 isteklerini aynı işlemdeki HTTP çağrılarıyla (liste, kimliğe göre tek seferlik okuma, filtrelenmiş ve sıralanmış okuma) karşılaştırarak ağ geçidi + hizmet katmanının gerçek yükünü ölçer. Her ölçüm, zamanlanmış döngüden önce 10 yinelemelik bir ısınmayı takip eder, ardından ortalama p50, p95, p99'u ve saniye başına işlem hacmini hesaplar.

def percentile(data, p):
    k = (len(data) - 1) * (p / 100)
    f = int(k)
    c = f + 1
    if c >= len(data):
        return data[f]
    return data[f] + (k - f) * (data[c] - data[f])

İkinci bir komut dosyası (aurabase_vs_supabase.py), yerel bir Supabase örneğiyle (varsayılan olarak Supabase CLI, localhost:54321) birebir karşılaştırmaya aynı ısınma ve yüzdelik hesaplama mantığını uygular - aynı makine, her ikisi için aynı yerel ağ, tam olarak PlanetScale'in kendi karşılaştırmaları için belgelediği ortam eşlik disiplini.

Bir düzenleme komut dosyası (collect_baseline.sh, hedef bench-baseline of Makefile) üç düzeyi birbirine bağlar - 3 kasadaki Kriter, k6 senaryolarının bir alt kümesi (health ve crud-read bugün, henüz 8'i değil), ardından Python karşılaştırması - ve günlükleri, JSON ve Criterion HTML raporlarını benzersiz zaman damgalı bir klasöre yazar: benchmarks/results/AAAAMMJJ_HHMMSS/. Bu tam olarak, aşağıdaki bölümün eksiksiz bir protokolde resmileştirdiği, tek bir tekrarlanabilir çalışmada tarihli açıklamanın refleksidir.

Her biri tanınmış bir üçüncü taraf aracı veya projesi tarafından zaten belgelenmiş olan ve bu durum için icat edilmemiş bir uygulamaya dayanan sekiz taahhüt.

1. Ölçümden ayrı ön ısıtma. Criterion.rs, zamanlamadan önce CPU/OS önbelleklerini doldurur; pgbench açıkça yalnızca birkaç saniye süren bir koşuya asla inanmamanızı önerir.
2. Sabit sayıda yineleme değil, sabit süre. Bir yükün yakınsaması için zamana ihtiyacı vardır — bu, stages k6'nın rolü ve pgbench'nin -T bayrağıdır.
3. Yüzdelikler, hiçbir zaman sadece ortalama — ve yük oluşturucunun kapalı bir döngüde çalışması durumunda koordineli ihmal konusunda aktif dikkat.
4. Ortam ayrıntılı olarak belgelenmiştir: test edilen hizmetin git taahhüdü, PostgreSQL sürümü, donanım özellikleri, yükleme aracının sürümü. PlanetScale tam olarak bu nedenle TPCC parametrelerini (TABLES=20, SCALE=250, ~500 GB) belgeliyor — bu ayrıntılar olmadan hiç kimse bir çalışmayı yeniden oluşturamaz.
5. Zaman damgalı ve versiyonlu sonuçlar, asla bir pazarlama sayfasına tarih olmadan tek bir sayı kazınmaz. Geçerli takım zaten tarihli bir dosyaya yazılmıştır; diğer çevresel değişkenler gibi belgelenen ev sahipliği bölgesi ile bu refleksi kamuya açık herhangi bir ölçümü kapsayacak şekilde genişletmek gerekli olacaktır (bir rakam belirli bir bölgeye bağlı olduğunda geçerli olan AB barındırma egemenliğihakkındaki kılavuzumuza bakın).
6. Yalnızca nihai ortalama değil, toplu sonuçla birlikte yayınlanan komut dosyaları ve ham veriler. PlanetScale, okuyucuları metodolojik bir hatayı özel bir adrese bildirmeye bile davet ediyor; sağlıklı bulduğumuz ve devam ettirmek istediğimiz bir duruş.
7. Gecikmenin yanı sıra reklamı yapılan aktarım hızı, yalnızca biri veya diğeri değil. Bir sistem, düşük yükte mükemmel gecikme süresine sahip olabilir ve eşzamanlılık arttıkça verimde çökebilir; k6 paketimizin breakpoint senaryosunun (çarpışmaya ölçeklendirme) ortaya çıkarmak için tasarladığı şey tam olarak budur ve Criterion'un Throughput::Bytes mikro kıyaslama ölçümünün işlev düzeyinde yakaladığı şey budur.
8. Bir iyileştirme duyurulmadan önceki önemli boşluk. İki çalışma arasındaki yüzde birkaçlık bir değişiklik, gerçek bir kazançtan ziyade ölçüm gürültüsü olabilir — Criterion.rs, gözlemlenen farkın, regresyon veya iyileştirme olarak nitelendirilmeden önce şansa bağlı olma olasılığını hesaplar. Bu doğrulama olmadan izole edilmiş bir rakam sadece istatistiksel bir anekdottur.

Bu liste yukarıdaki pozitif protokol kadar önemlidir.

• Farklı topolojileri (kendi kendine barındırılan ve yönetilen, soğuk ve önceden ısıtılmış örnek) açıkça raporlamadan karşılaştırma.
• Diğer dokuzundan bahsetmeden on üzerinden en iyi sırayı koruyun.
• Bir rakamı tarih olmadan, hizmet versiyonu olmadan, çoğaltma metni olmadan yayınlayın.
• Bu protokole kadar takip edilmediği sürece mevcut bir pazarlama rakamını yeniden yayınlayın.
• Kendimizi bir rakiple ham performans rakamına göre karşılaştırmak, eğer o rakip kendi metodolojisini eşdeğer bir şekilde yayınlamıyorsa - rakama karşı sessizlik bir karşılaştırma değil, bir slogandır.

Bu protokol herhangi bir özel Aurabase aracına bağlı değildir; bunu bugün kendi API'nize uygulayabilirsiniz.

1. Yükü araçtan önce ayarlayın: uygulamanız için salt okunur, yazılabilir, gerçekçi karışım; başka bir projeden kopyalanan genel bir oran değil.
2. Ön ısıtma aşamasını ölçüm aşamasından açıkça ayırın.
3. Testi yeterince uzun süre çalıştırın; saniyeler değil, dakikalar.
4. Yüzdelik dilimler halinde ölçün (p50/p95/p99), asla tek başına ortalama olarak ölçün.
5. Yük oluşturucunuzun kapalı döngüde olmadığını doğrulayın veya analizdeki koordinasyon ihmalini düzeltin.
6. Test edilen ortamı izole edin; gürültülü komşular yok, rakip arka plan görevleri yok.
7. Yalnızca nihai sonucu değil, test edilen sürümü, tarihi, donanım özelliklerini ve komut dosyasını yayınlayın.

Basit bir Postgres tabanında, bu protokol tek bir komut alır: pgbench — 4 iş parçacığına dağıtılan 20 eşzamanlı istemci, 5 dakika süreyle ve her 10 saniyede bir ilerleme raporuyla birlikte:

# Test veri kümesini başlatın (ölçek faktörü >= istemci sayısı)
pgbench -i -s 50 ma_base

# -c eşzamanlı istemciler, -j iş parçacıkları, saniye cinsinden -T süre, -P raporlama aralığı
pgbench -c 20 -j 4 -T 300 -P 10 ma_base

Her biri farklı bir yığın düzeyine uygun beş araç; hiçbiri diğerinin yerini almaz.