Node.js temelde bozuk

Feb 15 2023
JavaScript neden sunucu taraflı geliştirme için pek uygun değil ve bu sorunları nasıl çözebiliriz?
Bu makale javascript'e saldırmakla ilgili değil. Yıllar boyunca tarayıcıda bize iyi hizmet etti ve bundan sonra da sunucuda bize yardımcı olmaya devam etti.

Bu makale javascript'e saldırmakla ilgili değil. Yıllar boyunca tarayıcıda bize iyi hizmet etti ve bundan sonra da sunucuda bize yardımcı olmaya devam etti. Javascript'in yaygın bilgisi göz önüne alındığında, birçok kişinin arka uçlarını uygularken ona erişmesi de anlaşılabilir.

İşlemci

Sunucudaki javascript ile ilgili en büyük kusur, tek iş parçacıklı olmasıdır. Bu, sunucunun sahip olduğu tüm çekirdekleri kullanmak için çalışmayı sorunsuz bir şekilde yayamayacağı anlamına gelir. Bir geliştirici olarak javascript'in daha fazla çekirdek kullanmasını sağlamak için bazı işleri manuel olarak çalışanlara taşımanız gerekecek, bunun diğer platformlar kadar verimli olmasını sağlamak neredeyse imkansız.

En sık kullanılan sonraki seçeneğiniz, uygulamanızın birden çok örneğini döndürmek ve bu şekilde işletim sisteminin çalışmanızı diğer örneklerin üzerinde çalıştığından farklı bir çekirdekte programlamasını sağlamaktır. Genel olarak, sisteminizde sahip olduğunuz çekirdek sayısı kadar örneği döndürürsünüz, bu şekilde en azından tüm CPU'nuzu kullanma şansınız olur.

Rust, Go veya .net'te çalışan web geliştiricilerinin bu konuda endişelenmesine gerek yok, çünkü seçilen zaman uyumsuz çalışma zamanı bunu onlar için halledecektir.

Hafıza

Farkında değilseniz sizi vurabilecek başka bir kusur, V8'in (düğüme güç veren javascript çalışma zamanı) 2 Gb/4 Gb yığın boyutuyla sınırlı olmasıdır (sürümler arasında farklılık gösterir). Makinenizde ne kadar ram olduğu önemli değil, bu yığın boyutu kullanımına ulaşırsanız, uygulamanız çökecek ve bu, çökme bellek sızıntısından değil de yüksek kullanımdan kaynaklanıyorsa yıkıcı olabilir. Buna karşı koymanın yolu, düğüm işleminizdeki maksimum eski alan boyutu ayarını sunucunuz için doğru olduğunu düşündüğünüz bir sınıra ayarlamaktır.

Rust, Go veya .net'te çalışan geliştiricilerin, bellek sınırını çökerten gizli bir uygulama olmadığı için bu konuda endişelenmesine gerek yok.

Verim

En hızlı tarayıcıyı elde etmek için yıllardır süren rekabet sayesinde, javascript performansının oldukça inanılmaz olabileceği bir noktaya geldik. Bununla birlikte, en yüksek performansta çalışması garanti edilmez. Görüyorsunuz, javascript'in iki sorunu var, önce hızlı bir "kaynaktan başlama" süresine sahip olması gerekiyor, ardından gerçek uygulama mantığını hızlı çalıştırabilmesi gerekiyor. Bu, çok adımlı bir derleme işlemine sahip olunarak çözülür; burada ilk geçiş, optimizasyonlara fazla zaman harcamadan kodu çalışır duruma getirir. Uygulama bir süre çalıştıktan sonra, V8 optimizasyonları uygulamak için zaman harcamaya değeceğini bilir ve optimizasyonları yapmak için optimizasyon derleyicisini görevlendirir.

Genellikle bu iyidir, bir süre sonra düğüm işleminiz başladıktan sonra optimize edilir ve sunucular tarihsel olarak uzun süredir devam eden işlemlerdir. Ancak sunucusuz çağın şu anki günlerinde işler farklı. Bazen kod, koddan yalnızca bir geçiş yapmak için başlar, bu, optimizasyonlarını uygulama şansı asla olmayacağından V8 motoru için en uygun değildir. Bununla birlikte, optimizasyonlarını yapsaydı daha da kötü olurdu, çünkü bu, yalnızca milisaniyeler sonra atılacak bir şeyi optimize etmek için çok fazla CPU döngüsü harcadığı anlamına gelir.

Bir Rust geliştiricisinin bu konuda endişelenmesine gerek yoktur, çünkü optimizasyon derleme zamanında gerçekleşir ve uygulama başladığında en yüksek performansta çalışır.

Umarım bunu bilgilendirici bulmuşsunuzdur, a her zaman takdir edilmektedir, teşekkürler!