Eu tenho um aplicativo ASP Classic que é executado atualmente no IIS6, mas muitas vezes, devido ao programador original não seguir as "melhores práticas", este aplicativo lança um erro de falta de memória após várias horas.
Originalmente, eu tinha perguntado a esta questão no StackOverflow em referência ao problema original .
As soluções ideais seriam migrar o aplicativo para o .NET ou solucionar o código bruto para encontrar o vazamento de memória e resolvê-lo. No entanto, existem quase um milhão de linhas de código ... e demorou para encontrar vários problemas e consertá-los, e é necessário mais tempo para encontrar mais vazamentos de memória.
Minha pergunta é: O IIS7 lidaria com o uso da memória do VBScript melhor ou mais eficientemente do que o IIS6, o que seria uma melhoria? Vale a pena migrar o aplicativo para o IIS7 para ajudar a aliviar esse problema? Obviamente, todo o problema não desapareceria, pois ainda há vazamentos, mas isso melhoraria?
O aplicativo está sendo executado no Windows Server 2003.
Seria mais demorado se você mudasse para x64. Poderia usar o máximo de memória que você pudesse usar antes de explodir. No x86, você provavelmente não alcançaria o limite de processo de 2 GB antes de explodir. Em seguida, você pode reciclar o pool de aplicativos com menos frequência e, com sorte, depois de algumas horas, quando menos usuários são afetados.
Mas "manipula o VBScript melhor ou mais eficientemente"? Não.
A migração pode ser mais problemática do que vale a pena. O IIS 6 tem basicamente as mesmas opções de reciclagem que o 7, e é provavelmente o que eu consideraria primeiro na sua situação.
Se estiver vazando memória, você pode implementar a reciclagem baseada no limite de memória.
Por exemplo: se o aplicativo eventualmente exibir 800 MB de bytes particulares, ele será reciclado. (Reciclagem cria um novo processo para substituir o antigo, depois termina o antigo).
Se o seu aplicativo não responder mal à reciclagem (a reciclagem causa uma perda de estado, por exemplo, estado da sessão, variáveis na memória, etc.), isso pode ser uma boa opção. Se ele é sem estado, você também pode olhar para configuração maxprocesses > 1 (um "web garden"), que teoricamente multiplicaria o tempo antes da falha pelo número de processos de trabalho. (isso assume que você tem n * 2GB de RAM para jogar nele)
Em caso afirmativo, seu aplicativo tem uma vida útil definida, implementando um intervalo de reciclagem mais curto do que aquele que funcionaria (por exemplo, reciclar a cada 1 hora).