Temel sonuçlar
- Go dili her zaman hızlı değildir. Hatta bazı durumlarda JS runtime'ı daha hızlı olabilir.
- Go, sadelik ve verimlilikle öne çıksa da gerçek ortamlarda performansı beklenenden düşük kalabilir.
- Özellikle veritabanı I/O'sunun yoğun olduğu durumlarda Bun gibi JavaScript runtime'larına kıyasla performansı daha düşük olabilir.
Benchmark sonuçları
- Go daha yüksek istek işleme kapasitesi ve daha düşük bellek kullanımı gösterdi, ancak CPU kullanımı 2~3 kat daha yüksekti.
- Ancak DB I/O'sunun yoğun olduğu gerçek dünya ortamlarında Bun (
Elysia framework'ü ve MySQL2 kütüphanesi kombinasyonu) daha kararlı ve verimli bir performans gösterdi.
- Standart HTTP router'ın performansı düşüktü; Fiber framework'üne geçtikten sonra Bun'a yakın yanıt hızları elde edildi. (Go standart HTTP Router'ını kullanmayın!)
Bu benchmark'ı yaparken düşündüğüm Go'nun avantajları
- Çeşitli ilkel tipler ve tip güvenliği sunması.
- Tek binary ile dağıtım: basit bir çalıştırılabilir dosya olarak dağıtım mümkün, runtime bağımlılıklarını ortadan kaldırır.
- Goroutine'ler: paralel işlemeyi verimli şekilde destekler, doğru kullanıldığında donanım performansını en üst düzeye çıkarır.
Bu benchmark üzerinden hissedilen sınırlamalar ve iyileştirme alanları
- Şüphe duyulan MySQL driver performans sorunu: Go'nun
go-mysql-driver'ı kararlı ama yavaş ve JavaScript'in mysql2'sine göre performansı yetersiz görünüyor. (Elbette ben yanlış düşünüyor da olabilirim.)
- DB bağlantısı olmayan işlerde Go daha iyi performans gösteriyor. Belki de bu zaten oldukça doğal.
- HTTP router'ın düşük performansı: Ruh sağlığınız için Fiber ya da başka bir framework kullanın!
Performanstan memnun olunmasa da Go'yu kullanmayı sürdürme nedenleri
- Go'nun tip güvenliği, tek binary ile dağıtım ve goroutine'lerin paralel işleme performansı geliştirici olarak cazip geliyor. TypeScript ile doldurulamayan tipler ve
npm install gerektirmeyen tek binary dosya dağıtımı gerçekten çok büyük bir avantajdı.
- Ek performans optimizasyonu ihtimalini görerek Go'yu daha fazla öğrenip kullanmaya devam etmeye karar verildi.
Geliştiricilere mesaj
- Her dilin ve teknolojinin artıları ve eksileri vardır. Go dili için de bunun geçerli olduğu düşünülüyor.
- Go'nun performansına hayal kırıklığıyla bakmak yerine avantajlarını iyi kullanmak ve performans sınırlarını aşmanın yollarını aramayı sürdürmek faydalı olacaktır.
- Bu yazı, Go kullanan geliştiricilerle böyle bir analiz sonucunun da bulunduğu bilgisini paylaşmak için yazıldı.
16 yorum
Tamamen alakasız bir şey ama IBM Plex Sans KR fontu çok güzelmiş
Ben de o yazı tipini gerçekten çok beğenip kullandım, ama tam bir hayal kırıklığı yaratan tek nokta, düşük çözünürlüklü monitörlerde bakınca özellikle o kadar da güzel görünmemesi. haha, 5K monitörde bakınca gerçekten çok güzel görünüyordu!
Bir şeyi eleştirirken gerçekten çok dikkatli olmak gerektiğini düşünüyorum.
Bunun dil düzeyinde bir sorun mu, belirli bir kütüphane sorunu mu, yoksa koddaki bir sorun mu olduğu da belirsizken ve başkalarının yeniden üretebilmesi için yeterli bilgi de sunulmamışken, bir şeyin kötü olduğunu kamuya açık şekilde iddia etmek
Böyle bir niyetiniz olmasa bile, o ekosistemde yaşayan insanlar için hoş bir içerik gibi görünmüyor.
Merhaba! Öncelikle değerli görüşünüzü paylaştığınız için teşekkür ederim. Söyledikleriniz hakkında nasıl bir niyetle yorum yaptığınızı anlıyorum; eğer Go dilinin geleceğini ya da kullanıcılarını eleştirmişim gibi hissettirdiysem, durumun öyle olmadığını bir kez daha belirtip özür dilemek isterim. Ayrıca eğer sizin için uygunsa, yazının başlığına tıklarsanız çeşitli veriler ve ek olarak başka bir kişinin blog yazısı da bulunuyor; onları da okursanız (biraz uzun olsa da) niyetimi daha net anlayabileceğinizi düşünüyorum.
Ben dillerin bir bakıma otomobillere benzediğini düşünüyorum. Her aracın çeşitli artıları ve eksileri var, satın alma maliyetleri birbirinden farklı ve aynı işi yapıyor gibi görünseler de farklı değerleri hedefliyorlar; bu yönleriyle benzediklerini düşünüyorum. Elbette belli bir aracı özel olarak sevip ona değer vermek de çok doğal. Ben de kendi arabamı seviyor ve üreticisine güveniyorum.
Buna rağmen benim de kendi arabamla ilgili eksik bulduğum ya da memnun olmadığım noktalar var ve araç modellerini düzenli olarak inceleyen yorumcular da bunları her zaman rakip modellerle birlikte birçok açıdan karşılaştırarak paylaşıyor. Birisi benim arabam için vites kutusu performansının kötü olduğunu ya da yakıt tüketiminin yüksek olduğunu söylerse, açıkçası benim de pek hoşuma gitmez; ama yine de sürücü olarak kendimle arabayı ayrı değerlendirmeye çalışırım. Ayrıca kullandığım arabanın gerek güçlü gerek zayıf yönleri hakkında daha fazla şey öğrenmeye de çalışırım. Belki bir gün başka bir arabaya da binebilirim; ama şu anki sürüş deneyimim o zaman da bana yardımcı olacaktır.
Özet sürümde bundan çok bahsedemedim ama blog yazısının asıl metnini, Go'nun eksik bulduğum yönlerine rağmen avantajlarının hâlâ daha fazla olduğu ve bu yüzden kullanmaya devam etmeyi (= sürmeye devam etmeyi) düşündüğüm şeklinde bitirdim. Bence her dilin hedeflediği değerler ve güçlü yanları farklı; bu yüzden elimden geldiğince çeşitli dilleri (= araçları) kullanmaya çalışıyorum. İyi kullandığım JS runtime'ını bırakıp özellikle Go diline geçmek istememin nedeni de bu.
Gereksiz dil tartışmaları çıkmaması için elimden geldiğince dikkatli yazdığımı düşünüyordum; ama buna rağmen bu yazıyı okuyup rahatsız olan Gopher'lar varsa, bir kez daha anlayış göstermenizi rica ediyorum. Ve bir zamanlar çokça eleştirilen PHP dilini de seven romantik bir kod yazarı olduğumu belirterek yorumumu burada bitireyim!
Orijinal metinde yavaş kısımlara dair yazarın kendince yaptığı analizler ve buna rağmen neden yine de Go kullanacağını anlattığı gerekçeler yer alıyor; bu yazıyı hangi nedenle değer yargısı olarak algıladığınızı doğrusu pek anlayamıyorum.
TMI sayılır ama Go’nun std kütüphanesinin performansı zaman geçtikçe düşüyor. Bunun başlıca nedeni, RFC standartlarına uyum sağlamak için çeşitli özellikler eklenirken raporlanan çok sayıdaki güvenlik açığına karşı yapılan trade-off’lar.
Son dönemde FIPS sertifikasyonunu geçmek için performans kaybının muhtemelen biraz daha artacağı bir durum bekleniyor.
Tüm bu arka planı tamamen dışarıda bırakıp, en basit belirli bir senaryo için performansın kötü olduğunu tek cümleyle yazmak, birçok kişide yanlış anlaşılma yaratmaya fazlasıyla yeterli görünüyor ;_;
tsboard'un 1.0 sürümünü bekliyorum haha
Beklediğiniz için teşekkür ederim! Neşeyle çalışmaya devam edeceğim haha
JS JIT kullandığı için, özellikle yavaş olması için bir neden yok gibi görünüyor.
Çoklu iş parçacığı, kararlılık vb. dışında..
Bu benchmark sayesinde benim de yeni fark ettiğim(?) bir şey oldu; kararlılık da ciddi bir sorun sayılmayacak düzeyde olduğu için bunu rahatlıkla söyleyebileceğimi düşünüyorum. Multithreading ise kesinlikle orkestrasyon gerektirdiğinden (buna böyle demek doğru mu emin değilim) biraz uğraştırıcı, bu da bir gerçek.
Siteye erişilemiyor; bu sorun sadece bende mi var?
Merhaba! Yorumla haber verdiğiniz için teşekkürler hehe Siteyi henüz hostinge taşıyamadığım için zaman zaman erişim sorunları olabiliyor! Mümkün olduğunca kısa sürede gerekli düzenlemeyi yapacağım. (Şu anda evdeki mini PC tam gaz çalışıyor 😂)
Aa, şimdi oluyor. Zevkle okuyacağım!
Siteyi evdeki mini PC'den tek odalı ev büyüklüğünde bir sanal sunucuya taşıdım...! Bugün beklenmedik şekilde çok sayıda kişi geldi ve geri dönmek zorunda kaldı, ancak artık bir sorun olmadığını bildirmek isterim!
github.com/jackc/pgx/v5sürücüsü ve PostgreSQL ile denendiğinde farklı bir sonuç çıkıp çıkmayacağını merak ediyorum.Ben de bunun yalnızca MySQL’e özgü bir sorun mu, yoksa veritabanı kullanılan tüm senaryolar için mi geçerli olduğunu merak ediyorum. Sanırım bir gün başkaları da sonuçları paylaşacaktır :)