PHP ile Go'yu aynı OAuth2 API'de ölçtüm: 10.000 yazmada fark yok, 50.000 okumada var

“Go’ya geçersek kaç sunucu kazanırız?” sorusuna genellikle “Go daha hızlı” cevabı veriliyor. Bu cevapla kapasite tablosu doldurulamıyor. Bu kayıtta aynı OAuth2 korumalı API’yi PHP-FPM, FrankenPHP worker ve Go ile üç kez yazdım. Üçünü aynı dört çekirdekte, aynı PostgreSQL’e karşı ölçtüm ve farkı kendi hedefinize göre çekirdeğe çevirebileceğiniz bir sayıya indirdim: istek başına CPU. Ham koşuların hepsi php-go-bench deposunda duruyor.

Ne ölçtüm

Üç uç nokta, üç adayda da birebir aynı sözleşmeyle çalışıyor. Hepsi önce bearer token’ı doğruluyor: RS256 imzası, iss, aud, exp, nbf ve uç noktaya göre scope. Doğrulama hiçbir adayda önbelleğe alınmıyor.

Senaryo	İstek	Doğrulamadan sonra ne oluyor	Hedef hız
Doğrulama	GET /auth	hiçbir şey — veritabanı yok	50.000/sn
Okuma	GET /events/{id}	1.000.000 satırlık tablodan birincil anahtarla tek satır	50.000/sn
Yazma	POST /events	JSON gövde doğrulaması, tek INSERT … RETURNING	10.000/sn

Framework yok. İki PHP adayı aynı Api.php sınıfını çalıştırıyor, yalnız giriş dosyaları farklı. Her aday, süreç ya da istek ömrünün izin verdiği en hızlı veritabanı idiom’unu kullanıyor:

• Go: pgx, prepared statement’ları bağlantı başına önbelleğe alıyor.
• FrankenPHP worker: statement’ı bir kez hazırlayıp tekrar kullanıyor.
• php-fpm: bir isteğin ömrü statement tutmaya yetmediği için sorguyu tek gidiş-dönüşlük parametreli çağrıyla gönderiyor.

Hedef hızda: 10.000 yazma herkes için kolay, 50.000 okuma değil

Etkileşimli grafiği aç

Tooltip ve imleç okuması için ~60 kB JavaScript iner. Aşağıdaki veri tablosu her hâlde açık.

Veri tablosu

5 tekrarın medyanı, open loop, 256 bağlantı, 60 sn — bench/report.mjs

Seri	Yalnız doğrulama	Doğrulama + okuma	Doğrulama + yazma
Hedef	50.000	50.000	10.000
Go	49.999	49.999	10.000
FrankenPHP (worker)	33.089	22.859	10.000
PHP-FPM	30.606	23.528	10.000

Grafik tarayıcıda çizilir; aşağıdaki tablo aynı veriyi taşır.

Saniyede 10.000 yazmada üç aday da hedefi beş tekrarın beşinde tutturdu. Üç adayın p99 değerleri yan yana: FrankenPHP 1,81 ms, PHP-FPM 1,88 ms, Go 2,50 ms. Bu yükte en düşük p99 bir PHP adayından geldi; Go ile aradaki fark da bir milisaniyenin altında. Bu hedefte dil, kapasite tablonuzda bir satır bile değil.

Hedef 50.000 okumaya çıkınca tablo değişiyor. Go beş tekrarın beşinde 50.000’i p99 6,45 ms ile tutturdu. PHP-FPM 23.528’de kaldı ve dört çekirdeğin 3,9’unu kullandı. FrankenPHP 22.859’da kaldı ama 2,7 çekirdekle; bu farka aşağıda döneceğim. Open loop ölçümde tutturulamayan istek kuyrukta bekliyor. Bu yüzden iki PHP adayının doğrulama ve okumadaki gecikmesi (p99 20–32 saniye) bir servis gecikmesi değil; yalnız “bu hedef bu bütçeyle karşılanamaz” anlamına geliyor.

Farkı belirleyen: istek başına CPU

Etkileşimli grafiği aç

Tooltip ve imleç okuması için ~60 kB JavaScript iner. Aşağıdaki veri tablosu her hâlde açık.

Veri tablosu

Sabit hız fazı, 5 tekrarın medyanı

Seri	Yalnız doğrulama	Doğrulama + okuma	Doğrulama + yazma
Go	47 µs	64 µs	96 µs
FrankenPHP (worker)	88 µs	117 µs	146 µs
PHP-FPM	130 µs	168 µs	207 µs

Grafik tarayıcıda çizilir; aşağıdaki tablo aynı veriyi taşır.

Bu sayı hedef hızla çarpıldığında gereken çekirdeği veriyor. Adayın hedefi tutturduğu her ölçümde hesap, sayacın gösterdiği çekirdekle örtüşüyor. Go’da okuma için hesap 50.000 × 64 µs = 3,2 çekirdek, sayaç 3,20. PHP-FPM’de yazma için hesap 10.000 × 207 µs = 2,07 çekirdek, sayaç da 2,07.

50.000 okuma için iki farklı hesap yapılabiliyor ve iki PHP adayı bu iki hesapta farklı yere düşüyor:

50.000 okuma/sn	CPU zamanı hesabı	Go'ya oranı	Instance hesabı	Go'ya oranı
Go	3,2 çekirdek (ölçüldü)	1,0×	3,4 çekirdek	1,0×
FrankenPHP (worker)	5,8 çekirdek	1,8×	8,8 çekirdek	2,6×
PHP-FPM	8,4 çekirdek	2,6×	8,2 çekirdek	2,4×

PHP-FPM’de iki hesap aynı yere çıkıyor, çünkü PHP-FPM dört çekirdeğin tamamını kullanıyor. FrankenPHP’de ise çıkmıyor.

CPU nereye gidiyor: dörtte üçü token’a

Doğrulama senaryosu veritabanına hiç gitmiyor, bu yüzden bir okuma isteğinin CPU’sunun ne kadarının OAuth2’ye gittiğini ayırmayı sağlıyor. Üç adayda da oran aynı bantta: token doğrulaması, okuma isteğinin uygulama CPU’sunun Go’da %73’ünü, FrankenPHP’de %75’ini, PHP-FPM’de %77’sini oluşturuyor. Oran yaklaşık, çünkü doğrulama yanıtı okuma yanıtından küçük; yine de kapasite açısından sonuç net. Bu API’de satırı okumak değil, RS256 imzasını doğrulamak pahalı. Dillerin arasındaki farkın büyük kısmı da imza doğrulamanın kendisinden geliyor: Go 47 µs, PHP-FPM 130 µs.

Veritabanının tarafı ayrı bir satır. Aynı sorgu için PostgreSQL’in harcadığı CPU’yu istek başına böldüğümde üç aday iki gruba ayrıldı:

PostgreSQL CPU / istek	Okuma	Yazma
Go	34 µs	48 µs
FrankenPHP (worker)	35 µs	51 µs
PHP-FPM	53 µs	81 µs

Statement’ı tekrar kullanan iki aday (Go ve FrankenPHP) birbirine çok yakın. Kullanamayan PHP-FPM ise veritabanına istek başına Go’ya göre okumada %56, yazmada %69 daha fazla iş yaptırıyor. Muhtemel sebep, her sorgunun her seferinde yeniden ayrıştırılıp planlanması; bu kayıt bunu ayrıca ölçmedi. Kapasite tablosunda bunun anlamı şu: PHP-FPM’den Go’ya geçiş, uygulama çekirdeklerinin yanında veritabanı çekirdeğini de azaltıyor. FrankenPHP’ye geçiş de aynı kazancın veritabanı tarafını büyük ölçüde sağlıyor.

FrankenPHP’nin tasarrufu kapasiteye dönmüyor

Worker modu PHP’nin istek başına CPU’sunu üç senaryoda da PHP-FPM’e göre üçte bir civarında düşürüyor (okumada 168’den 117 µs’ye). Tavan ise neredeyse kıpırdamıyor:

Etkileşimli grafiği aç

Tooltip ve imleç okuması için ~60 kB JavaScript iner. Aşağıdaki veri tablosu her hâlde açık.

Veri tablosu

16/64/128/256 bağlantılık süpürmenin en iyi hücresi, 3 tekrarın en iyisi, 15 sn

Seri	Yalnız doğrulama	Doğrulama + okuma	Doğrulama + yazma
Go	83.526	59.004	43.942
FrankenPHP (worker)	32.953	22.613	22.874
PHP-FPM	31.157	24.437	21.857

Grafik tarayıcıda çizilir; aşağıdaki tablo aynı veriyi taşır.

FrankenPHP doygunken bile dört çekirdeğin ancak 2,2 ile 2,9’unu kullanıyor; PHP-FPM aynı koşularda 3,3 ile 4,0 arasında. Yani darboğaz CPU değil, başka bir yerde: 32 worker’lık havuzda, Caddy ile PHP thread’leri arasındaki geçişte ya da ZTS derlemesinde olabilir. Bu kayıt darboğazın nerede olduğunu ölçmedi. Pratik sonuç şu: FrankenPHP’ye geçmek aynı işi daha az CPU zamanıyla yapıyor, ama bu bütçede aynı instance’tan daha fazla istek almıyor.

Bellek tarafında sıralama başka:

Aday	Tepe RSS	Not
Go	~27 MiB	tek süreç, 32 bağlantılık havuz
PHP-FPM	~63 MiB	32 worker + 2 nginx worker
FrankenPHP (worker)	~137 MiB	32 worker thread ve Caddy, tek süreç

Nasıl ölçtüğüm

• Bütçe. Docker VM’inin 12 vCPU’su ayrık üç kümeye bölündü: aday 0-3, PostgreSQL 4-7, yük üreteci 8-11. php-fpm’in nginx’i de adayın dört çekirdeğinin içinde; Go ve FrankenPHP HTTP’yi kendileri karşılıyor.
• Her blok aynı yerden başlıyor. Tablo CREATE DATABASE … TEMPLATE ile birebir kopyalanıyor ve pg_prewarm ile önbelleğe çekiliyor. Ardından CHECKPOINT alınıyor, taze aday konteyneri açılıyor ve her senaryo 5 saniye ısıtılıyor. Tabloyu değiştiren tek senaryo yazma olduğu için hep sonda koşuyor.
• Referans ölçümü. Her bloktan önce, uygulama kodu çalıştırmayan bir nginx adayın çekirdeklerine konup saniyede 50.000 istekle sınandı. Yük üreteci bu hızı bile tutturamasaydı hiçbir aday tutturamazdı. En düşük değer 49.980/sn oldu.
• İki tahminci. Sabit hız fazında hedef sabit olduğu için tekrarların medyanı raporlandı. Tavan fazında makine sakinleştirilemediği ve girişim throughput’u yalnız aşağı çekebildiği için en iyi tekrar raporlandı. İki faz birbirini doğruluyor: PHP-FPM doğrulamada tavanda 31.157, sabit hızın medyanında 30.606 verdi; FrankenPHP 32.953 ve 33.089.

Sınırlar ve dürüstlük notları

1. Tek makine, dizüstü. Aday, veritabanı ve yük üreteci ayrı çekirdeklerde ama tek bir VM’de ve tek bir Linux kernel’inde koşuyor; ağ Docker bridge’i, gerçek bir kablo değil. 12 vCPU’nun performans çekirdeğine ya da verimlilik çekirdeğine denk gelmesini macOS belirliyor.
2. Yazma tavanı gürültülü. Go’nun yazma tavanı tekrarlar arasında 9.649 ile 43.942 arasında gezdi. O koşularda ne aday ne veritabanı CPU’da doymuştu; sınır büyük olasılıkla VM diskindeki WAL yazımı, ama bu kayıt onu doğrudan ölçmedi. Bu yüzden yazma tavanını karşılaştırma için değil, bağlam için okuyun. Sabit 10.000 yazma sonuçları bu gürültüden etkilenmiyor: 15 koşunun 15’i hedefi tuttu.
3. Disk garantisi doğrulanmadı. Docker Desktop VM diskindeki fsync’in çıplak donanımla aynı garantiyi verip vermediğini kontrol etmedim. Mutlak yazma rakamları iyimser olabilir; üç adayın karşılaştırması etkilenmiyor, çünkü üçü aynı veritabanına yazıyor.
4. Tek token. Her istekte aynı token gönderildi. Adaylar doğrulamayı önbelleğe almıyor, ama gerçek bir resource server farklı token’lar görür.
5. Bir blok yeniden ölçüldü. Tavan fazında FrankenPHP’nin 3. tekrarı sürerken makine uykuya geçti. Blok baştan ölçüldü. Kesilen bloğun ham dosyaları kenara alınamadı ve yeniden ölçüm aynı adlarla onların üzerine yazdı. Bunun nasıl olduğu EXCLUDED.md dosyasında yazıyor.
6. Kapsam dışı. Framework’ler, Swoole ile RoadRunner, JIT, token üreten authorization server ve kodu Go’ya taşımanın ekip maliyeti ölçülmedi. Framework’lerin kendi maliyeti PHP framework yük testi kaydında.

Kendi sayınızı üretmek için php-go-bench deposunu kendi token biçiminiz ve kendi sorgunuzla, kendi donanımınızda koşturun. Tablonuza yazacağınız değer istek başına CPU; gerisi çarpma.