Teslimat pencerenizin gerektirdiği yararlı aktarım hızını hesaplayın, ardından tüm yolu ölçün. Bağlantı noktası kapasitesi, gidiş-dönüş süresi, TCP davranışı, depolama ve uygulama işleme sonucu etkiler. Gerçekçi eşzamanlılıkla kontrollü testler yapın ve bir ağ katmanı seçmeden önce bunları gerçek uygulama üzerinden tekrarlayın.
Teslimat penceresini bir hıza dönüştürün
Yararlı uygulama verisi miktarı ve bunu teslim etmek için mevcut süre ile başlayın. Ondalık birimler kullanıldığında, 2 TB verisini iki saatte aktarmak, protokol ek yükü ve kesintiler hesaba katılmadan önce yaklaşık 278 MB/saniye yük veya 2.22 Gbps gerektirir. Bu aritmetik bir planlama örneğidir, ölçülmüş bir hizmet sonucu değildir.
Örtüşen aktarımları dahil edin. Planlanmış bir dışa aktarma, müşteri indirmeleri ve yedekleme yüklemeleri, aylık toplamları mütevazı görünse bile kaynakları paylaşabilir. Yalnızca aylık ortalama değil, yoğun dönem modeli yazın. Hangi yönün önemli olduğunu ve başarısız bir aktarımın yeniden başlaması mı yoksa devam edebilmesi mi gerektiğini belirtin; bu davranış sistemin gerçekleştirdiği iş miktarını etkiler.
Bağlantı noktası kapasitesini yararlı verimden ayrı tutun
Bir sunucu bağlantı noktası bir bağlantı kapasitesini tanımlar. Yararlı verim, gözlemlenen bir aralıkta uygulamanız tarafından teslim edilen veriyi tanımlar. Şifreleme, protokol çerçeveleme, yeniden iletim, depolama etkinliği ve alıcıdaki işler bu yolun bölümlerini kaplar. Bu nedenle listelenen bir 10 Gbps bağlantı noktası, bir uygulamanın sürekli olarak 10 Gbps yük teslim edeceğini kanıtlamaz.
IETF RFC 6349, ağ yolunu test etmeyi TCP performansını incelemekten özellikle ayırır. Bu ayrımı kendi tanılamanızda kullanın. Önce uç noktaların ve rotanın uygun olduğunu doğrulayın, ardından taşıma katmanını ve uygulamayı inceleyin. Satın alınan bağlantı noktasını artırmak, veriyi yavaş yazan bir alıcıyı veya aynı anda tek istek işleyen bir uygulamayı düzeltmez.
Gidiş-dönüş süresinin neden önemli olduğunu anlayın
TCP, onaylar dönmeden önce ne kadar verinin uçuşta kalabileceğini kontrol eder. Bant genişliği-gecikme çarpımı bunun için yararlı bir ölçek verir: hız çarpı gidiş-dönüş süresi. 40 milisaniye gidiş-dönüş gecikmesine sahip varsayımsal bir 10 Gbps yolu, yaklaşık 50 MB uçuşta veriyi temsil eder. Bu hesaplama, gecikmenin ve taşıma davranışının neden yüksek hızlı planlamaya ait olduğunu açıklar.
Sonuç, rastgele bir soket ayarının uygulanması talimatı değildir. İşletim sistemleri, tıkanıklık kontrolü, anlaşılan pencereler ve gerçek yol davranışı etkiler. Ayar yapmadan önce güncel yazılım belgelerini doğrulayın ve ölçümleri inceleyin. Daha fazla paralel bağlantı bazı durumlarda toplam verimi iyileştirebilir, ancak uygulamanızın bağlı olduğu tek aktarımın davranışını da gizleyebilir.
Kontrollü bir test matrisi oluşturun
Yalnızca sahip olduğunuz veya test etme yetkiniz olan uç noktaları kullanın. Alıştırmanın normal hizmeti aksatmaması için test penceresi ve hızı üzerinde anlaşın. iperf3 gibi araçlar yapılandırılabilir yön, süre ve paralel akışlar sağlar; resmi belgeler bu kontrolleri tanımlar. Sürümü, uç noktaları, rota bağlamını ve ayarları sonuçla birlikte kaydedin; böylece başka bir operatör bunu yeniden üretebilir.
Tek bir akışla başlayın, ardından temsili eşzamanlılık ekleyin. Uygulama her iki yöne bağlıysa her iki yönü de çalıştırın. Bu örnek matris, tek bir manşet sonucun birbirine karıştıracağı soruları ayırır. İç adresleri veya operasyonel ayrıntıları açığa çıkardığında ham sonuçları özel olarak saklayın ve yalnızca karar için gereken ölçümleri yayınlayın.
| Test | Neyi inceliyor | Neyi kanıtlamıyor |
|---|---|---|
| Tek taşıma akışı | Tek akış yol davranışı | Toplam uygulama teslimatı |
| Birkaç paralel akış | Eşzamanlılık ve toplam sınırlar | Bir müşterinin aktarım hızı |
| Uygulama aktarımı | Depolama, protokol ve yazılım birlikte | Her veri kümesi için performans |
| Yoğun dönem tekrarı | Gerçekçi etkinlik altında değişim | Kalıcı bir verim garantisi |
Test sırasında uç noktalara bakın
Her iki uçta CPU kullanımını, bellek baskısını, depolama etkinliğini ve hata sayaçlarını kaydedin. Uç nokta gözlemleri olmadan bir aktarım sonucu, gerçek kısıtı görünmez bırakabilir. Bir sürecin veya CPU'in doymuş olup diğerlerinin boşta olup olmadığını kontrol edin. Aynı anda birkaç ayarı değiştirmekten kaçının, çünkü bu hangi ayarın yardımcı olduğunu belirlemeyi zorlaştırır.
Bellek destekli bir testi gerçek veriyi okuyup yazan bir testten ayırın. İlki taşıma yolunu incelemeye yardımcı olabilir; ikincisi uygulamanın işinin daha fazlasını yansıtır. Sonuçlar keskin biçimde farklıysa, bellek destekli rakamı bir teslimat vaadi olarak ele almak yerine depolamayı ve işlemeyi inceleyin. Kapsamları net olduğunda her iki ölçüm de yararlı olabilir.
Uygulamayı gerçekçi yüklerle test edin
Bir HTTP dışa aktarma, şifreli çoğaltma akışı ve dosya aktarım oturumu farklı işleme kalıplarına sahiptir. Temsili dosya boyutları, istek oranları ve şifreleme ayarları kullanın. Kullanıcı bu adımı beklediğinde, ilk bayt gönderilmeden önce veri hazırlamak için harcanan süreyi dahil edin. Birini diğeri olarak raporlamak yerine ilk yanıt gecikmesini tamamlanma süresinden ayırın.
Değişimi görmek için testi yeterli aralıkta tekrarlayın ve yapılandırmayı değiştirmeden önce bir temel tutun. Varsayımsal 2 TB dışa aktarma için gerçek tamamlanma süresini iki saatlik pencereyle karşılaştırın ve kesintiler için pay bırakın. Bağlantı noktası kapasitesini bir neden olmadan çarpmak yerine gözlemlenen darboğaza karşı bir iyileştirme seçin.
Sonucu bir yapılandırma seçmek için kullanın
Yararlı çıktı, kanıtlı bir kaynak gereksinimidir: ölçülmüş bir yük hızı, kabul edilebilir tamamlanma süresi, beklenen eşzamanlılık ve bilinen bir sınırlayıcı aşama. SwissOctet ağ varyantlarını bu gereksinimle karşılaştırın; trafik ödeneği ile CPU ve depolama spesifikasyonlarını dahil edin. Konum tek başına rotayı veya her alıcıya uçtan uca gecikmeyi belirlemez.
Test prosedürünü dağıtımdan sonra da koruyun. Veri kümeleri büyüdüğünde, yazılım değiştiğinde veya kullanıcılar farklı ağlara geçtiğinde bunu yeniden kullanın. Yeniden üretilebilir bir temel, performans olayını tanılamayı kolaylaştırır ve bir yapılandırmayı değiştirmek için izole bir hız testinden veya ilan edilen bir maksimumdan daha sağlam bir neden sağlar.
Pratik kontrol listeniz.
- Yük hızını hacim ve teslim süresinden hesaplayın.
- Örtüşen aktarımları ve yönü modelleyin.
- Yetkili test uç noktaları ve sınırları üzerinde anlaşın.
- Tek akışı, eşzamanlılığı ve uygulama testlerini karşılaştırın.
- Test sırasında her iki uç noktayı da gözlemleyin.
- Yeniden üretilebilir bir temel ve yararlı bir pay koruyun.
Önemli olan ayrıntılar.
Daha büyük bir TCP penceresi yavaş bir aktarımı her zaman düzeltir mi?+
Hayır. Önce yolu ve uç noktaları tanılayın. Depolama, CPU, kayıp ve uygulama davranışı baskın olabilir ve taşıma ayarı gerçek sisteme uygun olmalıdır.
Neden tek bir akışı ve birkaç akışı test etmeliyim?+
Farklı soruları yanıtlarlar. Toplam kapasite tek bir aktarımın hızından yüksek olabilir; hangi sonucun önemli olduğunu uygulamanın eşzamanlılığı belirler.
Herhangi bir genel sunucuya karşı kapasite testi çalıştırabilir miyim?+
Kontrol ettiğiniz veya test etme izniniz olan uç noktaları kullanın. Ölçümün ilgisiz hizmetleri aksatmaması için süre, hız ve zamanlama üzerinde anlaşın.
Kaynağa gidin.
Bu kaynaklar, bu kılavuzdaki teknik kavramları destekler. Bir üretim sistemini değiştirmeden önce güncel belgeleri izleyin.
- IETF RFC 6349: TCP verim testi çerçevesi datatracker.ietf.org
- ESnet: iperf3 çağırma software.es.net
SwissOctet tarafından editoryal rehberlik. Örnekler açıklayıcıdır. Hizmet spesifikasyonları, mevcut seçenekler ve sözleşme koşulları ayrıca doğrulanmalıdır.