I am working on a system where sometimes request/sec increase up to 680. It's a .NET 4.0 web api. In normal situations when requests are fewer, everything is fine, but sometimes when the number goes high database connectivity issues will happen and I can see the following error in log files

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - The wait operation timed out.)

Here are my web.config settings

Min Pool Size=50;Max Pool Size=101;
<serviceThrottling maxConcurrentCalls="100" />

Your help will be appreciated. I am new to ask question so please ignore if I did any mistake.

  • Have you checked this: support.microsoft.com/en-us/kb/2568167 TD;DR run: netsh WinSock Show Catalog > ws.txt and open WS.txt in a text editor and check if any Service Flags are not with the 20000 bit set (bascially lower than 20000) There could be simpler explanation try setting the service throttling to serviceThrottling to <maxConcurrentCalls="100" maxConcurrentInstances="100" maxConcurrentSessions="100" /> – Spörri Apr 29 '15 at 8:50
  • Thanks Spoorri for your comment. Service flags are all fine. Let me try the second solution <maxConcurrentCalls="100" maxConcurrentInstances="100" maxConcurrentSessions="100" /> – Muhammad Apr 29 '15 at 13:56
  • Sporri, I am facing same issue even after these settings. Let me give you some more useful info. The performance counter "Pipeline Instance Count" increases up to 500 pipes/sec and i am getting this DB error at the same time. Whenever this counter is less than 100 everything is fine but the moment this counter will have larger value, logs will show the same DB error. – Muhammad Apr 30 '15 at 13:18
  • I'm out on a limb here as I am not a developer but - Pipeline Instance Count -> The number of active request pipeline instances for the specified ASP.NET application. Since only one execution thread can run within a pipeline instance, this number gives the maximum number of concurrent requests that are being processed for a given application. In most circumstances it is better for this number to be low when under load.... So for me this looks to be on the on the application side. If the error is in the SQL Server error logs the web app is not finishing the login – Spörri Apr 30 '15 at 19:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.