Antes de tudo eu gostaria de deixar bem claro que não sou nem um pouco à favor do uso de tecnologias velhas e ruins (pois há soluções infinitamente melhores) como o ASP clássico. Estou apenas apresentando uma possível solução para lidar com débito técnico de empresas como a Microsoft e com legado.

Agora vamos ao que interessa. Há algum tempo atrás estávamos com problemas constantes de performance em um dos sistemas da empresa onde trabalho. Nossos clientes utilizam este sistema e este problema estava gerando muita insatisfação em nossos clientes.

Por razões históricas o sistema é todo baseado em soluções Microsoft, sendo que boa parte dele foi desenvolvido em ASP clássico, e algumas pequenas partes mais recentes foram feitas em .NET.

Não só havíamos problemas de performance pelo crescimento agressivo no uso do sistema, como também estávamos no limite do escalonamento vertical. Não adiantava mais colocar mais CPUs, mais RAM, etc, simplesmente porque naturalmente o IIS não escala serviços ASP.

O sistema utilizava o mecanismo de sessão do IIS que é mantido em RAM. Isto obviamente tem uma grande vantagem sobre sistemas que gravam sessão em arquivos ou em banco de dados. No entanto, quando o uso do sistema atinge os limites impostos pela plataforma não havia muito a ser feito.

O modelo de serviço do IIS com o ASP clássico e as sessões em RAM força o administrador do sistema a utilizar apenas um único processo (worker) do IIS para servir todas as requisições de um determinado site.

Poderíamos ter tomado alguns outros rumos, mas, ou eles envolviam alterações drásticas no sistema ou não sabíamos o que esperar de determinadas alterações. Qualquer tipo de teste levaria meses para ser feito e tudo isto há um custo astronômico. Havia a possibilidade de migrar para plataforma 64 bits para permitir o IIS alocar mais do que 4GB de RAM para um único processo, mas mesmo com menos de 2GB de uso o processo já apresentava problemas. Outro problema de migrar para 64 bits seriam as dezenas de componentes nativos (OCX, etc) que eram utilizados. Não era simples testar todos eles e determinar se todos se comportariam como antes na plataforma nova ou até mesmo encontrar versões adequadas para a nova plataforma.

Também era possível quebrar todo o site em vários pequenos outros sites, mas isso envolveria a alteração em dezenas de milhares de linhas de código e pelas características do código legado fazer este tipo de alteração poderia sair mais caro do que refazer o site do zero utilizando outra tecnologia mais recente.

A solução mais simples seria parar de utilizar o mecanismo de sessão nativo do ASP e passar a gravar a sessão em algum outro local onde pudesse ser lido por todos os processos sem problemas de locking. Este local poderia ser um banco de dados relacional ou algo como um memcached. Antes de colocar a mão na massa eu dei uma boa vasculhada na Internet e acabei encontrando o componente ISP Session da holandesa ADC Cure. Sinceramente a aparência do site não me animou muito a confiar no componente, mas como não havia encontrado nada melhor, acabei dando uma oportunidade.

Num primeiro momento baixei a versão trial do componente e testei-o num ambiente de desenvolvimento. Em pouco tempo estava tudo funcionando e com a sessão no banco de dados! Aquilo me impressionou muito e deixou a equipe toda animada. Achamos uma solução rápida para nossa maior dor-de-cabeça dos últimos meses!

O componente não faz nenhuma magia negra. Seu funcionamento é relativamente simples. Seu segredo é desligar a opção “Save session state” do site ou do IIS inteiro (como quiser) e substituir o objeto Session com um novo, que faz 99% do que o objeto original faz, só que gravando todas as informações em um banco de dados SQL Server.

Apesar das perdas na performance do tratamento da sessão – afinal deixamos de gravar em RAM e passamos a gravar em BD – pudemos escalar o pool do site para ter vários processos (workers) e inclusive colocar mais de um servidor para termos redundância do sistema. Sem dúvida o custo/benefício desta solução é muito melhor do que qualquer outra solução que encontramos.

Aproveito para mencionar que o componente não é gratuito. Ele tem um custo, até que pequeno, considerando-se as perdas que a falta dele estavam causando e o custo das outras soluções.

Agora que seu site pode continuar no ar com o volume de acessos crescendo constantemente, coloque a mão na massa e comece a refazê-lo em alguma outra tecnologia como, por exemplo, Ruby on Rails.