IIS7 üzerinde çalışan bir WCF hizmetine (* .svc) ve hizmeti sorgulayan çeşitli istemcilere sahip bir uygulamamız var. Sunucu, Win 2008 Sunucusunu çalıştırıyor. İstemciler Windows 2008 Sunucusu veya Windows 2003 sunucusu çalıştırıyor. Aslında çok sayıda potansiyel WCF sorunuyla ilgili olabileceğini gördüğüm aşağıdaki istisnayı alıyorum.
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.
Zaman aşımını 30 dakikaya çıkardım ve hata hala devam ediyor. Bu bana başka bir şeyin işin başında olduğunu söylüyor çünkü veri miktarının yüklenmesi veya indirilmesi asla 30 dakika süremez.
Hata gelir ve gider. Şu anda daha sık. Aynı anda çalışan 3 istemcim veya 100'üm olması önemli görünmüyor, yine de arada bir oluyor. Çoğu zaman zaman aşımı olmuyor ama yine de saatte birkaç tane alıyorum. Hata, çağrılan yöntemlerin herhangi birinden gelir. Bu yöntemlerden birinin parametresi yoktur ve bir bit veri döndürür. Bir diğeri parametre olarak çok fazla veri alır ancak eşzamansız olarak çalışır. Hatalar her zaman istemciden kaynaklanır ve yığın izlemede sunucudaki herhangi bir koda asla başvurmaz. Her zaman şu şekilde biter:
at System.Net.HttpWebRequest.GetResponse()
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
Sunucuda: Aşağıdaki bağlama ayarlarını denedim (ve şu anda var):
maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"
Etkisi yok gibi görünüyor.
Aşağıdaki kısıtlama ayarlarını denedim (ve şu anda var):
<serviceThrottling maxConcurrentCalls="1500" maxConcurrentInstances="1500" maxConcurrentSessions="1500"/>
Etkisi yok gibi görünüyor.
Şu anda WCF hizmeti için aşağıdaki ayarlara sahibim.
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]
ConcurrencyMode.MultipleBir süre koştum ve hata hala devam etti.
IIS'yi yeniden başlatmayı, temeldeki SQL Server'ımı yeniden başlatmayı ve makineyi yeniden başlatmayı denedim. Tüm bunların bir etkisi yok gibi görünüyor.
Windows güvenlik duvarını devre dışı bırakmayı denedim. Etkisi yok gibi görünüyor.
İstemcide şu ayarlara sahibim:
maxReceivedMessageSize="2147483647"
<system.net>
<connectionManagement>
<add address="*" maxconnection="16"/>
</connectionManagement>
</system.net>
Müşterim bağlantılarını kapatıyor:
var client = new MyClient();
try
{
return client.GetConfigurationOptions();
}
finally
{
client.Close();
}
Daha fazla giden bağlantıya izin vermek için kayıt defteri ayarlarını değiştirdim:
MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.
Son zamanlarda SvcTraceViewer.exe'yi denedim. Müşteri tarafında bir istisna yakalamayı başardım. Süresinin 1 dakika olduğunu görüyorum. Sunucu tarafı izine baktığımda, sunucunun bu istisnadan haberdar olmadığını görebiliyorum. Görebildiğim maksimum süre 10 saniyedir.
exec sp_whoSunucuda kullanarak aktif veritabanı bağlantılarına baktım . Bende sadece birkaç tane var (2-3). TCPview kullanarak bir istemciden gelen TCP bağlantılarına baktım. Genellikle 2-3 civarında ve 5 veya 6'ya kadar gördüm.
Basitçe söylemek gerekirse, şaşkınım. Bulabildiğim her şeyi denedim ve bir WCF uzmanının görebileceği çok basit bir şeyi kaçırıyor olmalıyım. Sunucu gerçekten mesajı almadan önce bir şeyin müşterilerimi düşük seviyede (TCP) engellediğini ve / veya bir şeyin mesajları sunucu seviyesinde kuyruğa aldığını ve asla işlemelerine izin vermediğini hissettim.
Bakmam gereken performans sayaçlarınız varsa lütfen bana bildirin. (Bu sayaçlardan bazılarının şifresini çözmek zor olduğundan, lütfen hangi değerlerin kötü olduğunu belirtin). Ayrıca, WCF mesaj boyutunu nasıl kaydedebilirim? Son olarak, istemcim ve sunucum arasında kaç bağlantı kurabileceğimi test etmeme izin verecek herhangi bir araç var mı (uygulamamdan bağımsız olarak)
Zaman ayırdığınız için teşekkürler!
Ekstra bilgiler 20 Haziran'da eklendi:
WCF uygulamam aşağıdakine benzer bir şey yapıyor.
while (true)
{
Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
Step2GetWorkUnitFromServerViaWCF();
DoWorkLocally(); // takes 5-15minutes.
Step3SendBackResultsToServerViaWCF();
}
WireShark'ı kullanarak, hata oluştuğunda, beş TCP yeniden aktarımım olduğunu ve ardından daha sonra bir TCP sıfırlamasının olduğunu gördüm. Tahminimce RST, bağlantıyı kesen WCF'den geliyor. Aldığım istisna raporu 3. Adımda zaman aşımına uğradı.
Bunu "tcp.stream eq 192" tcp akışına bakarak keşfettim. Daha sonra filtremi "tcp.stream eq 192 ve http ve http.request.method eq POST" olarak genişlettim ve bu akış sırasında 6 POST gördüm. Bu garip göründü, bu yüzden tcp.stream eq 100 gibi başka bir akışla kontrol ettim. Üç POST'um vardı, bu biraz daha normal görünüyor çünkü üç arama yapıyorum. Ancak, her WCF çağrısından sonra bağlantımı kapatıyorum, bu nedenle akış başına bir çağrı bekliyordum (ancak TCP hakkında fazla bir şey bilmiyorum).
Biraz daha araştırarak, http paket yükünü diske atarak bu altı kişinin neyi nerede aradığına baktım.
1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2
Tahminime göre iki eşzamanlı istemci aynı bağlantıyı kullanıyor, bu yüzden kopyalar gördüm. Ancak, hala anlayamadığım birkaç sorun daha var:
a) Paket neden bozulmuş? Rastgele ağ şansı - belki? Yükleme, bu örnek kod kullanılarak gzip ile sıkıştırılır: http://msdn.microsoft.com/en-us/library/ms751458.aspx - Kod, aynı anda kullanıldığında arada bir hatalı olabilir mi? Gzip kitaplığı olmadan test etmeliyim.
b) Bozuk işlem zaman aşımına uğradıktan SONRA neden 1. ve 2. adımın çalıştığını görüyorum? Bana öyle geliyor ki bu operasyonlar olmamalıydı. Belki doğru akışa bakmıyorum çünkü TCP anlayışım kusurludur. Aynı anda gerçekleşen başka akışlarım var. Diğer akışları araştırmalıyım - 190-194 akışlarına hızlı bir bakış, Adım 3 POST'un uygun yük verilerine sahip olduğunu (bozuk değil) gösterir. Beni gzip kitaplığına tekrar bakmaya zorluyor.