Yanlışlıkla dahili AB testimin sunucumun saniyede 3k vuruşla 1k eşzamanlılık işleyebileceği anlamına geldiğini varsaydım.

Şu anda benim teorim, ağın darboğaz olduğu. Sunucu yeterince hızlı veri gönderemiyor.

1k eşzamanlılıktaki blitz.io'dan yapılan harici testler, isabetlerimin 180 saniyede kapandığını gösteriyor, sayfalar yanıt vermenin daha uzun ve daha uzun sürdüğü için sunucu yalnızca saniyede 180 geri dönebiliyor.

Ben nginx boş bir dosya hizmet ettik ve tezgah ben: eşzamanlılık ile 1: 1 ölçekler.

Şimdi IO / memcached darboğazlarını (nginx normalde memcached'den çeker) ekarte etmek için, dosya sisteminden önbelleğe alınan sayfanın statik bir sürümünü sunuyorum.

Sonuçlar orijinal testime çok benziyor; Yaklaşık 180 RPS ile sınırlandım.

HTML sayfasını ikiye bölmek bana RPS'nin iki katını veriyor, bu yüzden kesinlikle sayfanın boyutu ile sınırlı.

Ben yerel sunucudan ApacheBench içersem, yüksek aktarım hızlarında Tam Sayfa ve Yarım Sayfada yaklaşık 4 K RPS tutarlı sonuçlar elde ediyorum. Transfer hızı: 62586.14 [Kbytes / sn] alındı

I harici bir sunucudan AB, yaklaşık 180RPS olsun - blitz.io sonuçları ile aynı.

Bunun kasıtlı azaltma olmadığını nasıl bilebilirim?

Birden fazla harici sunucudan karşılaştırma yaparsam, tüm sonuçlar kötü olur, bu da sorunun benim sunucularım / blitz.io ile indirme hızı sorunu değil, MY sunucuları giden trafiğinde olduğuna inanmamı sağlar.

Sonuç olarak sunucumun yeterince hızlı veri gönderemeyeceği sonucuna geri döndüm.

Haklı mıyım? Bu verileri yorumlamanın başka yolları var mı? Her biri saniyede 180 isabet alabilecek birden fazla sunucu + yük dengeleme kurmak için çözüm / optimizasyon var mı?

Sunucu optimizasyonu konusunda oldukça yeniyim, bu nedenle bu verileri yorumlayan herhangi bir onay için teşekkür ederim.

Giden trafik

Giden bant genişliği hakkında daha fazla bilgi: Ağ grafiği maksimum 16 Mb / s çıkış gösterir: saniyede 16 megabit. Hiç kulağa pek hoş gelmiyor.

Kısma ile ilgili bir öneri nedeniyle, buna baktım ve linod'un 50mbps'lik bir kapağa sahip olduğunu gördüm (ki görünüşe göre vurmaya bile yakın değilim). 100 mbps'ye çıkarttım.

Linode trafiğimi kapattığından ve hatta vurmadığımdan, sunucumun 100mbps'ye kadar çıkabilmesi gerektiği anlamına geliyor, ancak başka bir dahili darboğaz ile sınırlı mı? Bu büyüklükteki ağların nasıl çalıştığını anlamıyorum; HDD'den okuyabilecekleri kadar hızlı veri gönderebilirler mi? Ağ borusu bu kadar büyük mü?

Sonuç olarak

1: Yukarıdakilere dayanarak, LB'nin arkasındaki sunucu başına tam olarak 180RPS'de çok nginx sunucu kurulumunun üstüne bir nginx yük dengeleyici ekleyerek kesinlikle 180RPS'imi yükseltebileceğimi düşünüyorum.

2: Linode hiç vurmadığım bir 50 / 100mbit sınırına sahipse, tek sunucu kurulumumla bu sınıra ulaşmak için yapabileceğim bir şey olmalı. Verileri yerel olarak yeterince hızlı okuyabilir / aktarabilir ve hatta linode 50mbit / 100mbit kapağa sahip olsa bile rahatsız edersem, nasıl tespit edeceğimden emin olmadığım bu başlıkları vurmama izin vermeyen bir iç darboğaz olmalı. Doğru?

Sorunun şimdi çok büyük ve belirsiz olduğunu anlıyorum, ama nasıl yoğunlaşacağından emin değilim. Herhangi bir girdi yaptığım herhangi bir sonuç için takdir edilmektedir.

Sorun bana linode.com grafik zirveleri gerçek zirveleri olduğunu varsayarak oldu. Grafikte 5 dakikalık ortalama veri noktaları kullanıldığı ortaya çıkıyor, bu yüzden zirvem aslında 50mbit başlığa vururken 24mbits gibi görünüyordu.

Şimdi 100mbits'e yükselttiklerine göre, kriterlerim hemen yeni giden trafik sınırına yükseldi.

Keşke daha önce fark etmiş olsaydım! Akıl yürütmemin çoğu, bu grafik nedeniyle giden trafik sınırına ulaşmadığım fikrine bağlıydı.

Şimdi, saniyede 370 istekte zirveye çıkıyorum, bu da 100mbps'nin altında.

Artık sayfayı daraltarak maksimum eşzamanlılığı artırabilirim; gzip etkinken 600RPS alıyorum.

Aniden zirveye çıktığımda hala sorun yaşıyorum ve bekleyen isteklerin (bant genişliği ile sınırlı) birikmesi birikmeye başlıyor, ancak bu farklı bir soru gibi geliyor.

Optimizasyon / bu verileri okuma / olası sorunları daraltma konularında harika bir ders oldu. Girişiniz için çok teşekkür ederim!

Biraz geç fark ettiniz ... ama belki zaman zaman ServerFault blogunu okumayı düşünmelisiniz.

Özellikle bir saniye yoklama aralığına sahip olmanın neden zaman zaman kesmediğini, sahip olduğunuza çok benzer bir sorunla ilgili olduğunu tartıştıkları bu yazıyı özellikle düşünüyorum .

1 Gbit / s arayüzlerinde paketleri sık sık performansımızı zedeleyen sadece 10-30 MBit / s hızında attığımızı keşfettik. Bunun nedeni, 10-30 MBit / s hızının gerçekten 5 dakika başına aktarılan bit sayısı bir saniyelik bir hıza dönüştürülmesidir. Wireshark ile daha yakından kazdığımızda ve bir milisaniyelik IO grafiğini kullandığımızda, 1 Gbit / s arayüzlerinin milisaniye hızı başına 1 Mbit sık sık patlayacağımızı gördük.

Tabii beni düşündürdü. Ve biliyorum ki, ilk şansım dükkanımda diğer SA'lardan birisini yakaladığımı biliyorum ve bu soruna çarptığımızda kötü parlak ve algısal görünecek.

Kim bilir, bazılarının sırrını bile alabilirim. :)

Ağ tarafından sınırlı olabilir, ancak sadece bir bant genişliği sorunu olmayabilir. Uzak test ünitenizin gecikmesi, herhangi bir zamanda bekleyen bağlantı sayısını (onay için yerel olarak 50ms beklemek yerel olarak .5ms'den çok farklıdır) ve ayrıca bağlantı ilerledikçe pencere boyutlarının görüşülmesi ve dengelenmesi üzerinde etkili olacaktır. Ayrıca, tıkanıklığın bir fonksiyonu olarak veya operatörünüzün (veya yukarı akıştaki) bant genişliği sınırlama mekanizması olarak bir miktar paket kaybına da maruz kalacaksınız.

Makul bir taban çizgisi çizmek için denklemden mümkün olduğunca çıkarılmasını öneririm. Sunucunuzdan genel İnternet'teki birkaç noktaya kadar olan bant genişliğini, gecikmeyi ve paket kaybını ölçün. Olası görünmüyorsa, "Voip trafik testi" veya benzerlerini aramayı deneyin. VOIP servislerinin bazı sağlayıcıları, bu tür kalıpları (çift yönlü olarak) adil bir doğrulukla ölçebilen uygulamalara sahiptir. Bağlantınızın gerçek kullanışlı hızıyla ilgili bazı geçerli ampirik veriler elde ederseniz, sonuçlarınız doğrulanabilir.

Bant genişliği testlerine ek olarak, aşırı sayıda yeniden iletim aramak ve sunucunuzun istekleri yanıtlamak için geçtiği görünür süreyi ölçmek için alt par web trafiğinin bir paket yakalamasına bakmak da yararlı olabilir. bağlantı sayısının bir fonksiyonu olarak değer önemli ölçüde artmaktadır, bu büyük bir ipucudur).