Pertengkaran, kinerja yang buruk, dan deadlock ketika Anda membuat permintaan layanan Web dari ASP.NET aplikasi

Ketika Anda membuat panggilan ke layanan XML Web dari ASP.NET aplikasi, Anda mungkin mengalami pertentangan, kinerja yang buruk, dan deadlock. Klien dapat melaporkan bahwa permintaan berhenti merespons (atau "menggantung") atau mengambil sangat waktu yang panjang untuk menjalankan. Jika jalan buntu diduga, proses pekerja mungkin daur ulang. Anda akan menerima pesan berikut di log peristiwa aplikasi.

• Jika Anda menggunakan Microsoft Internet Information Services (IIS) 5.0, Anda menerima pesan berikut di acara aplikasi log:

     Event Type:     Error
     Event Source:   ASP.NET 1.0.3705.0
     Event Category: None
     Event ID:       1003
     Date:           5/4/2003
     Time:           6:18:23 PM
     User:           N/A
     Computer:       <ComputerName>
     Description:
        aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
        It did not send any responses for pending requests in the last 180 seconds.

• Jika Anda menggunakan IIS 6.0, Anda menerima berikut pesan log peristiwa aplikasi:

     Event Type:     Warning
     Event Source:   W3SVC-WP
     Event Category: None
     Event ID:       2262
     Date:           5/4/2003
     Time:           1:02:33 PM
     User:           N/A
     Computer:       <ComputerName>
     Description:
        ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
        unhealthy for the following reason: 'Deadlock detected'.

• Jika Anda menggunakan IIS 6.0, Anda menerima berikut pesan log peristiwa sistem:

     Event Type:     Warning
     Event Source:   W3SVC
     Event Category: None
     Event ID:       1013
     Date:           5/4/2003
     Time:           1:03:47 PM
     User:           N/A
     Computer:       <ComputerName>
     Description:
        A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
        The process id was '<xxxx>'.

Anda mungkin juga menerima galat pengecualian berikut pesan Anda membuat panggilan ke HttpWebRequest.GetResponse metode:Anda mungkin juga menerima pesan galat berikut pengecualian dalam browser:Catatan Artikel ini juga berlaku untuk aplikasi yang membuat HttpWebRequest permintaan secara langsung.

Masalah ini mungkin terjadi karena ASP.NET membatasi jumlah thread pekerja dan penyelesaian pelabuhan benang yang panggilan dapat digunakan untuk mengeksekusi permintaan.

Biasanya, panggilan untuk layanan Web menggunakan satu pekerja benang untuk mengeksekusi kode yang mengirim permintaan dan penyelesaian satu port benang untuk menerima panggilan balik dari layanan Web. Namun, jika permintaan dialihkan atau memerlukan otentikasi, panggilan dapat menggunakan sebanyak dua pekerja dan dua penyelesaian pelabuhan benang. Oleh karena itu, Anda dapat knalpot dikelola ThreadPool ketika beberapa layanan Web panggilan terjadi pada waktu yang sama.

Untuk contoh, Anggaplah bahwa ThreadPool terbatas pada 10 pekerja benang, dan semua 10 pekerja benang saat ini mengeksekusi kode yang menunggu untuk panggilan balik untuk mengeksekusi. Panggil balik tidak pernah dapat mengeksekusi karena pekerjaan item yang antri untuk ThreadPool diblokir sampai thread menjadi tersedia.

Potensial lain sumber pertentangan adalah maxconnection parameter yang System.net namespace menggunakan untuk membatasi jumlah koneksi. Umumnya, batas ini bekerja seperti yang diharapkan. Namun, jika banyak aplikasi yang mencoba untuk membuat banyak permintaan untuk satu alamat IP pada saat yang sama, benang mungkin harus menunggu koneksi yang tersedia.

Untuk mengatasi masalah ini, Anda dapat menyetel berikut parameter di file Machine.config elemen dari terbaik sesuai dengan situasi Anda:

• maxWorkerThreads
• minWorkerThreads
• maxIoThreads
• minFreeThreads
• minLocalRequestFreeThreads
• maxconnection
• executionTimeout

Untuk berhasil menyelesaikan masalah ini, lakukan hal berikut:

• Batas jumlah ASP.NET permintaan yang dapat mengeksekusi pada waktu yang sama untuk sekitar 12 per CPU.
• Izin Web layanan callback untuk secara bebas menggunakan benang di ThreadPool.
• Pilih nilai yang sesuai untuk maxconnections parameter. Berdasarkan pilihan Anda jumlah alamat IP dan AppDomains yang digunakan.

Catatan Rekomendasi untuk membatasi jumlah ASP.NET permintaan untuk 12 per CPU adalah agak sewenang-wenang. Namun, batas ini telah terbukti untuk bekerja dengan baik untuk sebagian besar aplikasi.

maxWorkerThreads dan maxIoThreads

ASP.NET menggunakan pengaturan konfigurasi dua berikut untuk membatasi jumlah maksimum pekerja benang dan penyelesaian benang yang digunakan: The maxWorkerThreads parameter dan maxIoThreads parameter secara implisit dikalikan dengan jumlah CPU. Untuk contoh, jika Anda memiliki dua prosesor, jumlah maksimum pekerja benang adalah Berikut ini:

minFreeThreads dan minLocalRequestFreeThreads

ASP.NET juga berisi konfigurasi berikut pengaturan yang menentukan berapa banyak pekerja benang dan penyelesaian port benang harus tersedia untuk memulai permintaan remote atau lokal permintaan:Jika tidak ada cukup benang yang tersedia, permintaan antri sampai cukup benang bebas untuk membuat permintaan. Oleh karena itu, ASP.NET akan tidak menjalankan lebih dari jumlah berikut permintaan pada waktu yang sama:Catatan The minFreeThreads parameter dan minLocalRequestFreeThreads parameter tidak secara implisit dikalikan dengan jumlah CPU.

minWorkerThreads

Seperti ASP.BERSIH 1.0 Service Pack 3 dan ASP.NET 1.1, ASP.NET juga berisi pengaturan konfigurasi berikut yang menentukan bagaimana banyak pekerja benang dapat dibuat tersedia segera untuk layanan remote permintaan. Benang yang dikendalikan oleh ini pengaturan dapat dibuat pada tingkat yang jauh lebih cepat daripada thread pekerja yang dibuat dari CLR default "benang-tuning" kemampuan. Pengaturan ini memungkinkan ASP.NET untuk permintaan layanan yang mungkin tiba-tiba mengisi ASP.NET permintaan antrian karena untuk lambat-down pada back-end server, tiba-tiba ledakan permintaan dari ujung klien, atau sesuatu yang serupa yang akan menyebabkan peningkatan jumlah permintaan tiba-tiba dalam antrian. The nilai untuk default minWorkerThreads parameter adalah 1. Sebaiknya Anda mengatur nilai minWorkerThreads parameter untuk nilai berikut. Secara default, minWorkerThreads parameter tidak ada dalam file Web.config baik atau Machine.config elemen dari file. Pengaturan ini secara implisit dikalikan dengan jumlah CPU.

maxconnection

The maxconnection parameter ini menentukan berapa banyak koneksi dapat dibuat untuk alamat IP tertentu. Parameter muncul sebagai berikut:Pengaturan untuk parameter yang dibahas sebelumnya di ini Artikel ini adalah semua tingkat proses. Namun, maxconnection parameter pengaturan berlaku untuk tingkat AppDomain. Secara default, karena pengaturan ini berlaku untuk tingkat AppDomain, Anda dapat membuat hingga maksimum dari dua sambungan ke alamat IP tertentu dari setiap AppDomain di Anda proses.

executionTimeout

ASP.NET menggunakan pengaturan konfigurasi berikut untuk batas waktu eksekusi permintaan: Anda juga dapat menetapkan batas ini dengan menggunakan Server.ScriptTimeout properti.

Catatan Jika Anda meningkatkan nilai executionTimeout parameter, Anda juga harus memodifikasi processModel responseDeadlockInterval parameter pengaturan.

Rekomendasi

Pengaturan yang disarankan di bagian ini tidak dapat berfungsi untuk semua aplikasi. Namun, informasi tambahan berikut dapat membantu Anda untuk membuat penyesuaian yang tepat.

Jika Anda membuat satu Web layanan panggilan untuk satu alamat IP dari setiap halaman ASPX, Microsoft menganjurkan agar Anda menggunakan pengaturan konfigurasi berikut:

• Mengatur nilai-nilai maxWorkerThreads parameter dan maxIoThreads parameter untuk 100.
• Mengatur nilai maxconnection parameter untuk 12 *N (di mana N adalah jumlah CPU yang Anda memiliki).
• Mengatur nilai-nilai minFreeThreads parameter untuk 88 *N dan minLocalRequestFreeThreads parameter untuk76 *N.
• Set nilai minWorkerThreads untuk 50. Ingat, minWorkerThreads ini tidak di file konfigurasi standarnya. Anda harus menambahkannya.

Beberapa rekomendasi ini melibatkan rumus sederhana yang melibatkan nomor CPU pada server. Variabel yang mewakili jumlah CPU di Formula adalah N. Untuk pengaturan ini, jika Anda memiliki hyperthreading diaktifkan, Anda harus menggunakan jumlah CPU logis bukan jumlah CPU fisik. Sebagai contoh, jika Anda memiliki server empat-prosesor dengan hyperthreading yang diaktifkan, maka nilai N dalam rumus akan 8 Melainkan 4.

Catatan Ketika Anda menggunakan konfigurasi ini, Anda dapat melaksanakan maksimum 12 ASP.NET permintaan per CPU pada saat yang sama karena 100-88 = 12. Oleh karena itu, setidaknya 88 *N pekerja benang dan 88 *N penyelesaian pelabuhan benang yang tersedia untuk penggunaan lain (seperti callback layanan Web).

Misalnya, Anda memiliki sebuah server dengan empat prosesor dan hyperthreading diaktifkan. Berdasarkan rumus ini, Anda akan menggunakan nilai berikut untuk pengaturan konfigurasi yang disebutkan dalam artikel ini.
Juga, ketika Anda menggunakan konfigurasi ini, sambungan 12 tersedia per CPU per alamat IP untuk setiap AppDomain. Oleh karena itu, di bawah skenario, sangat sedikit pertentangan terjadi ketika permintaan menunggu sambungan, dan ThreadPool tidak lelah:

• Web host hanya satu aplikasi (AppDomain).
• Setiap permintaan untuk ASPX halaman membuat satu layanan Web permintaan.
• Semua permintaan adalah ke alamat IP yang sama.

Namun, bila Anda menggunakan konfigurasi ini, skenario yang melibatkan salah satu langkah berikut mungkin akan menggunakan terlalu banyak koneksi:

• Permintaan akan beberapa alamat IP.
• Permintaan yang diarahkan (kode 302 status).
• Permintaan memerlukan otentikasi.
• Permintaan yang terbuat dari beberapa AppDomains.

Dalam skenario ini, itu adalah ide yang baik untuk menggunakan nilai yang lebih rendah untuk The maxconnection parameter dan nilai-nilai yang lebih tinggi untuk minFreeThreads parameter dan minLocalRequestFreeThreads parameter.

Ini adalah aktivitas.

Jika Anda mengalami kinerja yang buruk dan pertarungan di IIS 7.0 dengan ASP.NET, melihat blog Microsoft berikut:

ASP.NET Thread penggunaan pada IIS 6.0 dan 7.0
ASP.net menggantung di IIS 7.0

Untuk informasi lebih lanjut, kunjungi Website Microsoft berikut Situs Web Developer Network (MSDN):