Pois é, resolvi mudar o endereço blog. A partir de agora os artigos estarão em https://blogs.msdn.com/b/teixeira

Logo logo trago novidades… só para atiçar a curiosidade, vou começar postar em breve uns artigos com dicas rápidas para otimizar o tempo de carregamento de páginas do seu site.

Abraços,

Paulo.

Observe que o .NET Framework 1.1 somente foi testado com o Windows 7 32-bits. Há relatos disponíveis na internet atestando que o mesmo pode ser instalado em versões 64 bits. Todavia, a Microsoft não realizou testes de regressão com o .NET Framework 1.1 no Windows 7 64bits ou no Windows 2008 R2.

Na prática isso significa que caso você instale o framework 1.1 num desses sistemas, ele poderá não funcionar da forma esperada, apresentado erros “inexplicáveis”. Também significa que se você tiver um contrato de suporte diretamente com a Microsoft (Suport Premier), este cenário não se enquadrará nas políticas de suportabilidade cobertas pelo seu contrato, e portanto, não será dada sequência a investigação da causa-raiz do problema pelo qual você estará passando.

Abraços,

Paulo.

Update: agora temos um artigo falando sobre o tema: “.NET Framework 1.1 not supported on Windows 7 nor Windows Server 2008 R2” https://support.microsoft.com/kb/2489698

Continuando a nossa série, vamos agora para a parte mais interessante. Após a configuração do ARR com Shared Configuration e Offline Files, estamos prontos para migrar as aplicações dos servidores antigos para o novo ambiente IIS7, de forma transparente para o usuário final. O objetivo principal é fazer o balanceamento de acordo com a URL chamada. Por exemplo, se você abrir o navegador colocando o endereço www.contoso.com/app1 o ARR deverá direcionar o tráfego para um certo conjunto de servidores antigos (por exemplo com IIS5 ou 6), mas se você usar www.contoso.com/app2, o ARR direciona o tráfego para outros servidores já com IIS7. Com isso, você terá tempo de homologar cada uma das suas aplicações e migrá-las de forma controlada, sem ter que arriscar uma migração de todos os servidores/sites em um único passo.

Para atingir este objetivo, vamos configurar dois WebFarms nos seus servidores ARR, sendo:

• Um webfarm com servidores antigos (IIS5, IIS6, Apache, ou qquer outro webserver)
• Um webfarm com os novos servidores IIS7 para os quais as aplicações serão migradas.

Para criar os farms, no nó “Server Farms” do IIS Manager do servidor ARR-1, clica-se com o botão direito e seleciona-se “Create Server Farm”, e definindo um nome para o primeiro farm (aqui chamado de ANTIGO). O IIS Manager irá perguntar se é necessário criar uma regra para direcionar todos os requests para este farm automaticamente. Como este é o farm que conterá a maioria das aplicações (ainda não homologadas para o ambiente com IIS7), deve-se permitir a criação da regra (clicando no botão “Yes”).

Em seguida, deve-se adicionar cada um dos servidores no nó “Servers”.

Repete-se então o processo de criação para o segundo farm (chamado de “NOVO”) mas desta vez não cria-se a regra para direcionar todos os requests para o farm, visto que somente algumas aplicações (já homologadas para o IIS7) serão direcionadas ao mesmo. Também não se esqueça de adicionar os servidores correspondentes no nó “Servers”.

Criação das Regras do Proxy Reverso

Ao se criar o primeiro farm (ANTIGO), também foi criada automaticamente uma regra que irá redirecionar todo o tráfego para o mesmo. A regra fica armazenada no arquivo applicationHost.config na pasta compartilhada do Shared Configuration. A seção que contém esta configuração é chamada <globalRules>. A seguir, um exemplo desta seção:

<system.webServer>
<rewrite>
<globalRules>
<clear />
<rule name="ARR_Antigo_loadbalance" patternSyntax="ECMAScript" stopProcessing="true">
<match url=".+" />
<action type="Rewrite" url="https://Antigo/{R:0}" />
</rule>
</globalRules>
</rewrite>
</system.webServer>

Note que, no exemplo acima, a regra foi mudada para utilizar expressões regulares ao invés de caracteres curinga (wildcards).

Uma vez que esta regra já está criada, deve-se então criar regras para direcionar cada uma das aplicações já homologadas para o farm NOVO. Para fazer isso, no IIS Manager, clica-se no farm NOVO e em seguida no painel direito, seleciona-se “Routing Rules”.

No painel central, marca-se a opção “Use URL Rewrite to inspect incoming requests” e em seguida, no painel da esquerda, clica-se em “Apply”. Nesse momento, uma nova regra similar a do farm ANTIGO é criada mas a mesma necessita alguns ajustes.

No painel da esquerda, em “Advanced Routing”, clica-se em “URL Rewrite” para abrir as regras já criadas. Edita-se a nova regra ARR_NOVO_LOADBALANCE recém-criada, para ajustar os seus parâmetros.

Esta regra deverá utilizar expressões regulares, e ao invés de fazer o match para todos os requests, somente aqueles direcionados a aplicação em questão é que devem ser atendidos. A figura a seguir ilustra a configuração da regra criada:

Note que o pattern foi ajustado para combinar com a URL da aplicação que irá fazer parte do balanceamento.

Um aspecto importante é que, para cada aplicação a ser balanceada, uma regra como esta deverá ser criada. Ao final, existirão N regras distintas, correspondendo a cada uma das aplicações direcionadas para o farm com IIS7.

Para concluir, as regras devem ser ajustadas para obedecer uma certa precedência: as regras mais “acima” na janela do URL Rewrite são processadas primeiramente. Assim, a última regra deve ser a que direciona todos os requests para o farm ARR_ANTIGO. É possível ajustar a precedência das regras e também outros detalhes como o nome das mesmas.

É isso ai! Agora você consegue migrar suas aplicações de forma tranquila, sem o risco de um upgrade as escuras.

Ok, no post anterior desta série nós configuramos dois servidores IIS com ARR para utilizar o recurso de configuração compartilhada (Shared Configuration).

Com isso, os servidores ARR irão sempre “buscar” a sua configuração no share de rede que foi especificado. Então vem a pergunta de sempre: mas e se o compartilhamento ficar indisponível?

Realmente, problemas sérios podem ocorrer caso se esteja usando o Shared Configuration e o compartilhamento onde está armazenada a informação de configuração falhe. No momento que o compartilhamento está inacessível, os servidores no Farm recebem uma notificação e o serviço Web será interrompido em todo o farm (o que eu tenho certeza, não é algo que você iria desejar).

Bom, para evitar este problema, existem algumas alternativas, dentre elas o uso de um servidor de arquivos em Cluster, utilização de replicação do conteúdo via DFS-R, ou o uso de Offline Files.

Esta ultima opção, apesar de aparentemente simples, é uma das mais eficientes e atende as os requisitos, e portanto é a que vamos usar aqui.

Para habilitar o Offline Files, o compartilhamento no servidor ARR-1 deve estar configurado com o “Caching” habilitado, como já configurado no Passo 1 da configuração do recurso Shared Configuration descrito no meu post anterior.

No servidor ARR-2, o recurso “Desktop Experience” deve estar instalado, pois ele é necessário para configurar os “Offline Files” (somente após a sua instalação aparece o ícone no painel de controle). Então vamos lá, para configurar os “Offline Files”, deve-se executar os seguintes passos: Passo 1: Habilitar o Offline Files no painel de controle do servidor ARR-2. No painel de controle e selecione “Offline Files”; em seguida, clique no botão “Enable Offline Files”. O sistema irá solicitar um restart, mas antes de prosseguir, é necessário ajustar o cache para que o mesmo seja somente-leitura.

Passo 2: Colocar o cache como somente-leitura

Através de um prompt de comando e emite-se o seguinte comando:
REG ADD "HKLM\System\CurrentControlSet\Services\CSC\Parameters"
/v ReadOnlyCache /t REG_DWORD /d 1 /f

Em seguida, reinicia-se o servidor.

Passo 3: Habilitar o cache para a pasta com os arquivos do Shared Configuration no servidor ARR-2.

Após reiniciar o servidor ARR-2, deve-se conectar no compartilhamento de arquivos no servidor ARR-1 e, clicando com o botão direito sobre o mesmo, selecionar a opção “Always Available Offline”. Para confirmar se a configuração foi realizada com sucesso, abre-se o Sync Center no painel de controle. No Sync Center também é possível estabelecer uma agenda de sincronização personalizada (o padrão é ocorrer uma sincronização por dia, mas é possível ajustar para a mesma para atender os requisitos de negócio).

Referências adicionais:

“Setting up Shared configuration on IIS 7.0” https://blogs.iis.net/wonyoo/archive/2009/01/12/setting-up-shared-configuration-on-iis-7-0.aspx

Já estamos chegando ao final desta série, e a melhor parte está chegando. 
Fique ligado!

E esta acaba sendo sempre a resposta que todos nós costumamos ouvir quando se fala sobre aplicação de hotfix e/ou patches em produção.

O problema com isso é que cada um faz o que quer. Mas existe um guia (em inglês) disponível falando como montar um processo para atualização de hotfixes e patches (de segurança, mas que você pode aplicar para tudo).

Para conhecer mais, baixe Microsoft Security Update Guide: https://www.microsoft.com/downloads/details.aspx?FamilyID=c3d986d0-ecc3-4ce0-9c25-048ec5b52a4f&displaylang=en

Abraços,

Paulo.

No meu post anterior falei como instalar o IIS e o ARR para criar uma solução que permita a migração transparente de aplicações de um ambiente “antigo” para o IIS7.x. Um ponto importante nesta configuração é que os dois servidores devem possuir exatamente a mesma configuração, ou inconsistências podem ocorrer ao processar as requisições nos servidores ARR.

O IIS7.x felizmente possui um recurso que permite em manter todos os arquivos de configuração do IIS em um único local de rede compartilhado por todos os servidores do WebFarm, chamado de Shared Configuration. Esta configuração é necessária para que ambos os servidores utilizem sempre o mesmo conjunto de regras de rotamento para os requests, evitando inconsistências.

UPDATE (09/02/2013): o Shared Configuration não é requerido para o ARR funcionar. Se você estiver usando um único servidor poderá seguir sem utilizá-lo, mas se tiver dois ou mais servidores é recomendado que faça uso deste recurso.

Os seguintes passos são requeridos para essa configuração:

Passo 1: Criação de pasta compartilhada no Servidor ARR-1:

Para habilitar o Shared Configuration, uma pasta compartilhada na rede deve ser criada em um servidor de arquivos, ou em um dos servidores Web com o ARR. Para facilitar o gerenciamento, optamos por criar a pasta compartilhada (SHAREDCONFIG) em um dos servidores ARR.

A pasta compartilhada deve atender os seguintes requisitos:

• deve possuir o “Caching” habilitado (no próximo post explicarei mais detalhes deste requisito);
• deve ter assignado um usuário com direitos de escrita na mesma.

Para atender estes requisitos, cria-se um usuário local nos dois servidores ARR com o mesmo nome de login e mesma senha, ou usa-se uma conta de domínio para atribuir as permissões no share. Também configura-se o “Caching” do compartilhamento conforme as figuras a seguir:

Passo 2: Exportação da configuração do IIS para a pasta compartilhada no servidor ARR-1.

No servidor ARR1, utilizando a console de gerenciamento do IIS, deve ser exportada a configuração do IIS para a pasta compartilhada criada no passo 1. Antes de exportar a configuração é necessário certificar-se que o usuário criado possui permissões de escrita tanto no compartilhamento de rede quanto no sistema de arquivos NTFS. Se o mesmo não possuir permissões adequdas, uma mensagem de erro será exibida.

Passo 3: Configuração do Shared Configuration nos servidores ARR-1 e ARR-2

No servidor ARR-1, utilizando a console de gerenciamento do IIS, deve-se configurar o recurso de Shared Configuration. Para isso, utiliza-se o compartilhamento de rede criado no servidor próprio ARR‑1. Deve-se repetir os mesmos passos no servidor ARR-2.

Importante:

Após configurar o recurso de Shared Configuration, as alterações de configuração realizadas em um dos servidores serão aplicadas a todos os membros do farm (no nosso caso, ARR-1 e ARR-2). Para instalar novos pacotes do IIS (por exemplo, suporte a ASP, ASP.NET ou outro qualquer), deve-se desabilitar o recurso de Shared Configuration dos dois servidores. Em seguida, o pacote deve ser instalado individualmente em cada servidor. Deve-se repetir os três passos descritos acima. A não observância deste procedimento poderá levar a inconsistências de configuração em um dos servidores do farm.

Referências adicionais:

https://learn.iis.net/page.aspx/264/shared-configuration/

A gente continua em breve.

Paulo.

Vários de nossos clientes encontram dificuldades para migrar os seus servidores e aplicações do IIS5 ou IIS6 para novos servidores baseados no IIS7.x (ou do PHP rodando no Linux/Unix para o IIS7). O grande problema é a dificuldade de homologar divervas aplicações e colocá-las todas em produção em poucos dias.

Na prática, para implementar tal solução é necessário ter um mecanismo que permita a homologação e migração gradual das aplicações para um novo ambiente de forma transparente para os seus usuários.

Muitos desses clientes já possuem um equipamento capaz de realizar o balanceamento de carga na camada 3 (camada de rede), mas para atingir esse objetivo é necessário implementar um balanceamento na camada de aplicação (protocolo HTTP, camada 7) que seja capaz de interpretar os requests e redirecionar o tráfego para os servidores apropriados.

Para atender felizmente contamos com um novo componente OOB do IIS7, o Application Request Routing (ARR) que é capaz cumprir esta tarefa. Lembrando que vamos usar o termo ARR mas na realidade estamos falando de um servidor Web IIS especializado (que não irá servir páginas diretamente, e sim fazer um “proxy-reverso” para outros servidores Web. Os servidores Web que hospedam o conteúdo podem ser de quaisquer versões ou plataformas (você pode ter até um Apache rodando em Linux e usar o ARR para fazer esse roteamento das aplicações). Vou descrever como montar esta solução nos meus próximos posts, e vamos começar pelo básico: a instalação do IIS e do ARR:

Instalação do IIS

Vamos começar com um laboratório onde instalamos dois servidores Windows 2008 R2 x64 em ambiente virtual (Hyper-V), para posterior configuração do Application Request Routing, chamados aqui de de ARR-1  e ARR-2. Note que recomendo que em um ambiente de produção real, sejam utilizados servidores físicos para esta função (afinal, quando é que você iria virtualizar os seus balanceadores de carga de hardware que possui hoje?)

Os servidores IIS devem possuir os requisitos mínimos necessários. A instalação do IIS restringi-se somente aos componentes descritos conforme a listagem a seguir:

·         IIS-CommonHttpFeatures

·         IIS-StaticContent

·         IIS-DefaultDocument

·         IIS-HttpErrors

·         IIS-HttpRedirect

·         IIS-HealthAndDiagnostics

·         IIS-HttpLogging

·         IIS-LoggingLibraries

·         IIS-RequestMonitor

·         IIS-HttpTracing

·         IIS-Security

·         IIS-RequestFiltering

·         IIS-IPSecurity

·         IIS-Performance

·         IIS-HttpCompressionStatic

·         IIS-HttpCompressionDynamic

Para fazer a instalação do IIS 7.5 via prompt de comando, utilizamos o seguinte comando:

start /w pkgmgr /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-HttpErrors;IIS-HttpRedirect;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-Security;IIS-IPSecurity;IIS-RequestFiltering;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementScriptingTools;WAS-WindowsActivationService;WAS-ProcessModel;IIS-NetFxExtensibility;WAS-NetFxEnvironment;WAS-ConfigurationAPI;IIS-ManagementService

Para confirmar via prompt de comando se a instalação ocorreu conforme o esperado utilizamos o seguinte comando:

Servermanagercmd.exe /query

Além disso, foi necessário instalar o Feature “Desktop Experience”, requirido posteriormente para a configuração do recurso de Offline Files (depois explico por que isso é necessário). Para instalar este componente via prompt de comando, utilizamos o seguinte:

start /w pkgmgr.exe /iu:Desktop-Experience

Instalação do Application Request Routing (ARR).

O Application Request Routing (ARR) é um component OOB (Out-of-Box) que deve ser baixado do site da Microsoft ou do IIS.NET. Para fazer download do mesmo, basta utilizar o seguinte endereço:

https://www.iis.net/downloads/category/handle-requests 

No próximo post, vou continuar descrevendo como montarmos a estrutura necessária para migrar aplicações de um ambiente IIS5/6 para o IIS7 de forma transparente para o usuário final.

Vejo vocês logo!

Paulo.

UPDATE (09/02/2013): Links para download do ARR foram atualizados, algumas referências às versões RC dos pacotes citados anteriormente foram removidos.

Convenhamos, é horrível. Pois bem, o pessoal do MS Research tem um projeto que substitui essas imagens por algo que somente nós, humanos, somos capazes de fazer (e de quebra é divertido). Trata-se da nossa capacidade de identificar (corretamente) cães e gatos. É isso mesmo! O projeto ASIRRA (Animal Species Image Recognition for Restricting Access) oferece um conjunto de APIs (WebServices) que você pode adicionar ao seu site e que ao invés de usar imagens como a acima, usa fotos de cães e gatos, e pede que nós os identifiquemos. O mais interessante é que muito difícil que uma imagem de um cão, ou gato, se repita: são 3 milhões de imagens diferentes. Vale a pena dar uma olhadinha: https://research.microsoft.com/asirra.

Paulo.

"Let's rock". Um argumento a menos!

Para começar e antes de tudo, acho que vale fazer uma distinção importante aqui:

Causa: do Lat. Causa, s. f., aquilo ou aquele que ocasiona um acontecimento ou faz que uma coisa exista; princípio; origem; motivo, razão, pretexto; partido.

Efeito: do Lat. Effectu, s. m., resultado, consequência; produto de uma causa; fim; destino; aplicação; eficácia; execução, realização; cumprimento; impressão moral, sensação; Fís., fenomeno de particular importância produzido por uma causa bem determinada.

A nossa experiência no suporte Microsoft tem nos mostrado que confundir causa e efeito é algo muito comum. Eu pessoalmente sou muito cético quando se atribui a causa ao SQL Server ou ao IIS quando há problemas em um ambiente Web. Isso porque, em geral, tanto SQL quanto o IIS sofrem os efeitos de aplicações mal comportadas. Se uma aplicação faz uso incorreto de memória ou de outros recursos do sistema, em geral, os efeitos aparecem no IIS. Se a aplicação faz uso de queries de forma inadvertida ou tem um modelo de dados inadequado, em geral, os efeitos aparecem no SQL.

Com base nessa experiência iniciei o meu trabalho atacando exatamente a minha área de atuação, ou seja, a configuração do servidor IIS. O servidor em questão era baseado no Windows 2003 SP1 com IIS6.

Como sempre, o primeiro passo foi olhar os contadores de performance para avaliar se o equipamento estava bem dimensionado e se havia algum gargalo. Os contadores básicos do S.O. são aqueles relacionados a CPU, disco, rede e memória. Infelizmente (ou felizmente) já de início foi possível descartar a existência de gargalos; a máquina estafa “sobrando”. Porém algo que as vezes passa desapercebido me chamou a atenção: o consumo de memória de um Worker Process do IIS6.... mas vamos guardar essa informação para logo mais.

Também olhei o log de eventos de aplicação. Por incrível que pareça é possível contar nos dedos os administradores que realmente olham e dão importância aos logs do sistema. E ai cabe um puxão de orelha: isso quase sempre só acontece com administradores Windows. Se pegaramos os administradores Unix facilmente encontraremos um que regularmente dá uma “olhadela” no syslog.

Pois bem, no log de aplicações encontrei algo semelhante ao descrito abaixo:

8/20/2007 4:49:39 PM Active Server Pages Warning None 9 N/A SERVER_01 Warning: 500 Server Error. .
8/20/2007 4:49:25 PM Active Server Pages Warning None 9 N/A SERVER_01 Warning: File /search_payment.asp Line 29 Type mismatch: 'fValidateC'. .
8/20/2007 4:48:58 PM Active Server Pages Warning None 9 N/A SERVER_01 Warning: File /basket_001.asp Line 33 Type mismatch: 'oBasket.Item(...)'. .
8/20/2007 4:48:48 PM Active Server Pages Warning None 9 N/A SERVER_01 Warning: File /finalizebuy01_.asp Line 304 Type mismatch: 'oBasket.Item(...)'. .

Obviamente, por essas entradas, fica claro que a aplicação estava apresentando problemas. Havia pelo menos três tipos distintos de erros, e nesse instante não havia mais como descartar que o SQL poderia estar sofrendo efeitos de uma aplicação mal comportada. Ainda assim não havia nenhuma relação comprovada entre esses erros e o consumo de 100% CPU no banco de dados.

A primeira coisa que me ocorreria é tentar capturar mais informações no instante em que esses erros estavam ocorrendo, ou no instante que a CPU no banco estivesse em 100%. Seria possível capturar facilmente esses erros gerando um dump de memória utilizando o utilitário Debug Diagnostics, também conhecido como DebugDiag (que pode ser baixado do www.microsoft.com/downloads).

Entretando isso simplesmente não era possível nesse caso. O porquê? Dois fatores contribuiram para tornar isso impossível:

a) a aplicação era crítica para o cliente (uma solução de comércio eletrônico);
b) o consumo de memória do Worker Process responsável por processar a aplicação;

Como citei há pouco, não havia gargalos no ambiente. De fato, o uso de memória física estava muito baixo. Mas então qual era o problema com o Worker Process? O problema estava exatamente no consumo de memória virtual ou melhor, do espaço de endereços de memória virtual. Usando o contador Process\Virtual Bytes do performance monitor notei que a instância do W3WP.EXE que executava a aplicação ocupada 1.8Gb de memória virtual!! Isso realmente é algo MUITO além do normal (em geral uma aplicação “bem comportada” costuma consumir menos que 1Gb de memória virtual).

E qual o problema de usar o Debug Diagnostics? Ao se gerar um dump de memória, o DebugDiag (e qquer outro debugger) irá criar um arquivo cujo tamanho final será muito próximo ao tamanho de memória virtual utilizada pelo processo (no nosso caso, 1.8Gb). Infelizmente, gerar um arquivo desse tamanho pode ser uma tarefa bem demorada, mesmo em um equipamento adequado.

Apesar de não poder gerar o dump de memória, esse consumo excessivo de memória também me apontou para algumas possibilidades interessantes em relação a causa do problema. Infelizmente a ausência do dump também me deixava somente no terreno das possibilidades (ou das incertezas) e uma outra abordagem se fazia necessária. Como identificar a origem dos problemas da aplicação? Como encontrar uma correlação entre os problemas na aplicação e os efeitos no banco de dados?

A única solução possível foi fazer uma revisão estática de código (popularmente chamado "Code Review").  Antes que alguém pergunte, fazer isso numa aplicação que tem 1000 páginas é inviável. E esse era o caso. Todavia, sabemos que "estatisticamente" o código costuma apresentar um padrão de desenvolvimento, ou seja, se há algo errado, o erro costuma ser repetido em diversos locais do código. Também sabemos que a regra 80/20 costuma se aplicar, ou seja, em 20% das páginas estão concentrados 80% dos problemas mais críticos da aplicação. Por isso o nosso objetivo em um Code Review (executado com uma visão de Suporte) é atacar extamente esses 20% de código.

O primeiro passo então é definir o nosso escopo (os 20%), e isso é feito através da análise de logs do IIS. Através do uso do LogParser, conseguimos identificar as TOP páginas com Erros 500, e também as páginas com maior tempo de duração. O Code Review é realizado com foco nessas páginas. Como fazer isso?

# maior número de hits
logparser "SELECT TOP 20 cs-uri-stem as URI, count(*) as Hits, AVG(time-taken) as AvgTimeTaken, AVG(sc-bytes) As AvgSentBytes, AVG(cs-bytes) as AvgRecvBytes FROM ex*.log ORDER BY Hits DESC GROUP BY cs-uri-stem"
#maior tempo gasto
logparser "SELECT TOP 20 cs-uri-stem as URI, count(*) as Hits, AVG(time-taken) as AvgTimeTaken, AVG(sc-bytes) As AvgSentBytes, AVG(cs-bytes) as AvgRecvBytes FROM ex*.log ORDER BY AvgTimeTaken DESC GROUP BY cs-uri-stem"
# páginas com erros 500, ordenadas pelo número de hits
logparser "SELECT TOP 20 cs-uri-stem as URI, count(*) as Hits, AVG(time-taken) as AvgTimeTaken, AVG(sc-bytes) As AvgSentBytes, AVG(cs-bytes) as AvgRecvBytes FROM ex*.log WHERE sc-status =  500 ORDER BY Hits DESC GROUP BY cs-uri-stem"

Com essas queries do logparser conseguimos identificar o nosso conjunto de páginas. Após isso, basta fazer uso de um pouco de experiência  (e algumas referências que listo abaixo) para varrer o código e encontrar (se houver) os principais problemas da aplicação. Para resumir o resultado do trabalho, após a análise do código das páginas, o que foi encontrado foi o seguinte:

• Diversos problemas em relação ao mecanismo de acesso à dados utilizado, causados pela falta de padronização no acesso ao banco de dados. Estavam sendo usadas queries “ad-hoc”, stored procedures, updatable client-side cursors e instruções SQL DML na atualização dos dados, algumas vezes diretamente a partir do código ASP e outras vezes com o auxilio de um componente COM, ou seja, uma tríade de mecanismos para acesso à dados.
• O sistema armazenava um non-agile object em uma variável de sessão para um dos processos mais importanes do site (a cesta de compras).
• O cache estava desabilitado programaticamente em praticamente 80% do código da aplicação (o que revela também uma falta de padronização ao se desenvolver o código - afinal, se houvesse padrão ou seria tudo, ou nada habilitado).
• A forma com que o código foi criado e estava organizado gerava grandes asp templates para serem processados pelo IIS (e isso representa uma sobrecarga a mais no servidor).  

Como podemos ver havia grandes problemas a serem enfretados, e um longo trabalho teve início a partir desta análise da aplicação. Se você leu estes últimos itens acima e ficou pensando consigo mesmo: "Puxa, e agora? Não entendi nem por que isso é considerado problema!", não se preocupe. Nos próximos posts eu vou comentar cada um dos tópicos encontrados. Por outro lado se você entendeu tudo, mesmo assim eu lhe convido a retornar, afinal, sempre pode haver alguma informação que contribua para o seu conhecimento.

Vejo vocês em breve.

Paulo.