<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Muhammet Şafak — Research — Araştırmalar</title><description>Ö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.</description><link>https://www.muhammetsafak.com.tr/</link><language>tr-TR</language><lastBuildDate>Wed, 16 Sep 2026 00:00:00 GMT</lastBuildDate><managingEditor>info@muhammetsafak.com.tr (Muhammet Şafak)</managingEditor><atom:link href="https://www.muhammetsafak.com.tr/research/rss.xml" rel="self" type="application/rss+xml"/><item><title>PHP ile Go&apos;yu aynı OAuth2 API&apos;de ölçtüm: 10.000 yazmada fark yok, 50.000 okumada var</title><link>https://www.muhammetsafak.com.tr/research/php-go-oauth2-postgres-yuk-testi/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/php-go-oauth2-postgres-yuk-testi/</guid><description>Saniyede 10.000 yazmada üç aday da hedefi beş tekrarın beşinde tutturdu, p99 üçünde de 2,5 ms&apos;yi aşmadı: bu yükte dil bir kapasite kalemi değil. Saniyede 50.000 okumayı dört çekirdekte yalnız Go tutturdu (p99 6,45 ms); PHP-FPM 23.528&apos;de, FrankenPHP 22.859&apos;da kaldı. İstek başına CPU okumada Go&apos;da 64, FrankenPHP&apos;de 117, PHP-FPM&apos;de 168 mikrosaniye. 50.000 okuma için instance hesabı Go&apos;ya 3,4, iki PHP adayına 8,2–8,8 çekirdek yazdırıyor. FrankenPHP&apos;nin CPU tasarrufu kapasiteye dönmüyor: doygunken dört çekirdeğin birini boşta bırakıyor.</description><pubDate>Wed, 16 Sep 2026 00:00:00 GMT</pubDate><category>servis-yuk</category><category>php</category><category>go</category><category>benchmark</category><category>oauth2</category><category>postgresql</category><category>frankenphp</category><category>php-fpm</category></item><item><title>Partial index on beş dakikada üç yüz beş kat şişti — ve autovacuum bir kez bile gelmedi</title><link>https://www.muhammetsafak.com.tr/research/kuyruk-tablosunda-bloat-ve-autovacuum/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/kuyruk-tablosunda-bloat-ve-autovacuum/</guid><description>Canlı küme beş bin satırda sabit dururken partial index 0,125 MB&apos;dan 38,2 MB&apos;a çıktı — üç yüz beş 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&apos;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.</description><pubDate>Sun, 23 Aug 2026 00:00:00 GMT</pubDate><category>veritabani</category><category>postgresql</category><category>index</category><category>kuyruk</category><category>autovacuum</category><category>bloat</category><category>performans</category></item><item><title>Laravel&apos;in preload eğrisi: 123 dosya, 1.912 dosyadan sekiz kat fazla kazandırıyor</title><link>https://www.muhammetsafak.com.tr/research/laravel-preload-egrisi/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/laravel-preload-egrisi/</guid><description>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üğü &quot;hepsini derle&quot;, 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.</description><pubDate>Sun, 23 Aug 2026 00:00:00 GMT</pubDate><category>dil-runtime</category><category>php</category><category>opcache</category><category>preload</category><category>laravel</category><category>deploy</category></item><item><title>Partial index kuyruk tablosunu kırk bir kat küçültüyor — planner onu seçtiği sürece</title><link>https://www.muhammetsafak.com.tr/research/partial-index-kuyruk-tablosu/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/partial-index-kuyruk-tablosu/</guid><description>10 milyon ölü satırda partial index saniyede 11.537 iş çıkarıyor, index&apos;siz tablo 7. Composite index&apos;le hız farkı küçük (%6,9) ama boyut farkı değil: 7,6 MB&apos;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&apos;ye, 0,68 ms 1,1 saniyeye düşüyor. Bin altı yüz otuz beş kat. Aynı koşulda composite index etkilenmiyor.</description><pubDate>Sun, 23 Aug 2026 00:00:00 GMT</pubDate><category>veritabani</category><category>postgresql</category><category>index</category><category>kuyruk</category><category>skip-locked</category><category>outbox</category><category>performans</category></item><item><title>Postgres partial index&apos;i generic plana çevirmedi: kırk çalıştırma, kırk custom plan</title><link>https://www.muhammetsafak.com.tr/research/planner-generic-plana-ne-zaman-geciyor/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/planner-generic-plana-ne-zaman-geciyor/</guid><description>Postgres geçişi reddediyor. Partial index&apos;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&apos;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 otuz beş katlık uçurum gerçek ama çitli: ona düşmek için `plan_cache_mode = force_generic_plan` yazmak gerekiyor.</description><pubDate>Sun, 23 Aug 2026 00:00:00 GMT</pubDate><category>veritabani</category><category>postgresql</category><category>index</category><category>kuyruk</category><category>planner</category><category>prepared-statement</category></item><item><title>Chart.js&apos;i nasıl import ettiğin, ziyaretçiye kaç kilobayt gönderdiğini belirliyor</title><link>https://www.muhammetsafak.com.tr/research/chartjs-import-stratejisi/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/chartjs-import-stratejisi/</guid><description>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&apos;ları dışarıda bırakmakta: yalnız çubuk grafiği kaydeden bir sayfa 46,0 kB&apos;a iniyor — auto&apos;nun üçte ikisi.</description><pubDate>Sat, 22 Aug 2026 00:00:00 GMT</pubDate><category>arayuz-performans</category><category>bundle-size</category><category>chart-js</category><category>astro</category><category>preact</category></item><item><title>opcache preload deploy faturasını on dört kata kadar siliyor — ama yedi framework&apos;ün beşi onu size vermiyor</title><link>https://www.muhammetsafak.com.tr/research/opcache-preload-deploy-faturasi/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/opcache-preload-deploy-faturasi/</guid><description>Preload, soğuk ilk isteği 3,5 ile 14,2 kat arasında kısaltıyor: Symfony 35,58 ms&apos;den 2,50 ms&apos;ye, yani Phalcon&apos;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&apos;ten körlemesine üretilen preload Symfony&apos;yi hiç ayağa kaldırmıyor, CodeIgniter&apos;da ise elle seçilmiş resmî dosyadan (3,13 ms) daha kötü sonuç veriyor (5,29 ms). Ve bedel kaybolmuyor: Laravel&apos;in classmap preload&apos;ı ziyaretçiden aldığı 62 ms&apos;yi php-fpm&apos;in ayağa kalkışına 2.340 ms olarak yazıyor.</description><pubDate>Sat, 22 Aug 2026 00:00:00 GMT</pubDate><category>dil-runtime</category><category>php</category><category>opcache</category><category>preload</category><category>deploy</category><category>framework</category></item><item><title>PHP ekosistemi yeni sürümü beklemiyor — ama desteklediğini de söylemiyor</title><link>https://www.muhammetsafak.com.tr/research/php-surum-destegi-beyani/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/php-surum-destegi-beyani/</guid><description>Kurulumların %43,5&apos;i üst sınırı hiç yazmayan bir kısıtla geliyor — `symfony/console` bugün `&gt;=8.4.1` diyor, yani PHP 12&apos;yi de desteklediğini iddia ediyor. Üst sınır yazan 280 paketin 247&apos;si taahhüdünü sürüm daha doğmadan vermiş: `guzzlehttp/guzzle` 8.4&apos;ü Ekim 2020&apos;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 &apos;ekosistem hızlanıyor&apos; diye okunuyor; eşit gözlem penceresinde bakınca trend tersine dönüyor (238 → 215 → 325 gün).</description><pubDate>Sat, 22 Aug 2026 00:00:00 GMT</pubDate><category>dil-runtime</category><category>php</category><category>ekosistem</category><category>composer</category><category>surum-yukseltme</category><category>bagimlilik</category></item><item><title>Bir PHP framework&apos;ünü kurmanın sabit maliyeti: disk boyutu hiçbir şey söylemiyor</title><link>https://www.muhammetsafak.com.tr/research/php-framework-ayak-izi/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/php-framework-ayak-izi/</guid><description>Disk boyutu hiçbir şey öngörmüyor: Yii2 en büyük vendor&apos;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&apos;dan sonra ilk ziyaretçinin ödediği derleme faturasıdır ve framework başına birkaç kilobayt değil, onlarca milisaniye tutuyor.</description><pubDate>Thu, 20 Aug 2026 00:00:00 GMT</pubDate><category>arac-karsilastirma</category><category>php</category><category>framework</category><category>opcache</category><category>composer</category><category>bagimlilik</category></item><item><title>Yedi PHP framework&apos;ü aynı yükte ölçtüm: fark, istek gerçek iş yaptıkça küçülüyor</title><link>https://www.muhammetsafak.com.tr/research/php-framework-yuk-testi/</link><guid isPermaLink="true">https://www.muhammetsafak.com.tr/research/php-framework-yuk-testi/</guid><description>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&apos;in kendi varsayılan web middleware grubu, aynı yanıtı 5.858&apos;den 2.176 istek/sn&apos;ye düşürüyor — yani tek bir varsayılan, framework&apos;ler arasındaki farkın çoğundan daha pahalı.</description><pubDate>Thu, 20 Aug 2026 00:00:00 GMT</pubDate><category>servis-yuk</category><category>php</category><category>benchmark</category><category>framework</category><category>php-fpm</category><category>docker</category></item></channel></rss>