IIS: Bagaimana cara mengetahui apakah waktu yang lambat diambil karena koneksi jaringan yang lambat

Menurut http://support.microsoft.com/kb/944884 , "ketika respons besar atau respons besar dikirim ke klien melalui koneksi jaringan yang lambat, nilai bidang yang diambil waktu mungkin lebih dari yang diharapkan".

Saya memiliki situasi di mana klien akan berkata, "Saya mengirim permintaan ke server web Anda pada 10:03:24 dan butuh 20 detik, mengapa?". Saya bisa melihat ini di log IIS juga, tetapi modul server ASP.NET mencatatnya sebagai mengambil 100 ms, dan penghitung CPU dan Disk rendah.

Saya menduga itu karena koneksi jaringan yang lambat. Bagaimana saya bisa membuktikan ini?

Memperbarui:

1) Ini adalah permintaan SOAP Web Service, oleh karena itu tidak ada grafik yang disematkan, hanya HTTP POST dengan satu halaman hasil XML.

2) Juga, saya telah mereproduksi ini dengan membatasi kecepatan jaringan di sisi klien dan gejalanya persis sama.

3) Masalahnya terputus-putus, artinya permintaan yang sama biasanya cepat untuk klien tetapi terkadang lambat. Saya tidak dapat mereproduksi ini sendiri selain dengan menekan jaringan. Pencatatan server ASP.NET menunjukkannya selalu cepat, tetapi pencatatan IIS menunjukkannya lambat ketika klien mengatakan itu lambat.

4) Saya hanya memiliki akses ke server, dan perlu memberikan informasi sebanyak mungkin kepada klien sehingga mereka menerima bahwa masalahnya bukan pada server dan tahu apa logging / alat untuk dijalankan pada klien untuk menemukan akar penyebab.

— Jon
sumber

Apakah permintaan ini tampilan halaman normal yang memerlukan pengambilan grafik penyematan dan sebagainya? Atau apakah itu permintaan otomatis yang hanya menghasilkan satu halaman? Apakah kita benar-benar mengukur waktu untuk memuat halaman atau waktu untuk menanggapi permintaan HTTP tunggal?

— David Schwartz

Jawaban:

Saya memiliki situasi di mana klien akan berkata, "Saya mengirim permintaan ke server web Anda pada 10:03:24 dan butuh 20 detik, mengapa?". Saya bisa melihat ini di log IIS juga, tetapi modul server ASP.NET mencatatnya sebagai mengambil 100 ms, dan penghitung CPU dan Disk rendah.

Saya menduga itu karena koneksi jaringan yang lambat. Bagaimana saya bisa membuktikan ini?

Ini dimulai dengan mencari paket drop antara browser klien Anda dan semua sumber gambar / skrip / html untuk halaman web tersebut. Jika Anda menemukan penurunan paket yang konsisten, maka Anda tahu pasti ada sesuatu di jaringan yang perlu diperbaiki ... bahkan jika itu hanya tautan yang kelebihan beban. Paket tetes bukan satu-satunya alasan untuk jaringan yang lambat, tetapi itu adalah sumber paling umum dalam pengalaman saya. Sumber lain dapat berupa mesin proxy atau cache yang salah dikonfigurasi. Sayangnya, saya tidak dapat membuat daftar semua penyebab jaringan di sini.

Namun, orang sering menyalahkan jaringan, padahal sebenarnya masalah kecepatan berada dalam kendali mereka sendiri. Penjelasan yang mungkin:

Misalkan HTML untuk halaman itu ditulis dengan buruk dan memuat skrip yang diperlukan dalam urutan yang salah sehingga seluruh halaman merender dengan lambat, meskipun hampir semua sumber daya ada di tempat.
Halaman sedang menunggu sumber daya yang tidak ada dan habis waktu sambil menunggu.
Sebuah skrip berada dalam loop lambat yang memblokir untuk sementara waktu
Mesin cache membutuhkan waktu lama untuk mengirimkan gambar
CGI Anda mencari sesuatu dalam database, dan pencarian itu sendiri lambat
Anda menggunakan google analytics , yang memperlambat segalanya karena cara halaman ditulis

Saya bisa melanjutkan, tetapi intinya adalah Anda harus menemukan alasan yang tepat mengapa halaman itu lambat sendiri. Jaringan yang cacat dimungkinkan; mungkin juga faktor-faktor lain berkontribusi terhadap kinerja yang lambat.

Untuk mendiagnosis lebih lanjut:

Jika halaman dimuat dengan baik di Firefox, maka tab Network di Firebug adalah teman Anda (Hit F12, lalu buka tab Network dan muat ulang halaman). Firebug memberi Anda diagram air terjun yang bagus untuk bagaimana halaman dimuat dan di mana penundaan itu
Jika halaman dimuat dengan baik di Chrome, Anda dapat melakukan hal serupa (Hit CntlShiftI, klik pada tab jaringan, dan muat ulang halaman).
Jika halaman hanya didukung di IE (btw, malu pada pengembang HTML Anda), taruhan terbaik Anda adalah mulai memuat setiap elemen halaman ASP ini satu per satu curlhingga Anda menemukan sesuatu yang terlihat terlalu lambat, lalu cari tahu mengapa elemen tertentu itu lambat.

BTW, contoh Chrome dan Firefox menggunakan kueri CGI dari Debian.org ; ini adalah contoh yang baik dari penundaan yang berasal dari pencarian CGI.

Ketika semuanya gagal, Anda bisa mendapatkan .pcapdari wireshark dan menjalankannya tcptrace; Namun, sementara tcptracesangat baik menganalisis paket dumps, tidak ada jaminan bahwa Anda dapat mengisolasi masalah ini tcptracesendirian. Lihat jawaban ini untuk informasi tentang cara menggunakan tcptracediagnostik.

— Mike Pennington
sumber

Lihat pembaruan saya di atas. Meskipun info Anda sangat berguna dalam kasus umum, saya pikir itu tidak berlaku di sini. Halaman ini hanya sesekali lambat, dan gejalanya hanya dapat direproduksi ketika saya menekan jaringan di sisi klien.

— Jon

grafik air terjun di firefox / chrome mendukung operasi posting http, dan juga curl ... Saya tidak yakin bagaimana Anda menyimpulkan bahwa info tersebut tidak berlaku, tetapi tampaknya itu tidak melibatkan aplikasi lengkap alat-alat terhadap domain masalah .

— Mike Pennington

Firefox / chrome adalah alat sisi klien. Saya hanya memiliki akses ke server, dan saya tidak dapat melaporkan menggunakan klien saya sendiri. Saya perlu memberi tahu, dari server saja, jika permintaan tertentu lambat karena masalah jaringan. Itu membuat penangkapan paket, tapi itu terlalu berat untuk ditinggalkan dalam produksi (menganggap 1 dari 10.000 permintaan mungkin lambat).

— Jon

Sebagai seorang insinyur jaringan dengan lebih dari 15 tahun di bawah ikat pinggang saya, perkenankan saya dengan hormat menyarankan agar Anda tidak dapat mendiagnosis masalah layanan HTTP sisi klien dari server saja; Anda tidak punya cukup informasi (yang tampaknya kesimpulan Anda juga ... namun, Anda tampaknya tidak terbuka untuk hidup dengan kenyataan ini :-).

— Mike Pennington

Jika penangkapan paket di server dapat mendiagnosis masalah jaringan (mis. Melalui melihat TCP ack yang lambat), apakah tidak masuk akal untuk mengharapkan alat / pencatat yang lebih ringan dapat menunjukkan hal yang sama?

— Jon

Hasil dari artikel kb 944884 adalah bahwa waktu aktual yang diperlukan untuk menyelesaikan respons mungkin tidak secara akurat tercermin dalam log. Itulah sebabnya artikel itu menyebutkan waktu jaringan.

Jika gejalanya dapat direproduksi, saya akan melakukan pengambilan paket di sisi server (dan lebih disukai sisi klien) untuk melihat waktu aktual koneksi diakui oleh klien.

— Greg Askew
sumber

Terima kasih, tetapi ini tidak dapat direproduksi selain dengan melambatkan kecepatan jaringan, dan tangkapan paket terlalu berat untuk digunakan dalam produksi.

— Jon

Penundaan 20 detik juga bisa disebabkan oleh IIS harus me-restart itu w3wp.exe yang akan tidur ketika tidak digunakan.

— Steve Rollins
sumber

Anda dapat meningkatkan jawaban ini dengan menjawab "bagaimana cara mengetahui". w3wp.exe akan tidur tidak relevan dalam kasus saya karena saya telah menonaktifkan perilaku itu, tetapi ini bisa membantu orang lain.

— Jon