Kim bilir haproxy Yazara Göre, bu yüzden bir iki şey http:

Canlı tutma CPU azaltmak için icat edilmiştir CPU kullanımı 100 yaşındayken sunucularda bir kez daha yavaş. Ama söylenenler değil kalıcı bağlantılar tüketen bellek olmasa da kullanışlı olmaktan çok müşteri dışında kimse kim onlar istedi mi yani herkes ister. Olan CPU 2009, bugün çok ucuz ve bellek hala sınırlıdır mimarisi ile birkaç gigabayt ya da fiyatı. Eğer bir site ihtiyacı varsa canlı tutma, gerçek bir sorun var. Aşırı yüklenen siteler genellikle devre dışı bırakın -hayatta tutmak maksimum destek için eşzamanlı müşteriler. Bu -hayatta tutmak zorunda değil gerçek dezavantajı için biraz daha yüksek bir gecikme. nesneleri getir. Tarayıcılar çift eş zamanlı bağlantı sayısı non-keepalive telafi etmek için siteler bu.

(http://haproxy.1wt.eu/)

Bu diğer halklar doğrultusunda yaşamak mı? "keep alive" -yani sonuç artık zor farkedilir mi? (muhtemelen onun değer websockets vb ile dikkat çeken bir bağlantısı tutulur "açık" canlı tutma durumu ne olursa olsun - çok duyarlı uygulamalar için zaten). Etkisi ise birçok eserler ise orada sunucu veya uzak olan insanlar bir sayfa yüklenirken aynı ana bilgisayardan yüklemek daha mı büyük? (CSS, resim ve JS gibi şeyler giderek önbellek dostu CDN geliyor diye düşünüyorum).

Düşünceler?

bu serverfault.com bir şey, ama biri beni oraya taşımak söyleyene kadar post çapraz) vermem (eğer emin değilim.

Hey bu alıntı, ben yazar değilim beri, ben karşılık vereceğim :-)

Büyük sitelerde iki büyük sorunu vardır : eşzamanlı bağlantı ve gecikme. Eşzamanlı bağlantı boşta bağlantı devletlerin indir içeriğini ve yaş yavaş istemciler tarafından kaynaklanır. Bu boş bağlantı devletlerin daha fazla gecikme artmış olan birden fazla nesne alıp bağlantıyı yeniden, "keep alive" olarak bilinen, kaynaklanır. İstemci sunucuya çok yakın, bağlantı, yoğun bir şekilde kullanır ve asla boşta neredeyse olun. Sıra bittiğinde ancak kimse hızlı kanal kapatmak için takar ve Bağlantı açık ve uzun süre kullanılmayan kalır. Çok düşük canlı tutma zaman aşımı kullanmanızı öneririz nedeni budur. Bazı sunucular gibi Apache, en düşük zaman aşımı ayarlayabilirsiniz. bir saniye, ve genellikle çok fazla sürdürmek için yüksek yükler varsa 20000 müşteriler önünde ve satmışlar ortalama bir nesne her saniye, o 20000 kalıcı bağlantılar kurdu. 20000 eşzamanlı bağlantı üzerinde genel amaçlı bir sunucu gibi Apache, büyük, çıkar arasında 32 ve 64 GB RAM ne olduğuna bağlı modüller yüklendi ve muhtemelen umut gitmek çok daha yüksek bile ekleyerek RAM. 20000 müşteriler için pratik, hatta tarayıcılar getirmek için çok sayıda nesne varsa 2-3 bağlantı kurmak için çalışacağız, çünkü sunucuda 60000 eşzamanlı bağlantı için 40000 görebilirsiniz.

Eğer her nesne sonra bağlantıyı kapatın, eş zamanlı bağlantı sayısı önemli ölçüde düşecek. Gerçekten de, bir faktör ortalama süre karşılık gelen nesneler arasında bir nesne indirmek için atacak. Eğer ihtiyacınız olan 50 ms indirmek için bir nesne (bir minyatür fotoğraf, düğme, vb...), ve karşıdan ortalama 1 nesne başına ikinci olarak, yukarıda, daha sonra tek sahip 0.05 bağlantı başına istemci, yalnızca 1000 eşzamanlı bağlantı için 20000 müşteriler.

Şimdi yeni bağlantılar kurma zamanı sayacak. Çok uzak istemciler hoş olmayan bir gecikme yaşayacaksınız. Geçmişte, tarayıcıları canlı tutma zaman eşzamanlı bağlantı büyük miktarda kullanmak için kullanılan devre dışı bırakıldı. MSIE 4 ve Netscape 8 rakamları hatırlıyorum. Bu gerçekten o kadar nesne başına gecikme, ortalama bölünmüş olurdu. Şimdi canlı tutmak her yerde, bunu yaparken daha da uzak sunuculardaki yükü artar, çünkü artık yüksek rakamlar görüyoruz ve tarayıcılar İnternet altyapısı korumaya dikkat çekmek.

Bu günümüz tarayıcıları ile, zor olmayan canlı tutma hizmetleri canlı tutma olanlar kadar tepki almak anlamına gelir. Ayrıca, bazı tarayıcılar (örn: Opera) keşif pipelinining kullanmaya çalışın. Boruhattı yöntemi kullanarak etkili bir şekilde hemen hemen bir karşılık beklemeden birden fazla isteği göndererek gecikme ortadan kaldırır çünkü hayatta tutmak. Ben denedim bir sayfa ile 100 küçük fotoğraf ve ilk erişim yaklaşık iki kat daha hızlı olarak olmadan canlı tutma, ama bir sonraki erişim yaklaşık 8 kat daha hızlı, çünkü tepkiler çok küçük sadece gecikme sayıları (sadece "304" yanıtları).

İdeal tarayıcılarda bazı tunables onları hayatta tutmak arasındaki bağlantıları yapmak için nesneleri getirilen ve hemen sayfa tamamlandığında bırakın olmamız gerektiğini söyleyebilirim. Ama ne yazık ki göremiyoruz.

Bu nedenle, ön tarafta Apache gibi genel kullanım amaçlı sunuculara yüklemek için gereken ve müşteriler büyük miktarda desteklemek zorunda olan bazı siteler genellikle devre dışı canlı tutmak için var. Ve tarayıcılar bağlantı sayısını artırmak için zorlamak için, indirme parallelized olabilir, böylece birden çok etki alanı adları kullanıyorlar. Bağlantı kur ek bir gidiş var gibi hatta daha yüksek olduğundan sitelerin yoğun SSL kullanarak özellikle sorunlu.

Ne olur daha sık gözlenen günümüzde bu tür siteleri tercih yükleyin ışık frontends gibi haproxy veya nginx, sorunsuz idare onlarca, yüzlerce, binlerce eşzamanlı bağlantı sağlar canlı tutma, istemci tarafında ve sakatlar üzerinde Apache yan. Bu tarafta bir bağlantı kurmanın maliyeti CPU açısından neredeyse boş, ve fark hiç de zaman açısından. Bu her iki dünyanın en iyi sağlar : düşük gecikme canlı tutmak istemci tarafında çok düşük zaman aşımı ve sunucu tarafında bağlantıları düşük sayıda nedeniyle. Herkes mutlu :-)

Bazı ticari ürünler daha ön yük dengeleyici ve sunucu arasındaki bağlantıları yeniden ve tüm istemci bağlantıları çoklu tarafından bu geliştirmek. Zaman sunucuları kapatmak için LB, kazanmak değil, çok daha yüksek daha önceki bir çözüm, ama bu genellikle gerektiren uyarlamalar üzerinde uygulama sağlamak için risk yok oturumu arasında geçiş kullanıcılar nedeniyle beklenmedik paylaşmak için bir bağlantı arasında birden çok kullanıcı. Teoride bunun asla olmaması gerekir. Gerçeklik çok farklı :-)