IIS: Yavaş bir ağ bağlantısından dolayı yavaş zaman alınıp alınmadığı nasıl anlaşılır


10

Http://support.microsoft.com/kb/944884'e göre , "yavaş bir ağ bağlantısı üzerinden bir istemciye büyük bir yanıt veya büyük yanıt gönderildiğinde, zaman alan alanının değeri beklenenden fazla olabilir".

Bir müşterinin "Web sunucunuza 10:03:24 saatinde bir istek gönderdim ve 20 saniye sürdü, neden?" Diyeceği bir durum var. Bunu IIS günlüklerinde de görebiliyorum, ancak sunucunun ASP.NET modülü 100ms olarak kaydetti ve CPU ve Disk sayaçları düşüktü.

Bunun yavaş bir ağ bağlantısı nedeniyle olduğundan şüpheleniyorum. Bunu nasıl kanıtlayabilirim?

Güncelleme:

1) Bunlar SOAP Web Hizmeti istekleri, dolayısıyla gömülü grafikler değil, yalnızca tek bir XML sonuç sayfası içeren bir HTTP POST.

2) Ayrıca, istemci tarafında ağ hızını daraltarak bunu tekrarladım ve semptomlar tamamen aynı.

3) Sorun aralıklıdır, yani aynı istek normalde müşteri için hızlıdır ancak bazen yavaştır. Şebekeyi daraltmak dışında bunu kendim üretemiyorum. Sunucunun ASP.NET günlüğü her zaman hızlı olduğunu gösterir, ancak istemci yavaşladığını söylediğinde IIS günlüğü yavaş gösterir.

4) Sadece sunucuya erişimim var ve istemciye mümkün olduğunca fazla bilgi vermeliyim, böylece sorunun sunucuda olmadığını kabul ettiler ve kök nedenini bulmak için istemcide hangi günlük / araçların çalıştırılacağını biliyorlar.


Bu istekler, gömülü grafikler vb. Getirilmesini gerektiren normal sayfa görünümleri midir? Yoksa yalnızca tek bir sayfa döndüren otomatik sorgular mı? Bir sayfayı yükleme süresini mi yoksa tek bir HTTP isteğine yanıt verme süresini mi ölçüyoruz?
David Schwartz

Yanıtlar:


4

Bir müşterinin "Web sunucunuza 10:03:24 saatinde bir istek gönderdim ve 20 saniye sürdü, neden?" Diyeceği bir durum var. Bunu IIS günlüklerinde de görebiliyorum, ancak sunucunun ASP.NET modülü 100ms olarak kaydetti ve CPU ve Disk sayaçları düşüktü.

Bunun yavaş bir ağ bağlantısı nedeniyle olduğundan şüpheleniyorum. Bunu nasıl kanıtlayabilirim?

Bu, istemcinizin tarayıcısı ve yukarıda belirtilen web sayfası için tüm resim / komut dosyası / html kaynakları arasında paket damlalarını aramakla başlar . Tutarlı paket düşüşleri bulursanız, ağda düzeltilmesi gereken bir şey olduğundan emin olabilirsiniz ... sadece aşırı yüklenmiş bir bağlantı olsa bile. Paket düşüşleri yavaş bir ağın tek nedeni değildir, ancak deneyimimdeki en yaygın kaynaktır. Diğer kaynaklar yanlış yapılandırılmış bir proxy veya önbellek motoru olabilir. Ne yazık ki, tüm olası ağ suçlularını burada listeleyemiyorum.

Bununla birlikte, aslında hız sorunları kendi kontrolleri içinde olduğunda, insanlar genellikle ağı suçlarlar. Olası açıklamalar:

  • Bu sayfanın HTML'sinin kötü yazıldığını ve gerekli komut dosyalarını yanlış sırada yüklediğini ve neredeyse tüm kaynakların yerinde olmasına rağmen sayfanın tamamının yavaş işlediğini varsayalım.
  • Sayfa, var olmayan bir kaynağı bekliyor ve beklerken zaman aşımına uğradı.
  • Bir komut dosyası bir süre engellenen yavaş bir döngüde
  • Bir önbellek motorunun görüntü aktarması uzun zaman alıyor
  • CGI'niz veritabanında bir şey arıyor ve aramanın kendisi yavaş
  • Sayfanın yazılma şekli nedeniyle işleri yavaşlatan google analizi kullanıyorsunuz

Devam edebilirdim, ama asıl önemli olan, sayfanın neden yavaş kaldığının kesin nedenini ortaya çıkarmak zorundasınız. Kusurlu bir ağ mümkündür; diğer faktörlerin yavaş performansa katkıda bulunması da mümkündür.

Daha fazla teşhis etmek için:

  • Sayfa Firefox'ta iyi yüklüyse , Firebug'daki Ağ sekmesi arkadaşınızdır (Vur F12, ardından Ağ sekmesine gidin ve sayfayı yeniden yükleyin). Firebug, sayfanın nasıl yüklendiği ve gecikmelerin nerede olduğu konusunda size güzel bir şelale diyagramı verirKundakçı şelale
  • Sayfa Chrome'a ​​iyi yüklenirse, benzer bir şey yapabilirsiniz (Hit CntlShiftI, ağ sekmesini tıklayın ve sayfayı yeniden yükleyin).Krom
  • Sayfa yalnızca IE'de destekleniyorsa (btw, HTML geliştiricilerinizde utanç), en iyi seçeneğiniz, curlçok yavaş görünen bir şey bulana kadar bu ASP sayfa öğelerinin her birini ayrı ayrı yüklemeye başlamaktır , ardından bu öğenin nedenini öğrenin yavaş.

BTW, Chrome ve Firefox örnekleri Debian.org'dan bir CGI sorgusu kullandı ; bu bir CGI aramasından kaynaklanan gecikmeye iyi bir örnektir.

Herkes başarısız olduğunda, bir elde edebilirsiniz .pcapgelen wireshark ve içinden çalıştırmak tcptrace; Bununla birlikte, tcptracepaket dökümlerini analiz etmede çok iyi olsa da, sorunu tcptracetek başına izole edebileceğinizin garantisi yoktur . Teşhis kullanma hakkında bilgi için bu cevaba bakınız tcptrace.


Yukarıdaki güncellemelerime bakın. Bilgileriniz genel durumda çok yararlı olsa da, burada geçerli olduğunu düşünmüyorum. Sayfa sadece aralıklı olarak yavaş ve belirtiler yalnızca ağı istemci tarafında kıstığımda tekrarlanabilir.
Jon

firefox / chrome şelale çizelgeleri http post işlemleri yanı sıra kıvırmak ... Bilginin geçerli olmadığı sonucuna nasıl ulaştığınızdan emin değilim, ancak sorun alanına karşı araçların tam bir uygulamasını içermediği anlaşılıyor. .
Mike Pennington

Firefox / chrome istemci tarafı araçlarıdır. Yalnızca sunucuya erişimim var ve kendi istemcimi kullanarak çoğaltma yapamıyorum. Ağ sorunları nedeniyle belirli bir istek yavaş olsaydı, sadece sunucudan söylemeliyim. Bu, paket yakalamayı bırakır, ancak üretimde bırakılamayacak kadar ağırdır (10.000 talepten 1'inin yavaş olabileceğini düşünün).
Jon

Kemerimin altında 15 yılı aşkın bir ağ mühendisi olarak, yalnızca sunucudan istemci tarafı HTTP hizmetleri sorununu tanılayamayacağınızı saygıyla önerebilir miyim; sadece yeterli bilgiye sahip değilsiniz (görünüşe göre sonucunuz da budur ... ancak, bu gerçeklikle yaşamaya açık görünmüyorsunuz :-).
Mike Pennington

Sunucuda paket yakalama ağ sorunlarını tanılayabilirse (örneğin, yavaş bir TCP ack görerek), daha hafif bir araç / kaydedicinin aynı şeyi göstermesini beklemek mantıklı değil mi?
Jon

0

944884 numaralı kb maddesinin sonucu, yanıtı tamamlamak için gereken gerçek sürenin günlüğe tam olarak yansıtılmayabileceğidir. Bu yüzden makale ağ zamanından bahsediyor.

Belirti yeniden üretilebiliyorsa, bağlantının istemci tarafından kabul edildiği gerçek süreleri görmek için sunucu tarafında (ve tercihen istemci tarafında) bir paket yakalama gerçekleştiririm.


Teşekkürler, ancak ağ hızını azaltma dışında tekrar üretilemez ve bir paket yakalama, üretimde kullanmak için çok ağırdır.
Jon

0

20 saniyelik gecikme, IIS'nin kullanılmadığında uyku moduna girecek olan w3wp.exe dosyasını yeniden başlatması nedeniyle de olabilir.


1
Bu cevabı "nasıl söylenir" şeklinde cevaplayarak geliştirebilirsiniz. w3wp.exe uyuyacak benim durumumda bu davranışı devre dışı bıraktığım için ilgili değil, ama bu başkalarına yardımcı olabilir.
Jon
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.