Kami memiliki aplikasi yang memiliki layanan WCF (* .svc) yang berjalan di IIS7 dan berbagai klien yang meminta layanan tersebut. Server menjalankan Win 2008 Server. Klien menjalankan Windows 2008 Server atau Windows 2003 server. Saya mendapatkan pengecualian berikut, yang saya lihat sebenarnya terkait dengan sejumlah besar masalah WCF potensial.
System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://www.domain.com/WebServices/myservice.svc/gzip' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. Saya telah meningkatkan batas waktu menjadi 30 menit dan kesalahan masih terjadi. Ini memberi tahu saya bahwa ada hal lain yang sedang dimainkan, karena kuantitas data tidak pernah bisa memakan waktu 30 menit untuk mengunggah atau mengunduh.
Kesalahan datang dan pergi. Saat ini, itu lebih sering. Sepertinya tidak masalah jika saya memiliki 3 klien yang berjalan secara bersamaan atau 100, itu masih terjadi sesekali. Sering kali, tidak ada waktu tunggu tetapi saya masih mendapatkan beberapa waktu tunggu per jam. Kesalahan berasal dari salah satu metode yang dipanggil. Salah satu metode ini tidak memiliki parameter dan mengembalikan sedikit data. Yang lain mengambil banyak data sebagai parameter tetapi dijalankan secara asinkron. Error selalu berasal dari klien dan tidak pernah mereferensikan kode apa pun di server dalam pelacakan tumpukan. Itu selalu diakhiri dengan:
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
Di server: Saya telah mencoba (dan saat ini memiliki) pengaturan pengikatan berikut:
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"Sepertinya tidak berdampak.
Saya telah mencoba (dan saat ini memiliki) pengaturan pelambatan berikut:
<serviceThrottling maxConcurrentCalls="1500" maxConcurrentInstances="1500" maxConcurrentSessions="1500"/>Sepertinya tidak berdampak.
Saat ini saya memiliki pengaturan berikut untuk layanan WCF.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]Saya menjalankannya ConcurrencyMode.Multiplesebentar, dan kesalahan masih terjadi.
Saya sudah mencoba memulai ulang IIS, memulai ulang SQL Server saya yang mendasarinya, memulai ulang mesin. Semua ini sepertinya tidak berdampak.
Saya sudah mencoba menonaktifkan firewall Windows. Sepertinya tidak berdampak.
Di klien, saya memiliki pengaturan ini:
maxReceivedMessageSize="2147483647"
<system.net>
<connectionManagement>
<add address="*" maxconnection="16"/>
</connectionManagement>
</system.net>
Klien saya menutup koneksinya:
var client = new MyClient();
try
{
return client.GetConfigurationOptions();
}
finally
{
client.Close();
}
Saya telah mengubah pengaturan registri untuk memungkinkan lebih banyak koneksi keluar:
MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.Saya sekarang baru saja mencoba SvcTraceViewer.exe. Saya berhasil menangkap satu pengecualian di sisi klien. Saya lihat durasinya 1 menit. Melihat jejak sisi server, saya dapat melihat bahwa server tidak mengetahui pengecualian ini. Durasi maksimum yang bisa saya lihat adalah 10 detik.
Saya telah melihat koneksi database aktif yang digunakan exec sp_whodi server. Saya hanya punya sedikit (2-3). Saya telah melihat koneksi TCP dari satu klien menggunakan TCPview. Biasanya sekitar 2-3 dan saya telah melihat hingga 5 atau 6.
Sederhananya, saya bingung. Saya telah mencoba semua yang dapat saya temukan, dan pasti melewatkan sesuatu yang sangat sederhana yang dapat dilihat oleh seorang ahli WCF. Ini adalah firasat saya bahwa ada sesuatu yang memblokir klien saya di tingkat rendah (TCP), sebelum server benar-benar menerima pesan dan / atau ada sesuatu yang mengantri pesan di tingkat server dan tidak pernah membiarkan mereka memproses.
Jika Anda memiliki penghitung kinerja yang harus saya lihat, beri tahu saya. (harap tunjukkan nilai apa yang buruk, karena beberapa penghitung ini sulit untuk diuraikan). Juga, bagaimana saya bisa mencatat ukuran pesan WCF? Terakhir, apakah ada alat di sana yang memungkinkan saya untuk menguji berapa banyak koneksi yang dapat saya buat antara klien dan server saya (terlepas dari aplikasi saya)
Terima kasih atas waktunya!
Informasi tambahan ditambahkan pada 20 Juni:
Aplikasi WCF saya melakukan sesuatu yang mirip dengan berikut ini.
while (true)
{
Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
Step2GetWorkUnitFromServerViaWCF();
DoWorkLocally(); // takes 5-15minutes.
Step3SendBackResultsToServerViaWCF();
}
Menggunakan WireShark, saya melihat bahwa ketika kesalahan terjadi, saya memiliki lima transmisi ulang TCP diikuti oleh reset TCP di kemudian hari. Dugaan saya adalah RST datang dari WCF yang mematikan koneksi. Laporan pengecualian yang saya dapatkan berasal dari waktu habis Step3.
Saya menemukan ini dengan melihat aliran tcp "tcp.stream eq 192". Saya kemudian memperluas filter saya ke "tcp.stream eq 192 dan http dan http.request.method eq POST" dan melihat 6 POST selama streaming ini. Ini tampak aneh, jadi saya memeriksa dengan aliran lain seperti tcp.stream eq 100. Saya memiliki tiga POST, yang tampaknya sedikit lebih normal karena saya melakukan tiga panggilan. Namun, saya menutup koneksi saya setelah setiap panggilan WCF, jadi saya mengharapkan satu panggilan per aliran (tetapi saya tidak tahu banyak tentang TCP).
Menyelidiki lebih lanjut, saya membuang beban paket http ke disk untuk melihat apa yang disebut enam ini di mana.
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2
Dugaan saya adalah dua klien bersamaan menggunakan koneksi yang sama, itulah mengapa saya melihat duplikat. Namun, saya masih memiliki beberapa masalah lagi yang tidak dapat saya pahami:
a) Mengapa paket tersebut rusak? Kebetulan jaringan acak - mungkin? Muatan di-gzip menggunakan kode contoh ini: http://msdn.microsoft.com/en-us/library/ms751458.aspx - Mungkinkah kode tersebut terkadang bermasalah saat digunakan secara bersamaan? Saya harus menguji tanpa pustaka gzip.
b) Mengapa saya melihat langkah 1 & langkah 2 berjalan SETELAH waktu operasi yang rusak habis? Menurut saya, operasi ini seharusnya tidak terjadi. Mungkin saya tidak melihat aliran yang benar karena pemahaman saya tentang TCP cacat. Saya memiliki aliran lain yang terjadi pada saat yang bersamaan. Saya harus menyelidiki aliran lain - sekilas ke aliran 190-194 menunjukkan bahwa Step3 POST memiliki data muatan yang tepat (tidak rusak). Mendorong saya untuk melihat pustaka gzip lagi.