Bir web sunucusu için saniyede gerçekçi bir istek ölçüsü belirleme

15

Bir nginx yığını oluşturuyorum ve canlı yayınlanmadan önce yapılandırmayı optimize ediyorum. Makineyi stres testi için ab çalıştırarak, saniyede 150 istekte bir şeylerin geri dönmesini> 1 saniye süren önemli sayıda talep gördüğümde hayal kırıklığına uğradım. İşin garibi, makinenin kendisi bile zor nefes almıyordu.

Sonunda kutuya ping atmayı düşündüm ve 100-125 ms civarında ping süreleri gördüm. (Makine, benim için sürpriz oldu, ülke çapında). Yani, ağ gecikmesi testime baskın geliyor gibi görünüyor. Sunucu ile aynı ağdaki bir makineden aynı testleri yürütüyoruz (ping süreleri <1 ms) ve saniyede 5000 istek görüyorum, bu da makineden beklediğim ile daha uyumlu.

Ama bu beni düşündürdü: Bir web sunucusu için saniyede "gerçekçi" bir istek ölçüsünü nasıl belirleyebilir ve rapor edebilirim? Her zaman performansla ilgili iddialar görürsünüz, ancak ağ gecikmesini dikkate almamalısınız? Tabii, sunucunun yanındaki bir makineye saniyede 5000 istek sunabilirim, ancak ülke genelindeki bir makineye sunamıyorum. Çok sayıda yavaş bağlantım varsa, sonunda sunucumun performansını etkileyecekler, değil mi? Yoksa bunların hepsini yanlış mı düşünüyorum?

Bu ağ mühendisliği 101 şey ise beni affet. Ben ticaretle geliştiriciyim.

Güncelleme: Anlaşılır olması için düzenlendi.

— Don
kaynak

abeşzamanlılık seçeneği vardır. Neye ayarladın? Ayrıca, yerel bir ADSL bağlantısından test yapıyorsanız, testin bant genişliğinizde baskın olması muhtemeldir ve sunucuda hiçbir şey test etmeyecektir.

— Ladadadada

Ab'nin eşzamanlılık seçeneğini tanıyorum ve kutunun sınırlarını keşfetmek için çok çeşitli değerler denedim. Yukarıda yazdığım gibi, ilk testlerimin ağ tarafından yönetildiğini ve sunucunun kapasitesini yansıtmadığını anlıyorum. Ama sorum hala duruyor: Çoğu insan gerçekçi metrikler almak için testlerini nereden yapıyor? Testler, sunucu ile aynı ağdaki bir kutudan (herhangi bir ağ gecikmesini denklemden etkili bir şekilde bırakarak) büyük sayılar döndürür, ancak gerçek kullanıcılar ağın dışından geleceğinden "adil" sayılar gibi görünmez.

— Don

Aynı ağdan yapılan testler aslında ağı görmezden geldikleri için daha 'adil' olabilir. Kullanıcılarınızın büyük olasılıkla farklı ağlarda olması nedeniyle, bu ağların toplam bant genişliği sunucunuzun kullanılabilir bant genişliğini kolayca aşmalıdır. Tüm kullanıcılar birlikte düşünüldüğünde, darboğaz sunucunun yetenekleridir - oysa tek bir kullanıcı göz önüne alındığında, darboğaz tek kullanıcının bant genişliği olabilir. (İdeal test, gerçek durumları en iyi şekilde simüle etmek için birçok uzak konumdan çalıştırılabilir, ancak çoğu durumda buna ihtiyaç duyulmamalıdır).

— cyberx86

"Tüm kullanıcıları birlikte ele aldığımızda, darboğaz sunucunun yetenekleridir" - bu mantıklı ve düşünmek için doğru yol gibi görünüyor. Sunucu, crappy ağ ekipmanının arkasında oturuyor olabilir, yanıt oranını dış dünyayla sınırlayabilir, ancak bu gerçekten sunucunun sorunu değildir ve ayrı olarak ele alınması gerekir. Sanırım , Pingdom gibi bir şey ideal testi çalıştırmak için kullanılabilir.

— Don

3

Sunucunuzun dünyanın herhangi bir yerinden erişildiğinde performansını önemsiyorsanız, dünyanın herhangi bir yerindeki bir arkadaşınızdan (iyi bant genişliği olmalı) linux kutusuna sproxy + kuşatma takmasını isteyin . Sadece indirin, yapılandırın, yapın. Bu araçlar küçüktür, saniyeler içinde derlenir.

İlk olarak, sproxylinux kutusuna başlayın . Varsayılan olarak, localhost (127.0.0.1) üzerindeki 9001 numaralı bağlantı noktasında çalışır. Dışarıdan erişmek istiyorsanız, giden IP adresini parametre olarak iletmeniz yeterlidir.
Şimdi tarayıcınızı bu ip ve bağlantı noktasını HTTP için proxy olarak kullanacak şekilde ayarlayarak sproxy'ye bağlanın. Bundan sonra yaptığınız her şey sproxy ile kaydedilir ve daha sonra tekrar oynatılabilir. Şimdi sitenizde gezinin, müşterilerinizin yapacağı şeyleri yapın ve sunucunuzu kullanan "pahalı" şeyler yapmaya çalışın.
İşiniz bittiğinde CTRL ^ C'ye basarak sproksiyi sonlandırın. Eylemlerinizi kaydetti $HOME/urls.txt. Dosyayı kuşatmanın bulunduğu yere taşıyın. Stres testine başlamak için çalıştırın siege -f urls.txt -d NUM -c NUM. distekler arasındaki gecikme anlamına gelir, performans testleri yaparken 1 (saniye) kullanın.csimüle edilmiş eşzamanlı kullanıcı sayısını ifade eder. İstediğinizi seçin, ancak düşük başlayın. Kuşatma size saniye başına işlem sayısını, hata oranını, ortalama taleplerin ne kadar sürdüğünü vb. Gösterecektir. Güçlü ve kullanımı kolay bir araçtır.
Parametreler hakkında daha fazla bilgiye ihtiyacınız varsa (çok var), kuşatma kılavuzunu ve sproxy kılavuzunu kontrol edin

Daha gerçekçi sonuçlar almak için, birçok kişinin sunucunuzu çeşitli ülkelerden bir kerede test etmesine ve size istatistikleri göndermesine izin verin.

— SebiF
kaynak

2

Gerçekçi istekler / sn önlemi erişim günlüklerinden alınmalıdır. IMO, istek gecikmesinin sunucu yüküyle ilgisi yoktur, çünkü sunucu tüm istekleri kökenlerine bakılmaksızın aynı hızda işler.

— ejaenv
kaynak

1

Soasta Cloudtest gibi hizmetleri kullanmayı düşünün . Bununla birlikte, testleriniz hakkında oldukça ayrıntılı raporlar alabilir ve çeşitli genel bulut / sanallaştırma sağlayıcılarından performans testleri çalıştırabilirsiniz. Sunucularınızı ne kadar zor ve ne kadar süreyle çekiçlemek istediğinizi yapılandırabilirsiniz. Ayrıca herhangi bir para vermeden önce neler yapabileceğini görebileceğiniz ücretsiz bir " lite " sürümüne sahipler .

— Mxx
kaynak