MetaSearch Benchmark Methodology: API Latency ve Reliability Standardı

Bu sayfa, metasearch.com.tr tarafından yayımlanacak API latency ve reliability benchmarklarının nasıl ölçüleceğini tanımlar. Amaç provider sıralaması üretmek değil; farklı travel API'lerini mümkün olduğunca tekrar edilebilir ve açıklanabilir koşullarda ölçmektir.

1. Ölçüm birimi

Temel gözlem birimi tek bir outbound HTTP request'tir. Her request için en az şu alanlar tutulur:

• provider / target adı,
• scenario,
• request başlangıç zamanı,
• toplam duration,
• HTTP status,
• timeout/error class,
• response size,
• cache mode,
• test region,
• run ID,
• methodology version.

OpenTelemetry HTTP semantic conventions, HTTP client request duration'ı standart bir telemetry metriği olarak tanımlar. Benchmark dataset'i bu yaklaşımı referans alır.

2. Latency metrikleri

Tek bir average değeri yayımlamak yeterli değildir. Her target/scenario için en az:

• p50,
• p95,
• p99,
• min/max,
• success count,
• timeout count,
• error count

raporlanır.

Percentile hesapları raw request-level dataset'ten yeniden üretilebilir olmalıdır.

3. Reliability

Reliability yalnız HTTP 5xx oranı değildir.

Ayrı sınıflar tutulur:

• success,
• HTTP 4xx,
• HTTP 5xx,
• timeout,
• DNS/network/TLS error,
• malformed/unexpected response,
• rate-limit response.

Provider-specific business error'lar mümkünse ayrıca sınıflandırılır ancak farklı API'ler arasında doğrudan eşdeğer kabul edilmez.

4. Warm ve cold cache

Warm-cache ve cold-cache sonuçları aynı dağılıma karıştırılmaz.

Bir target'ın cache davranışı dışarıdan doğrulanamıyorsa sonuç "cache state unknown" olarak etiketlenir. DNS/TLS/connection reuse gibi transport etkileri de test tasarımında açıkça belirtilir.

5. Geography ve network

Her benchmark run şu bağlamı kaydetmelidir:

• test region / cloud region,
• country,
• runtime,
• Node.js version,
• IPv4/IPv6 durumu biliniyorsa,
• proxy/VPN kullanımı,
• run başlangıç/bitiş zamanı.

Tek bir region'dan alınan sonuç global performans diye sunulmaz.

6. Sample size ve time window

Küçük sample yalnız exploratory sonuç üretir.

Public benchmark yayımlanmadan önce:

• sample size target başına açıklanır,
• test window yayımlanır,
• request spacing belirtilir,
• günlük/saatlik dağılım varsa açıklanır,
• retry davranışı açıkça yazılır.

Rate limit'i zorlayan burst test kullanılmaz.

7. Request pacing

Default runner bilinçli olarak düşük hızda çalışır:

• concurrency: 1,
• minimum interval: 1 saniye,
• target başına maksimum request sayısı: 100.

Daha yüksek hız ancak provider'ın açık load/performance test izni varsa ayrı test olarak yapılabilir.

8. Provider ve ToS sınırı

Benchmark yalnız erişim hakkı bulunan endpoint'lerde çalıştırılır.

• robots.txt API kullanım izni yerine geçmez,
• public docs bulunması otomatik benchmark izni anlamına gelmez,
• credential gerekiyorsa credential repository'ye yazılmaz,
• ToS veya partner contract performans yayınını sınırlıyorsa sonuç yayımlanmaz.

9. Comparable scenarios

Farklı iş yapan endpoint'ler tek tabloda "kim daha hızlı" diye karşılaştırılmaz.

Örnek scenario family'leri:

• hotel content lookup,
• hotel availability/search,
• price confirmation/recheck,
• flight indicative search,
• flight live search.

Her sonuç aynı scenario family içinde değerlendirilir.

10. Response completeness

Düşük latency tek başına iyi sonuç değildir.

Mümkün olduğunda ayrıca tutulur:

• result count,
• payload size,
• partial-result flag,
• response validation sonucu.

Hız ile completeness trade-off'u varsa raporda belirtilir.

11. Reproducibility

Her public benchmark release şu artefact'ları içermelidir:

• methodology version,
• runner version/commit,
• sanitized config,
• raw CSV/JSON,
• aggregate summary,
• environment metadata,
• known limitations.

Secret, credential, PII veya provider contract kapsamında gizli bilgi dataset'e girmez.

12. Conflict of interest

metasearch.com.tr veya ilişkili bir ürün ölçülen provider'lardan ticari fayda sağlıyorsa bu ilişki benchmark sayfasında açıklanır.

Sponsorlu ölçüm varsa sponsor methodology veya sonucu değiştiremez.

13. Methodology versioning

İlk sürüm: v1.0 — 2026-09-26

Methodology değişirse eski dataset'e sessizce uygulanmaz. Yeni version ile yayımlanır ve değişikliğin karşılaştırılabilirliğe etkisi changelog'da belirtilir.

14. Yayımlama eşiği

Bir çalışma ancak şu koşullarda "benchmark" olarak adlandırılır:

• raw observations saklanmışsa,
• methodology version belliyse,
• test environment açıklanmışsa,
• sample size yeterince açıkça verilmişse,
• provider/scenario comparable ise,
• sonuç reproducible ise,
• limitations yayımlanmışsa.

Bunlar yoksa çalışma benchmark değil, exploratory measurement olarak etiketlenir.