Nginx neden bu kadar hızlı?


31

Rambler gibi bir site dinamik içeriği nasıl bu kadar hızlı sunar? Yahoo'dan bile daha hızlı (ki benim ülkemde bir sunucu var - Güneydoğu Asya; rambler yok).

Bu tamamen Nginx'in yeteneği mi? Bu yetenekler hakkında nereden bilgi edinebilirim?

Burada hemen hemen yeni başlayanlar, Nginx'ten sunulan serverfault.com adresinin IIS 7'nin çok daha hızlı olacağına inanıyorum (db erişim zamanının her iki durumda da aynı olduğunu varsayarak). Bu adil bir varsayım mı?

Düzenle:

IIS7'nin önünde Nginx kullanarak Karl'dan mesaj gönderin


Serverfault.com adresinin zaten Nginx kullandığını unutmayın ( Wappalyzer’e göre ). : P
Will

Yanıtlar:


26

Bu sunumu nginx internals'ına genel bakış için görebilirsiniz . Başlıca fark, Apache'nin yaptığı gibi iş parçacığı kullanmak yerine isteklerin zaman uyumsuz işlenmesidir. Bu belgelere de bir göz atabilirsiniz.


2
Nginx'in mimarisine ve C10K problemine iyi cevap. Bununla birlikte, OP'lerin sorusunu nginx ile pek ilgisi olmayan algılanan sayfa yükleme hızı ile ilgili olarak anlıyorum.
Jesper M

"Eşzamansız" aslında ne anlama geliyor? Her zaman ayrı bir iş parçacığı içinde yürütülen anlamına gelir düşünüyorum.
Ivan,

Eşzamansız ortalama Nginx her zaman bir vekil olarak davranır, hatta Php: Nginx HTTP isteğini alırsa, Php sunucusuna gönderir, BUT HTTP yanıtını göndermek için kilitlemez / beklemez. Bu yüzden yüksek trafikli web siteleri için (hız, CPU / RAM) bir fark görüyorsunuz. Ancak birkaç istek için performans kazancı yok (ki bu internetin% 95'ini ilgilendirir ....), ancak Nginx havalı ;-)
Thomas Decaux

21

Rambler gibi bir site dinamik içeriği nasıl bu kadar hızlı sunar? ... Bu tamamen Nginx'in yeteneği mi? Bu yetenekler hakkında nereden bilgi edinebilirim?

Bunun kullanılan web sunucusuyla hiçbir ilgisi yoktur - hem nginx, IIS hem de Apache 'yeterince hızlı' olup, genellikle işlerini milisaniye içerisinde yaparlar. nginx Apache'den çok daha hızlıdır, ancak bu yalnızca site sahibinin web sunumu bölümü için daha az sunucuya ihtiyaç duyacağı anlamına gelir - nginx size daha hızlı veri aktarmaz.

Daha az önemli olan kısım, sunucu tarafı hızıdır , yani HTML'yi oluşturmak için geçen süredir. Daha önemli kısım, HTML, CSS, Javascript ve Görüntüler, bunların sayısı, bunların boyutu ve bunların uygun şekilde teslim edilmesi (HTTP sıkıştırma, önbellekleme) anlamına gelen 'ön uç' performansıdır .

Tabii ki sunucu tarafı hızı hala önemli, göz ardı edilmesi gerektiğini ya da önemli olmadığını söylemiyorum. Ancak, genellikle son kullanıcı hızının algılandığı en küçük kısımdır - sunucu tarafı çalışması genellikle 500 milisaniyeden daha az bir sürede yapılır, ancak sayfa 3.000 - 5.000 milisaniyeden geçmeden önce hazır değildir. Bu zamanın büyük kısmı ön uç kaynaklarını indirmeye gider (CSS, Javascript, Görüntüler).

Steve Souders asıl işi Yahoo'dayken yaptı, şimdi Google'da çalışıyor. İlk kitabı "Yüksek performanslı web siteleri" hızlı web siteleri yapma hakkında daha fazla bilgi edinmek için en iyi başlangıç ​​noktasıdır. Kitabındakiyle aynı materyal bu görüntülü konuşmada ve bu tasarım kurallarında bulunabilir . Ancak kitabın okunması hızlı ve anlaşılması daha kolay.

Siteleri WebPageTest.org test cihazı ile çalıştırabilirsiniz - bu size bu sitelerin ön kısımları ve neden daha hızlı veya daha yavaş oldukları hakkında iyi bir his verecektir.

Nginx'ten servis yapılırsa serverfault.com adresinin IIS 7'nin çok daha hızlı olacağına inanıyorum (db erişim zamanının her iki durumda da aynı olacağı varsayılarak). Bu adil bir varsayım mı?

Hayır, bu bir yanlış anlaşılma. :-)


18

Nginx, diğer uygulamaları / sunucuları yük dengelemek ve tüm sunucu olarak kullanıldığından daha fazla statik içerik sunmak için kullanılır.

Örneğin, birçok python çerçevesinden birini kullanarak bir uygulama yazabilir ve nginx'in bunun birçok örneğinin (belki de birkaç makineye yayılmış) ön tarafı olmasını sağlayabilirsiniz. Bu durumda nginx iki amaca hizmet eder: görüntüler ve stil sayfaları gibi statik içerik isteklerini doğrudan ele alır (tasarımı nedeniyle bunu çok hızlı yapar) ve yükü bildiği tüm örnekler arasında yayan uygulamaya dinamik istekleri iletir. . Bu Ruby on Rails topluluğunda da çok popüler bir yapılandırma.

Rambler'in size yerel Yahoo hizmetinden daha hızlı görünmesinin diğer iki olası nedeni var. Birincisi, yerel Yahoo PoP, daha çabuk aldığı istek sayısını karşılamak için yeterli kaynağa sahip olmayabilir, bu yüzden belki de daha fazla donanım eklemek (yazılımın bu şekilde iyi ölçeklendiğini varsayarak) hızlandırır (ama, muhtemelen, fark değildir). Ekstra kit bakımının bedeli ya da Yahoo bunu yapardı Diğer büyük fark, web sunucusundan ziyade arka uçta olabilir - iki servisin çok farklı veritabanı düzenlemeleri olduğundan şüphelenmeyecek ve tam olarak aynı çeşitlilikteki sorguları (ve veritabanı arşivine adanmış donanımın da önemli bir etkisi olacaktır).

Bir hizmetin neden diğerinden daha hızlı olduğunu (genellikle veya belirli durumlarda) analiz etmek genellikle tek bir basit cevaba yol açmayacaktır - her biri binlerce kişiye uyacak şekilde tasarlanmış bir uygulama tasarlamanın birçok yolu vardır. kendi yararları, sorunları ve ödünleri verme ve tüm bu farkları göz ardı etseniz bile, her site farklı bir kullanıcı tabanı dinamiğine sahip olacak, ayrıca tasarımcıların kontrolünün ötesinde ağ sorunları da olacak.


3

nginx muhtemelen statik içerik sunucuları / dinamik içerik üreticileri önünde makul bir yük dengeleme ile daha ölçeklenebilir bir yapıya sahiptir Eğer gerçekten mükemmel bir son kullanıcı deneyimi elde etmek istiyorsanız, içeriği muhtemelen 'gözbebeklerine' yaklaştırmalısınız - biraz CDN kullanın.

Eğer konu ile ilgilenen eğer - check out bu ve bu iyi .. ve - google; -]


2

En iyi siteler, Zeus'un ZXTM'leri gibi uygulama hızlandırıcılarını kullanır - birçok durumda dinamik yanıtları açıkça ön plana çıkarabilirler.



0

Sunucumun hatalarını çok daha hızlı görmekte zorlanıyorum (SO trafikten kaynaklanan sorunlara neden olabilir mi?) Çünkü zaten burada yolumun üzerinden AB’de bir anlık sayfa yüklendi. Çoğu yerel haber sitesinden çok daha hızlı ve daha hızlı yanıt veriyor.

Yükleme süreleri ve gecikmeyle ilgili bariz sorunların çoğu, sunucu ve son kullanıcı imo arasında gerçekleşir ve asıl sunucu performansı değil (birisi yanlış bir şey tasarladıysa veya tasarlamazsa). Farklı siteler farklı şekillerde yönlendirilebilir ve benim için bir ülke-yerel sitenin gezegen üzerindeki bir şeyden daha büyük bir gecikme süresine sahip olma olasılığı çok yüksektir - hepsi bir servis tarafından çözülebilir olduğunu söyleyemeyeceğiniz birçok değişkene bağlıdır. Belirli bir kullanım (r) için konunun nerede olduğunu bilmediğiniz sürece yükseltme / değiştirme ...

Açıkçası sunucuda çeşitli türlerin önbelleğe alınması büyük bir fark yaratıyor, ancak tüm bu siteler zaten bildiğim kadarıyla bunu yapıyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.