title: Timeout on long ASP.Net Operation, for some Users
body: <p>I have an application where it seems that for different users there is a different timeout and for some users the timeout is too soon.</p>
  
  <p>It is a C#/.NET application that runs an ASPX based Website. Basically, you fill out a form and click on submit and then must wait a few minutes and you get the results. When I am connected to the system and perform this action it takes around nine minutes and I see the results. </p>
  
  <p>But if another user performs this action after five minutes he gets displayed a “This page can’t be displayed” message in is browser (internet explorer –  the rest of the message is “<em>Make sure the web address http:// … is correct, Look for the page with bing, Refresh the page in a few minutes</em>”).</p>
  
  <p>A little more background:</p>
  
  <p>First the nine minutes seem long, but there is a huge amount of data (collection of datapoints over a span of a year) that is processed and displayed, and basically it works, so I don’t think it is necessary to discuss this point. For a lesser amount of data there are no problems.</p>
  
  <p>The data from the database is obtained via C# and it performs the queries to a MS SQL database. 
  First I thought it would help to set in the <code>web.config</code> in the <code>httpRuntime</code> tag the <code>executionTimeout</code> attribute. But the <code>compilation</code> tag has the <code>debug</code> flag set to true (and the application is deployed as release via visual studio on the server) – so the debug flag (as far I understand) overrides the executionTimeout anyways. </p>
  
  <p>The Server on which the application is running is Windows Server 2012 R2 and for the site I also set under IIS in the advanced settings in the behavior / limits area the connection timeout on a higher value. But this hasn’t any effect.</p>
  
  <p>I think I am missing some point, because as far I understand the deployed application doesn’t have any timeouts set (because of the debug flag) and this behavior seems user specific. 
  Do you have any hints or ideas where I can look for?</p>
  
  <p><strong>Edit</strong>
  In the comments was suggested to check the SQL Server logs for errors, the log was error free.</p>