- JavaScript ve Node.js ortamında bir doğrulama kütüphanesi olan Joi, diğer kütüphanelere kıyasla daha yavaş performans gösteriyor
- Joi başka bir kütüphaneyle değiştirilirse backend ortamında performans artışı beklenebilir
- Backend uygulamalarında anlamlı bir performans farkı ortaya çıkıp çıkmayacağını test etme
- Testler k6 kullanılarak yürütülüyor; lodash ve class-transformer da birlikte test ediliyor
- Performans testi sonuçları:
- native vs lodash: performans farkı yok
- object literal vs class-transformer: performans farkı yok
- non-validation vs Joi: Joi'nin yavaş performansına rağmen performans farkı ortaya çıkmıyor
- Performans önemlidir, ancak hâlihazırda ilerleyen bir projede değişiklik yapıldığında harcanan zamana kıyasla hissedilir bir performans farkı elde edilemeyebilir
8 yorum
Bence yazarın amacı darboğaz durumunu iyileştirmekten ziyade, gerçek duruma benzer ortamlarda doğrulama kütüphaneleri arasındaki performans farkının çok anlamlı olmadığını savunmak olabilir.
Makaledeki gibi yalnızca io bound task içeren bir servis değil de cpu bound task servisi olduğunu varsayarsak ne olur?
Gerçek ortamdaki servisler düşünüldüğünden daha karmaşıktır. Sunucu, yalnızca UI'ı çizmek için gereken veriyi sunan bir API'den ibaret değildir.
Validation ve JSON serialization işlemleri ana iş parçacığında gerçekleşen işlemler olduğu için, hafife alınacak bir konu değil. TS backend tarafında en yaygın kullanılanlar
class-validator/class-transformer. Ve bunların saniyede doğrulayabildiği veri miktarı yaklaşık 4MB; yani ana iş parçacığında saniyede 4MB’tan fazlasını işleyemeyeceğiniz anlamına geliyor.DB girdi/çıktısı ana değil arka plan iş parçacıklarında çalıştığı için, backend sunucusu açısından (TS sunucusu açısından) eşzamanlı bağlantı sayısını büyük ölçüde etkilemez. Hizmetin yapısına göre tek seferde aktarılan DTO miktarı büyükse, yavaş validation daha da korkutucu olabilir (gerçekten de işlem başına veri miktarı büyük bir servis geliştirildiğinde, NestJS’in eşzamanlı bağlantı sayısının tek hanelerde kaldığı bir örnek de vardı).
Katılıyorum; yazarın iddia ettiği gibi bunu "gerçek dünyadaki durumlar" diye varsaymak için, örnek olarak verilen gerçek durum fazlasıyla dar kapsamlı.
Yukarıda söylenenlere katılıyorum; DB giriş/çıkışının neden dahil edildiğini anlaması zor bir benchmark. Ayrıca yavaş validation ve serialization, request DTO’dan çok response DTO’da sunucu performansına daha fazla zarar verir. Son olarak, böyle benchmark deneyleri yapılırken tek bir DTO ile değil, çeşitli türlerde DTO’larla deney yapılması gerekir.
Gerçekte DB I/O olmadığında ve farklı yapılardaki DTO’lar test edildiğinde sonuçlar farklılık gösterir.
Bence baştan beri darboğaz veritabanı bağlantısı tarafında gibi görünüyor; konu yanlış seçilmiş olabilir mi diye düşünüyorum.
Sanki performans artışı yokken varmış gibi sunulmuş gibi görünüyor; ama aslında en başta darboğaz veritabanı tarafındayken, darboğaz olmayan noktaları iyileştirmeye odaklanarak yazılması yanlış anlaşılmaya yol açacak gibi.
Çoğu ortamda performans iyileştirmesi, darboğaz noktalarını gidermek anlamına gelir; doğrulamayı optimize ederken de bunun, doğrulama tarafının darboğaz olduğu tespit edildikten sonra yapılması gerekir.