# Araştırma, Ölçüm & Analiz Kayıtları

> Ölçüm, analiz, ekosistem taraması ve kaynak derlemesi kayıtları: hangi soruyu kovaladım, nasıl araştırdım, ne buldum ve sonuca ne kadar güveniyorum.

- Kayıt sayısı: 9
- Kaynak: https://www.muhammetsafak.com.tr/research/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
## Tüm programlar

- **Dil & çalışma zamanı** (3) — Sürüm yükseltmelerinin, derleyici ve çalışma zamanı ayarlarının aynı iş üzerindeki farkı: JIT, opcache, GC ve bellek davranışı. — https://www.muhammetsafak.com.tr/research/program/dil-runtime/
- **Veritabanı & sorgu** (3) — Index stratejisi, sorgu planı ve bağlantı yönetiminin gerçek veri hacmi altında ödettiği bedel; şema ve migration kararları dâhil. — https://www.muhammetsafak.com.tr/research/program/veritabani/
- **Servis & yük** (1) — Yük altında gecikme dağılımı, doyma noktası ve kuyruk davranışı — ortalama değil p95/p99; backpressure ve circuit breaker dâhil. — https://www.muhammetsafak.com.tr/research/program/servis-yuk/
- **Araç karşılaştırması** (1) — Aynı işi yapan iki aracın ölçülebilir farkı: derleme süresi, çıktı boyutu, bellek ve geliştirici döngüsü; ekosistem taraması dâhil. — https://www.muhammetsafak.com.tr/research/program/arac-karsilastirma/
- **Arayüz performansı** (1) — Gönderilen JS, ilk boya ve etkileşim gecikmesi: bir kolaylığın kullanıcıya kaç kilobayta mal olduğu; tarayıcı desteği dâhil. — https://www.muhammetsafak.com.tr/research/program/arayuz-performans/
- **Maliyet & kaynak** (0) — Bir kararın faturaya yansıyan tarafı: CPU-saat, bant genişliği, depolama ve istek başına gerçek maliyet. — https://www.muhammetsafak.com.tr/research/program/maliyet/

## Bulgu defteri

### Partial index on beş dakikada üç yüz seksen kat şişti — ve autovacuum bir kez bile gelmedi

- Tür: Ölçüm
- Soru: Sürekli churn altındaki bir kuyruk tablosunda partial index'in küçüklüğü kalıcı mı, ve varsayılan autovacuum ayarları ona yetişiyor mu?
- Bulgu: Canlı küme beş bin satırda sabit dururken partial index 0,1 MB'dan 38,2 MB'a çıktı — üç yüz seksen kat. Küçüklüğü canlı satır sayısından geliyor, şişme hızı iş hacminden, ve ikisi arasında hiçbir bağ yok. Composite index oransal olarak daha az şişti (%42) ama mutlak olarak daha çok (+126 MB) ve şişerken belleğe sığmayı bıraktı: gecikmesi 0,52 ms'den 61 saniyeye çıktı, kuyruğu 126 bine tırmandı. On beş dakikada 1,75 milyon ölü satır birikti ve autovacuum **bir kez bile koşmadı** — varsayılan eşik tablonun tamamına göre ölçekleniyor (50 + 0,2 × 10 milyon ≈ 2 milyon), churn ise küçük canlı kümede oluyor.
- Ölçüm tarihi: 2026-08-22
- Güven: Yüksek güven
- Program: veritabani
- Ham veri: https://github.com/muhammetsafak/pg-queue-bench/blob/main/results/2026-08-22/endurance-partial.jsonl
- https://www.muhammetsafak.com.tr/research/kuyruk-tablosunda-bloat-ve-autovacuum/
- Markdown: https://www.muhammetsafak.com.tr/research/kuyruk-tablosunda-bloat-ve-autovacuum.md

### Laravel'in preload eğrisi: 123 dosya, 1.912 dosyadan sekiz kat fazla kazandırıyor

- Tür: Ölçüm
- Soru: Laravel için elle seçilmiş bir preload nereye kadar iner, ve her dilim ne kadar açılış bedeline mal olur?
- Bulgu: Eğri hacimle orantılı değil. İlk 1.592 dosya (Laravel çekirdeği) 30 ms kazandırıyor ve açılışa 1,2 saniye ekliyor. Sonraki 1.094 Symfony dosyası 9,5 ms kazandırıyor, bedava. Ondan sonraki **123 dosya** (psr, carbon) 15,7 ms kazandırıyor — kendinden önceki 1.094 dosyadan fazla. Ve son 1.912 dosya yalnız 1,8 ms kazandırıp açılışa 1,2 saniye daha yazıyor. Yani önceki kaydın tavan olarak ölçtüğü "hepsini derle", eğrinin başlangıç noktası dışındaki en kötü fiyat/performans bölgesi: 2.809 dosyada durmak 12,77 ms ve 1.514 ms açılış verirken, 4.721 dosya 10,96 ms için 2.691 ms istiyor.
- Ölçüm tarihi: 2026-08-22
- Güven: Yüksek güven
- Program: dil-runtime
- Ham veri: https://github.com/muhammetsafak/php-framework-bench/blob/main/results/2026-08-22/preload-curate.json
- https://www.muhammetsafak.com.tr/research/laravel-preload-egrisi/
- Markdown: https://www.muhammetsafak.com.tr/research/laravel-preload-egrisi.md

### Partial index kuyruk tablosunu kırk bir kat küçültüyor — planner onu seçtiği sürece

- Tür: Ölçüm
- Soru: Milyonlarca ölü satır biriken bir Postgres kuyruk tablosunda partial index ne kazandırıyor, ve planner onu ne zaman seçmiyor?
- Bulgu: 10 milyon ölü satırda partial index saniyede 11.537 iş çıkarıyor, index'siz tablo 7. Composite index'le hız farkı küçük (%6,9) ama boyut farkı değil: 7,6 MB'a karşı 310,4 MB, ve partial tabloyla birlikte büyümüyor çünkü yalnız 5.000 canlı satırı indeksliyor. Asıl bulgu bunların hiçbiri: planner hazırlanmış bir deyimde generic plana geçtiği anda partial index tamamen devre dışı kalıyor — 11.752 tps 7'ye, 0,68 ms 1,1 saniyeye düşüyor. Bin altı yüz yetmiş üç kat. Aynı koşulda composite index etkilenmiyor.
- Ölçüm tarihi: 2026-08-22
- Güven: Yüksek güven
- Program: veritabani
- Ham veri: https://github.com/muhammetsafak/pg-queue-bench/blob/main/results/2026-08-22/queue.json
- https://www.muhammetsafak.com.tr/research/partial-index-kuyruk-tablosu/
- Markdown: https://www.muhammetsafak.com.tr/research/partial-index-kuyruk-tablosu.md

### Postgres partial index'i generic plana çevirmedi: kırk çalıştırma, kırk custom plan

- Tür: Ölçüm
- Soru: Hazırlanmış bir deyimde Postgres partial index'li sorguyu kendiliğinden generic plana çeviriyor mu — yoksa bin altı yüz yetmiş üç katlık uçuruma ancak elle mi düşülüyor?
- Bulgu: Postgres geçişi reddediyor. Partial index'te kırk çalıştırmanın kırkı da custom plan — sayaç 40/0. Reddetmesinin sebebi tam olarak felaketin kendisi: generic plan partial index'i kullanamaz, bu yüzden tahmini maliyeti yüksek çıkar ve planner onu seçmez. Composite index ise ders kitabındaki gibi altıncı çalıştırmada geçiyor (5/35) ve hiçbir şey kaybetmiyor. Yani bin altı yüz yetmiş üç katlık uçurum gerçek ama çitli: ona düşmek için `plan_cache_mode = force_generic_plan` yazmak gerekiyor.
- Ölçüm tarihi: 2026-08-22
- Güven: Yüksek güven
- Program: veritabani
- Ham veri: https://github.com/muhammetsafak/pg-queue-bench/blob/main/results/2026-08-22/plan-switch.json
- https://www.muhammetsafak.com.tr/research/planner-generic-plana-ne-zaman-geciyor/
- Markdown: https://www.muhammetsafak.com.tr/research/planner-generic-plana-ne-zaman-geciyor.md

### Chart.js'i nasıl import ettiğin, ziyaretçiye kaç kilobayt gönderdiğini belirliyor

- Tür: Ölçüm
- Soru: `chart.js/auto` ile seçmeli `Chart.register()` arasındaki fark, gerçek bir üretim derlemesinde kaç kilobayt?
- Bulgu: Seçmeli register, `chart.js/auto` yerine 9,7 kB gzip tasarruf ettiriyor (67,8 → 58,1 kB, %14,3). Asıl büyük düşüş kütüphanenin kendisinde değil, hiç kullanılmayan controller'ları dışarıda bırakmakta: yalnız çubuk grafiği kaydeden bir sayfa 46,0 kB'a iniyor — auto'nun üçte ikisi.
- Ölçüm tarihi: 2026-08-19
- Güven: Yüksek güven
- Program: arayuz-performans
- https://www.muhammetsafak.com.tr/research/chartjs-import-stratejisi/
- Markdown: https://www.muhammetsafak.com.tr/research/chartjs-import-stratejisi.md

### opcache preload deploy faturasını on dört kata kadar siliyor — ama yedi framework'ün beşi onu size vermiyor

- Tür: Ölçüm
- Soru: `opcache.preload` açıkken yedi PHP framework'ünün deploy sonrası ilk isteği ne kadar sürüyor, bu kazanç neye mal oluyor, ve kimler ona erişebiliyor?
- Bulgu: Preload, soğuk ilk isteği 3,5 ile 14,2 kat arasında kısaltıyor: Symfony 35,58 ms'den 2,50 ms'ye, yani Phalcon'un çıplak seviyesine iniyor. Ama yedi adayın yalnız ikisi (Symfony, CodeIgniter) resmî bir preload dosyası yayınlıyor; kalan beşinde kazanç masada duruyor ve kullanıcının kendi yazmasını bekliyor. Yazmak da göründüğü kadar kolay değil: classmap'ten körlemesine üretilen preload Symfony'yi hiç ayağa kaldırmıyor, CodeIgniter'da ise elle seçilmiş resmî dosyadan (3,13 ms) daha kötü sonuç veriyor (5,29 ms). Ve bedel kaybolmuyor: Laravel'in classmap preload'ı ziyaretçiden aldığı 62 ms'yi php-fpm'in ayağa kalkışına 2.340 ms olarak yazıyor.
- Ölçüm tarihi: 2026-08-22
- Güven: Yüksek güven
- Program: dil-runtime
- Ham veri: https://github.com/muhammetsafak/php-framework-bench/blob/main/results/2026-08-22/preload.json
- https://www.muhammetsafak.com.tr/research/opcache-preload-deploy-faturasi/
- Markdown: https://www.muhammetsafak.com.tr/research/opcache-preload-deploy-faturasi.md

### PHP ekosistemi yeni sürümü beklemiyor — ama desteklediğini de söylemiyor

- Tür: Tarama
- Soru: Bir PHP sürümü çıktıktan sonra en çok kurulan 500 Composer paketi onu desteklediğini ne zaman beyan ediyor, ve o beyan ne kadar bilgi taşıyor?
- Bulgu: Kurulumların %43,5'i üst sınırı hiç yazmayan bir kısıtla geliyor — `symfony/console` bugün `>=8.4.1` diyor, yani PHP 12'yi de desteklediğini iddia ediyor. Üst sınır yazan 280 paketin 247'si taahhüdünü sürüm daha doğmadan vermiş: `guzzlehttp/guzzle` 8.4'ü Ekim 2020'de, dört yıl önceden kapsamış. Geriye gerçekten bekleyen 33 paket kalıyor, medyanları 325 gün. Ham sayılar sürümden sürüme düşüp 'ekosistem hızlanıyor' diye okunuyor; eşit gözlem penceresinde bakınca trend tersine dönüyor (238 → 215 → 325 gün).
- Doğrulama tarihi: 2026-08-22
- Güven: Yüksek güven
- Program: dil-runtime
- Ham veri: https://github.com/muhammetsafak/packagist-php-support/blob/main/results/2026-08-22/php-support.json
- https://www.muhammetsafak.com.tr/research/php-surum-destegi-beyani/
- Markdown: https://www.muhammetsafak.com.tr/research/php-surum-destegi-beyani.md

### Bir PHP framework'ünü kurmanın sabit maliyeti: disk boyutu hiçbir şey söylemiyor

- Tür: Ölçüm
- Soru: Yedi PHP framework'ü kurulduğunda diskte kaç megabayt, istek başına kaç dosya ve ilk istekte kaç milisaniye tutuyor — ve bu sayılardan hangisi gerçekten yük altındaki hızı öngörüyor?
- Bulgu: Disk boyutu hiçbir şey öngörmüyor: Yii2 en büyük vendor'a sahip (34,1 MB) ama istek başına yalnız 62 dosya yüklüyor — sahanın en azlarından. İstek başına dosya sayısı da öngörmüyor: CodeIgniter 96 dosya yükleyip 6.431 istek/sn veriyor, Symfony 224 dosya yükleyip 13.067 veriyor. Gerçekten ayrışan tek şey opcache soğukken ödenen ilk istek: Phalcon 2,2 ms, Laravel 72,2 ms — otuz üç kat. Bu, her deploy'dan sonra ilk ziyaretçinin ödediği derleme faturasıdır ve framework başına birkaç kilobayt değil, onlarca milisaniye tutuyor.
- Ölçüm tarihi: 2026-08-20
- Güven: Yüksek güven
- Program: arac-karsilastirma
- Ham veri: https://github.com/muhammetsafak/php-framework-bench/blob/main/results/2026-08-20/static.json
- https://www.muhammetsafak.com.tr/research/php-framework-ayak-izi/
- Markdown: https://www.muhammetsafak.com.tr/research/php-framework-ayak-izi.md

### Yedi PHP framework'ü aynı yükte ölçtüm: fark, istek gerçek iş yaptıkça küçülüyor

- Tür: Ölçüm
- Soru: Aynı donanımda, aynı PHP sürümünde ve aynı yedi rotayla, Laravel, Symfony, CodeIgniter, Yii2, Phalcon, Laminas ve Slim saniyede kaç isteği ne gecikmeyle karşılıyor?
- Bulgu: Boş bir rotada en hızlı ile en yavaş arasında 4,4 kat var (Slim 25.975, Laravel 5.966 istek/sn). Ama istek gerçek iş yapmaya başlayınca fark kapanıyor: veritabanından tek satır çeken bir istekte 3,7 kata, yirmi satır çekende 3,5 kata iniyor. Phalcon boş rotada üçüncüyken veritabanı isteğinde beşinciye düşüyor — C eklentisi olmak, sorgu beklerken bir işe yaramıyor. Asıl pahalı olan şey framework seçimi değil: Laravel'in kendi varsayılan web middleware grubu, aynı yanıtı 5.858'den 2.176 istek/sn'ye düşürüyor — yani tek bir varsayılan, framework'ler arasındaki farkın çoğundan daha pahalı.
- Ölçüm tarihi: 2026-08-20
- Güven: Orta güven
- Program: servis-yuk
- Ham veri: https://github.com/muhammetsafak/php-framework-bench/tree/main/results/2026-08-20
- https://www.muhammetsafak.com.tr/research/php-framework-yuk-testi/
- Markdown: https://www.muhammetsafak.com.tr/research/php-framework-yuk-testi.md