---
title: "MetaSearch Benchmark Methodology: API Latency ve Reliability Standardı"
description: "Travel API benchmarklarında latency, timeout, error-rate, cache state, geography, sample size ve reproducibility için kullandığımız metodoloji."
slug: "benchmark-methodology"
translationKey: "report-benchmark-methodology"
locale: "tr"
type: "report"
category: "reports"
publisher: "metasearch.com.tr"
year: 2026
tags: ["benchmark","methodology","api-latency","reliability","reproducibility"]
publishedAt: "2026-09-26"
updatedAt: "2026-09-26"
reviewedAt: "2026-09-26"
technicalVerifiedAt: "2026-09-26"
sources:
  - title: "OpenTelemetry — HTTP semantic conventions"
    url: "https://opentelemetry.io/docs/specs/semconv/http/"
  - title: "RFC 9110 — HTTP Semantics"
    url: "https://www.rfc-editor.org/rfc/rfc9110.html"
---
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.