Limit czasu żądania usług IIS w przypadku długich operacji ASP.NET

Występuje przekroczenie limitu czasu żądania z usług IIS, gdy wykonuję długą operację. Za kulisami moja aplikacja ASP.NET przetwarza dane, ale liczba przetwarzanych rekordów jest duża, dlatego operacja zajmuje dużo czasu.

Myślę jednak, że IIS przekroczył limit czasu sesji. Czy jest to problem z sesją usług IIS lub ASP.NET?

Z góry dziękuję

Jeśli chcesz wydłużyć dopuszczalny czas wykonywania skryptu ASP.NET, zwiększ Server.ScriptTimeoutwartość. Wartość domyślna to 90 sekund dla .NET 1.xi 110 sekund dla .NET 2.0 i nowszych.

Na przykład:

// Increase script timeout for current page to five minutes
Server.ScriptTimeout = 300;

Tę wartość można również skonfigurować w swoim web.configpliku w httpRuntimeelemencie konfiguracyjnym:

<!-- Increase script timeout to five minutes -->
<httpRuntime executionTimeout="300" 
  ... other configuration attributes ...
/>

Uwaga zgodnie z dokumentacją MSDN :

„Ten limit czasu ma zastosowanie tylko wtedy, gdy atrybut debugowania w elemencie kompilacji ma wartość False. Dlatego też, jeśli atrybut debug ma wartość True, nie trzeba ustawiać tego atrybutu na dużą wartość, aby uniknąć zamykania aplikacji podczas debugowania. "

Jeśli już to zrobiłeś, ale okazuje się, że sesja wygasa, zwiększ HttpSessionState.Timeoutwartość ASP.NET :

Na przykład:

// Increase session timeout to thirty minutes
Session.Timeout = 30;

Tę wartość można również skonfigurować w swoim web.configpliku w sessionStateelemencie konfiguracyjnym:

<configuration>
  <system.web>
    <sessionState 
      mode="InProc"
      cookieless="true"
      timeout="30" />
  </system.web>
</configuration>

Jeśli wykonanie skryptu trwa kilka minut i jest wielu jednoczesnych użytkowników, rozważ zmianę strony na stronę asynchroniczną . Zwiększy to skalowalność Twojej aplikacji.

Inną alternatywą, jeśli masz dostęp administratora do serwera, jest rozważenie tej długotrwałej operacji jako kandydata do wdrożenia jako zaplanowanego zadania lub usługi systemu Windows.

Świetna i wyczerpująca odpowiedź @Kev!

Ponieważ długo przetwarzałem tylko na jednej stronie administratora w aplikacji WebForms, użyłem opcji kodu. Ale aby umożliwić tymczasową szybką naprawę na produkcji, użyłem wersji config w <location>tagu w web.config. W ten sposób moja strona administracyjna / przetwarzająca miała wystarczająco dużo czasu, podczas gdy strony dla użytkowników końcowych i tym podobne zachowały swoje dawne zachowanie.

Poniżej podałem konfigurację dla pracowników Google, którzy potrzebują tej samej szybkiej poprawki. Należy oczywiście stosować inne wartości niż mój „4 godziny” przykład, ale DO uwagę, że sesja timeOutjest w ciągu kilku minut, podczas gdy wniosek executionTimeoutjest w kilka sekund!

I - ponieważ jest już 2015 - dla NON- quickfix powinieneś użyć async / await teraz .Net 4.5, jeśli to w ogóle możliwe, zamiast strony ASYNC .NET 2.0, która była najnowocześniejsza, gdy KEV odpowiedział w 2010 r. :).

<configuration>
    ... 
    <compilation debug="false" ...>
    ... other stuff ..

    <location path="~/Admin/SomePage.aspx">
        <system.web>
            <sessionState timeout="240" />
            <httpRuntime executionTimeout="14400" />
        </system.web>
    </location>
    ...
</configuration>

Publikuję to tutaj, ponieważ spędziłem nad tym 3 i 4 godziny i znalazłem tylko odpowiedzi takie jak te powyżej, które mówią, dodaj executionTime, ale to nie rozwiązuje problemu w przypadku, gdy używasz programu ASP .NET Core . W tym przypadku zadziałałoby:

W pliku web.config dodaj requestTimeoutatrybut w aspNetCorewęźle.

<system.webServer>
  <aspNetCore requestTimeout="00:10:00" ... (other configs goes here) />
</system.webServer>

W tym przykładzie ustawiam wartość na 10 minut.

Źródła: https://docs.microsoft.com/en-us/aspnet/core/hosting/aspnet-core-module#configuring-the-asp-net-core-module

Usuń ~znak w miejscu, więc

path="~/Admin/SomePage.aspx"

staje się

path="Admin/SomePage.aspx"