Os desenvolvedores de ASP se esforçam continuamente para obter melhor desempenho e escalabilidade em seus projetos de design. Felizmente, existem muitos livros e sites que oferecem ótimos conselhos nesta área. No entanto, estas sugestões baseiam-se em conclusões retiradas da estrutura de trabalho da plataforma ASP e não existe uma medição quantitativa da melhoria real do desempenho. Como essas recomendações exigem uma codificação mais complexa e tornam o código menos legível, os desenvolvedores precisam avaliar se vale a pena melhorar o desempenho de seus aplicativos ASP sem ver os resultados reais.
Este artigo está dividido em duas partes. Apresentarei alguns resultados de testes de desempenho para ajudar os desenvolvedores a determinar se uma determinada iniciativa vale a pena não apenas para projetos futuros, mas também para atualizar o projeto original. Na primeira parte revisarei algumas questões básicas do desenvolvimento de ASP. Na segunda parte, você abordará a otimização de algumas funções ADO e a comparação de seus resultados com páginas ASP que chamam objetos VB COM para executar as mesmas funções ADO. Os resultados são reveladores e às vezes surpreendentes.
Neste artigo, responderemos às seguintes perguntas:
* Qual é a maneira mais eficiente de gravar conteúdo gerado por ASP no fluxo de resposta?
* O buffer deve estar habilitado?
* Você deveria considerar adicionar comentários ao seu código ASP?
* O idioma padrão deve ser definido explicitamente para a página?
* O estado da Sessão deve ser fechado se não for necessário?
* A lógica do script deve ser colocada em sub-rotinas e áreas funcionais?
* Quais são as implicações do uso de arquivos include?
* Que tipo de carga é imposta ao realizar o tratamento de erros?
* A configuração de um manipulador de contexto tem algum impacto no desempenho?
Todos os testes foram realizados usando a Web Application Focus Tool (WAST) da Microsoft, uma ferramenta gratuita que pode ser encontrada aqui. Criei um script de teste simples usando WAST que chamou repetidamente os testes de página ASP descritos abaixo (mais de 70.000 vezes cada). O tempo de resposta é baseado no tempo total médio do último byte (TTLB), que é o tempo desde o momento da solicitação inicial até o momento em que a ferramenta recebe o último bit de dados do servidor. Nosso servidor de teste é um Pentium 166 com 196 MB de RAM e o cliente é um Pentium 450 com 256 MB de RAM. Você pode pensar que o desempenho dessas máquinas não é muito avançado, mas não se esqueça, não estamos testando a capacidade do servidor, estamos apenas testando o tempo que o servidor leva para processar uma página por vez. As máquinas não realizam nenhum outro trabalho durante o teste. Os scripts de teste WAST, relatórios de teste e todas as páginas de teste ASP estão incluídos no arquivo ZIP para você revisar e testar.
Qual é a maneira mais eficiente de gravar conteúdo gerado por ASP no fluxo de resposta?
Um dos maiores motivos para usar ASP é gerar conteúdo dinâmico no servidor. Portanto, o ponto de partida óbvio para nossos testes é determinar a maneira mais apropriada de enviar conteúdo dinâmico para o fluxo de resposta. Entre as muitas opções, duas são as mais básicas: uma é usar tags ASP embutidas e a outra é usar a instrução Response.Write.
Para testar essas opções, criamos uma página ASP simples na qual definimos algumas variáveis e depois inserimos seus valores em uma tabela. Embora esta página seja simples e pouco prática, ela nos permite isolar e testar alguns problemas individuais.
Usando tags embutidas ASP
O primeiro teste envolve o uso da tag ASP embutida < %= x % >, onde x é uma variável atribuída. Esse método é de longe o mais fácil de executar e mantém a parte HTML da página em um formato fácil de ler e manter.
<% OPÇÃO EXPLÍCITA
Dim PrimeiroNome
DimSobrenome
Dim MédioInicial
Endereço escuro
Cidade escura
Estado escuro
DimPhoneNumber
Escurecer número de fax
Escurecer e-mail
DimDataDeNascimento
Nome = João
MédioInicial = Q
Sobrenome = Público
Endereço = Rua Principal 100
Cidade=Nova York
Estado=NY
Número de telefone = 1-212-555-1234
Número de fax = 1-212-555-1234
E-mail = [email protected]
Data de nascimento = 01/01/1950
%>
＜HTML＞
＜CABEÇA＞
＜ TÍTULO ＞Teste de resposta ＜ / TÍTULO ＞
＜ /CABEÇA＞
＜CORPO＞
＜H1 ＞Teste de Resposta ＜ /H1 ＞
＜ TABELA ＞
＜ tr ＞＜ td ＞＜ b ＞Nome:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nome % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Inicial do meio:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Sobrenome:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Sobrenome % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Endereço:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Endereço % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Cidade:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Cidade % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Estado:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Estado % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Número de telefone:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Número de telefone % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Número de fax:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Número de fax % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞E-mail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= E-mail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Data de Nascimento:＜ /b ＞＜ /td ＞＜ td ＞＜ %= DataNascimento % ＞＜ /td ＞＜ /tr ＞
＜ /TABELA＞
＜ / CORPO ＞
＜ /HTML＞
O código completo de /app1/response1.asp
Melhor anterior (velocidade de resposta) = 8,28 ms/página
Use a instrução Response.Write em cada linha de HTML
Muitos dos melhores documentos de aprendizagem recomendam evitar o método anterior. A principal razão para isso é que, no processo de saída da página e processamento da página para impor latência, se o servidor web tiver que converter entre o envio de HTML simples e o processamento de script, ocorre um problema chamado troca de contexto. Quando a maioria dos programadores ouve isso, sua primeira reação é agrupar cada linha de HTML bruto em uma função Response.Write.
…
Resposta.Write(＜html＞)
Resposta.Write(＜cabeça＞)
Response.Write(＜título＞Teste de resposta＜/título＞)
Resposta.Write(＜/head＞)
Response.Write(＜corpo＞)
Response.Write(＜h1＞Teste de resposta＜/h1＞)
Resposta.Write(＜tabela＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Nome:＜ /b ＞＜ /td ＞＜ td ＞ & Nome & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Inicial do meio:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
… <
Fragmento de /app1/response2.asp
Melhor anterior (velocidade de resposta) = 8,28 ms/página
Tempo de resposta = 8,08 ms/página
Diferença = -0,20 mseg (redução de 2,4%)
Podemos ver que o ganho de desempenho com o uso dessa abordagem é muito pequeno comparado ao uso da marcação inline, talvez porque a página carrega o servidor com um monte de pequenas chamadas de função. A maior desvantagem dessa abordagem é que, como o HTML agora está incorporado no script, o código do script se torna mais detalhado e mais difícil de ler e manter.
Use funções de wrapper
Talvez a descoberta mais desanimadora ao tentar usar a abordagem de instrução Response.Write seja que a função Response.Write não pode colocar um CRLF no final de cada linha. Então, quando você lê o código-fonte do navegador, o HTML que estava perfeitamente organizado agora é uma linha sem fim. Acho que sua próxima descoberta pode ser ainda mais horrível: não há função irmã Writeln no objeto Response. Portanto, uma reação óbvia é criar uma função wrapper para a função Response.Write para anexar um CRLF a cada linha.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞Nome:＜ /b ＞＜ /td ＞＜ td ＞ & Nome & ＜ /td ＞＜ /tr ＞)
…
SUB gravaçãoCR(str)
Resposta.Write(str & vbCRLF)
FINALIZAR SUB
Fragmento de /app1/response4.asp
Melhor anterior (velocidade de resposta) = 8,08 ms/página
Tempo de resposta = 10,11 ms/página
Diferença = +2,03 ms (aumento de 25,1%)
É claro que, uma vez que esta abordagem duplica efetivamente o número de chamadas de função, o seu impacto no desempenho é significativo e deve ser evitado a todo custo. Ironicamente, o CRLF também adiciona 2 bytes por linha ao fluxo reativo, que o navegador não precisa renderizar na página. Tudo o que o HTML bem formatado faz é tornar mais fácil para seus concorrentes lerem seu código-fonte HTML e entenderem seu design.
Concatene Response.Write consecutivos em uma única instrução
Independentemente de nossos testes anteriores com funções wrapper, o próximo passo lógico é extrair todas as strings das instruções Response.Write separadas e concatená-las em uma única instrução, reduzindo assim o número de chamadas de função, melhorando bastante o desempenho da página.
…
Resposta.Write(＜html＞&_
<cabeça> & _
＜título＞Teste de Resposta＜/título＞ & _
＜ /cabeça ＞ & _
＜corpo＞ & _
＜ h1 ＞Teste de resposta＜ /h1 ＞ & _
＜ mesa ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Nome:＜ /b ＞＜ /td ＞＜ td ＞ & Nome & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Data de Nascimento:＜ /b ＞＜ /td ＞＜ td ＞ & DataNascimento & ＜ /td ＞＜ /tr ＞ & _
＜ /tabela ＞ & _
＜ /corpo ＞ & _
＜ /html＞)
Fragmento de /app1/response3.asp
Melhor anterior (velocidade de resposta) = 8,08 ms/página
Tempo de resposta = 7,05 ms/página
Diferença = -1,03 mseg (redução de 12,7%)
Atualmente, esta é a configuração mais otimizada.
Concatene Response.Write consecutivos em uma única instrução, adicionando um CRLF no final de cada linha
Considerando aqueles que exigem que seu código-fonte pareça impecável em um navegador, usei a constante vbCRLF para inserir alguns retornos de carro no final de cada linha no teste anterior e executei-o novamente.
…
Response.Write(＜html＞&vbCRLF&_
<cabeça> & vbCRLF & _
＜ title ＞Teste de resposta＜ /title ＞ & vbCRLF & _
＜ /head ＞ & vbCRLF & _
…
Fragmento de /app1/response5.asp
Melhor anterior (velocidade de resposta) = 7,05 ms/página
Tempo de resposta = 7,63 ms/página
Diferença = +0,58 ms (aumento de 8,5%)
O resultado é uma ligeira diminuição no desempenho, talvez devido à concatenação extra e ao aumento do número de caracteres.
Revisão e Observação
Algumas regras podem ser extraídas dos testes anteriores na saída ASP:
* Evite o uso excessivo de ASP in-line.
* Sempre concatene instruções Response.Write consecutivas em uma única instrução.
* Nunca use funções wrapper em torno de Response.Write para anexar CRLF.
* Se a saída HTML precisar ser formatada, anexe CRLF diretamente na instrução Response.Write.
O buffer deve ser habilitado?
Iniciar buffer via script
Ao incluir Response.Buffer=True na parte superior do script ASP, o IIS armazenará em cache o conteúdo da página.
<% OPÇÃO EXPLÍCITA
Resposta.Buffer = verdadeiro
Dim PrimeiroNome
…
Fragmento de /app1/buffer__1.asp
Melhor anterior (tempo de resposta) = 7,05 ms/página
Tempo de resposta = 6,08 ms/página
Diferença = -0,97 mseg (redução de 13,7%)
O desempenho foi muito melhorado. Mas espere, há algo melhor.
Iniciar buffer por meio da configuração do servidor
Embora o buffer esteja habilitado por padrão no IIS 5.0, ele deve ser habilitado manualmente no IIS 4.0. Agora encontre a caixa de diálogo Propriedades do site e selecione o botão Configurar na guia Diretório inicial. Em seguida, selecione ativar buffer nas opções do aplicativo. Para este teste, a instrução Response.Buffer foi movida do script.
Melhor anterior = 7,05 ms/página
Tempo de resposta = 5,57 ms/página
Diferença = -1,48 mseg (redução de 21,0%)
Atualmente, esta é a resposta mais rápida que já tivemos, 21% menor do que o nosso melhor tempo de resposta anterior. A partir de agora, nossos testes futuros usarão esse tempo de reação como valor base.
Revisão e Observação
Os buffers são uma ótima maneira de melhorar o desempenho, portanto, é necessário definir os buffers para os valores padrão do servidor. Se por algum motivo a página não puder executar o buffer corretamente, basta usar o comando Response.Buffer=False. Uma desvantagem dos buffers é que o usuário não vê nada do servidor até que toda a página seja processada. Portanto, durante o processamento de páginas complexas, é uma boa ideia chamar Response.Flush ocasionalmente para atualizar o usuário.
Agora adicionamos mais uma regra: sempre habilite o buffer por meio das configurações do servidor.
Você deveria considerar adicionar comentários ao seu código ASP?
A maioria dos desenvolvedores HTML sabe que incluir comentários HTML é uma má ideia, em primeiro lugar aumenta o tamanho dos dados que estão sendo transferidos e, em segundo lugar, apenas fornecem a outros desenvolvedores informações sobre a organização da sua página. Mas e os comentários nas páginas ASP? Eles nunca saem do servidor, mas aumentam o tamanho da página, por isso devem ser divididos usando ASP.
Neste teste, adicionamos 20 comentários, cada um com 80 caracteres, totalizando 1.600 caracteres.
<% OPÇÃO EXPLÍCITA
'------------------------------------------------ - ---------------------------------
…20 linhas…
'------------------------------------------------ - ---------------------------------
Dim PrimeiroNome
…
Fragmento /app2/comment_1.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 5,58 ms/página
Diferença = +0,01 ms (aumento de 0,1%)
Os resultados do teste foram surpreendentes. Embora os comentários tenham quase o dobro do tamanho do arquivo em si, sua presença não tem um grande impacto nos tempos de resposta. Portanto, podemos seguir as seguintes regras:
Desde que usadas moderadamente, as anotações ASP têm pouco ou nenhum impacto no desempenho.
O idioma padrão deve ser definido explicitamente para a página?
O IIS lida com VBScript por padrão, mas vejo que na maioria dos casos a linguagem é explicitamente definida como VBScript usando a instrução <%@LANGUAGE=VBSCRIPT%>. Nosso próximo teste examinará qual impacto a presença desta declaração tem no desempenho.
＜ %@ IDIOMA=VBSCRIPT % ＞
<% OPÇÃO EXPLÍCITA
Dim PrimeiroNome
…
Fragmento /app2/idioma1.asp.
Linha de base = 5,57 ms/página
Tempo de resposta = 5,64 ms/página
Diferença = +0,07 ms (aumento de 1,2%)
Como você pode ver, incluir declarações de linguagem tem um leve impacto no desempenho. portanto:
* Defina a configuração de idioma padrão do servidor para corresponder ao idioma usado no site.
* Não defina uma declaração de idioma, a menos que esteja usando um idioma não padrão.
O estado da Sessão deve ser desativado se não for necessário?
Há muitos motivos para evitar o uso do contexto de sessão do IIS, e esses podem ser seus próprios artigos. A questão que estamos tentando responder agora é se fechar o contexto da Sessão quando não for necessário para a página ajudará a melhorar o desempenho. Teoricamente deveria ser sim, pois assim não há necessidade de utilizar a página para instanciar o contexto da Sessão.
Assim como o buffer, existem duas maneiras de configurar o estado da sessão: por meio de scripts e por meio de configurações do servidor.
Fechar o contexto da sessão via script
Para este teste, para fechar o contexto da Sessão na página, adicionei uma declaração de estado da Sessão.
＜ %@ ENABLESESSIONSTATE = FALSE % ＞
<% OPÇÃO EXPLÍCITA
Dim PrimeiroNome
…
Fragmento /app2/session_1.asp.
Linha de base = 5,57 ms/página
Tempo de resposta = 5,46 ms/página
Diferença = -0,11 ms (diminuição de 2,0%)
Um bom progresso foi feito através de um esforço tão pequeno. Agora veja a segunda parte.
Feche o contexto da sessão por meio da configuração do servidor
Para fechar o contexto da Sessão no servidor, acesse a caixa de diálogo Propriedades do site. Selecione o botão Configuração na guia Diretório inicial. Em seguida, desmarque ativar o estado da sessão nas opções do aplicativo. Executamos o teste sem a instrução ENABLESESSIONSTATE.
Linha de base = 5,57 ms/página
Tempo de resposta = 5,14 ms/página
Diferença = -0,43 mseg (redução de 7,7%)
Esta é outra melhoria significativa no desempenho. Portanto, nossa regra deveria ser: sempre feche o estado da Sessão no nível da página ou da aplicação quando não for necessário.
O uso da Option Explicit alterará substancialmente o desempenho?
Defina Option Explicit na parte superior de uma página ASP para exigir que todas as variáveis sejam declaradas na página antes do uso. Existem duas razões para isso. Primeiro, os aplicativos podem processar o acesso variável com mais rapidez. Em segundo lugar, isso nos impede de usar acidentalmente nomes de variáveis de forma incorreta. Neste teste removemos a referência Option Explicit e a declaração Dim da variável.
Linha de base = 5,57 ms/página
Tempo de resposta = 6,12 ms/página
Diferença = +0,55 mseg (aumento de 9,8%),
Embora algumas linhas de código tenham sido removidas da página, os tempos de resposta ainda aumentaram. Portanto, embora o uso de Option explicit às vezes seja demorado, ele tem um efeito significativo no desempenho. Portanto podemos adicionar outra regra: sempre use Option explícita em VBScript.
A lógica do script deve ser colocada em sub-rotinas e áreas funcionais?
Usar funções e sub-rotinas é uma boa maneira de organizar e gerenciar código, especialmente quando uma área de código é usada diversas vezes na página. A desvantagem é que adiciona uma chamada de função extra ao sistema que faz o mesmo trabalho. Outro problema com sub-rotinas e funções é o escopo das variáveis. Em teoria, é mais eficiente especificar variáveis dentro de uma área funcional. Agora vamos ver como esses dois aspectos entram em jogo.
Mova a instrução Response.Write para uma sub-rotina
Este teste simplesmente move a instrução Response.Write para uma área de sub-rotina.
…
CHAMADA writeTable()
SUB writeTable()
Resposta.Write(＜html＞&_
<cabeça> & _
…
＜ tr ＞＜ td ＞＜ b ＞E-mail:＜ /b ＞＜ /td ＞＜ td ＞ & E-mail & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Data de Nascimento:＜ /b ＞＜ /td ＞＜ td ＞ & DataNascimento & ＜ /td ＞＜ /tr ＞ & _
＜ /tabela ＞ & _
＜ /corpo ＞ & _
＜ /html＞)
FINALIZAR SUB
Fragmento /app2/function1.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 6,02 ms/página
Diferença = +0,45 ms (aumento de 8,1%)
Como esperado, as chamadas de sub-rotina geram sobrecarga adicional na página.
Mova todos os scripts para sub-rotinas
Neste teste, a instrução Response.write e as declarações de variáveis são movidas para uma área de sub-rotina.
<% OPÇÃO EXPLÍCITA
CHAMADA writeTable()
SUB writeTable()
Dim PrimeiroNome
…
DimDataDeNascimento
Nome = João
…
Data de nascimento = 01/01/1950
Resposta.Write(＜html＞&_
<cabeça> & _
＜título＞Teste de Resposta＜/título＞ & _
＜ /cabeça ＞ & _
＜corpo＞ & _
＜ h1 ＞Teste de resposta＜ /h1 ＞ & _
＜ mesa ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Nome:＜ /b ＞＜ /td ＞＜ td ＞ & Nome & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Data de Nascimento:＜ /b ＞＜ /td ＞＜ td ＞ & DataNascimento & ＜ /td ＞＜ /tr ＞ & _
＜ /tabela ＞ & _
＜ /corpo ＞ & _
＜ /html＞)
FINALIZAR SUB
Fragmento /app2/function2.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 5,22 ms/página
Diferença = -0,35 mseg (redução de 6,3%)
Muito interessante! Embora mover variáveis para o escopo da função adicione uma chamada de função extra, na verdade melhora o desempenho. Podemos adicionar as seguintes regras:
* Em uma página, se o código for usado mais de uma vez, coloque o código em uma área de função.
* Quando apropriado, mova as declarações de variáveis para o escopo da função.
Quais são as implicações do uso de arquivos include?
Uma característica importante da programação ASP é a inclusão de código de outras páginas. Com esse recurso, os programadores podem compartilhar funções em várias páginas, facilitando a manutenção do código. A desvantagem é que o servidor deve montar a página a partir de múltiplas fontes. Abaixo estão dois testes usando arquivos de inclusão.
Incluir arquivos usando código embutido
Neste teste, um pequeno trecho de código foi movido para um arquivo Incluir:
<% OPÇÃO EXPLÍCITA
Dim PrimeiroNome
…
DimDataDeNascimento
Nome = João
…
Data de nascimento = 01/01/1950
%>
＜ !-- #incluir arquivo=inc1.asp -- ＞
Fragmento /app2/include_1.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 5,93 ms/página
Diferença = +0,36 ms (aumento de 6,5%)
Isto não é surpreendente. A carga útil é formada usando arquivos de inclusão.
Use Incluir arquivos na área de função
Aqui, o código é agrupado em uma sub-rotina em um arquivo Incluir. A referência Incluir é feita no topo da página e chama a sub-rotina no local apropriado no script ASP.
<% OPÇÃO EXPLÍCITA
Dim PrimeiroNome
…
DimDataDeNascimento
Nome = João
…
Data de nascimento = 01/01/1950
CHAMADA writeTable()
%>
＜ !-- #incluir arquivo=inc2.asp -- ＞
Fragmento /app2/include_2.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 6,08 ms/página
Diferença=+0,51 ms (aumento de 9,2%)
Isto tem um impacto maior no desempenho do que as chamadas de funções. Portanto: Use Incluir arquivos somente quando o código for compartilhado entre páginas.
Quanta carga é criada ao executar o tratamento de erros?
O tratamento de erros é necessário para todas as aplicações reais. Neste teste, o manipulador de erros é chamado chamando a função On Error Resume Next.
<% OPÇÃO EXPLÍCITA
Em caso de erro, retomar o próximo
Dim PrimeiroNome
…
Fragmento /app2/error_1.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 5,67 ms/página
Diferença = 0,10 ms (aumento de 1,8%)
Como você pode ver, o tratamento de erros tem um preço. Podemos sugerir o seguinte: Use identificadores de erro somente quando acontecer algo que esteja além da sua capacidade de testar ou controlar. Um exemplo básico é usar objetos COM para acessar outros recursos, como objetos ADO ou FileSystem.
A configuração de um manipulador de contexto tem algum impacto no desempenho?
Quando ocorre um erro, definir um manipulador de contexto na página permite que o script reverta a ação. Isso é definido usando uma instrução de processamento na página.
＜ %@ TRANSAÇÃO = NECESSÁRIA % ＞
<% OPÇÃO EXPLÍCITA
Dim PrimeiroNome
…
Fragmento /app2/transact1.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 13,39 ms/página
Diferença = +7,82 ms (aumento de 140,4%)
ah! Este é realmente o resultado mais dramático. Portanto, observe a seguinte regra: Use o contexto de processamento somente quando duas ou mais operações forem executadas como uma unidade.
para concluir
O que é importante na primeira parte deste artigo é o acúmulo de muitas pequenas coisas. Para destacar esse problema, configurei um teste final onde fiz todas as coisas que testamos antes que pareciam inócuas, mas na verdade tiveram um efeito negativo. Incluí várias instruções Response.Write, desliguei o buffer, configurei o idioma padrão, removi a referência Option Explicit e inicializei o manipulador de erros.
＜ %@ IDIOMA=VBSCRIPT % ＞
<%
Em caso de erro, retomar o próximo
Nome = João
…
Data de nascimento = 01/01/1950
Resposta.Write(＜html＞)
Resposta.Write(＜cabeça＞)
Response.Write(＜título＞Teste de resposta＜/título＞)
Resposta.Write(＜/head＞)
Resposta.Write(＜corpo＞)
Response.Write(＜h1＞Teste de resposta＜/h1＞)
Resposta.Write(＜tabela＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Nome:＜ /b ＞＜ /td ＞＜ td ＞ &_
Nome & ＜ /td ＞＜ /tr ＞)
…
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Data de nascimento:＜ /b ＞＜ /td ＞＜ td ＞ &_
Data de Nascimento & ＜ /td ＞＜ /tr ＞)
Resposta.Write(＜/tabela＞)
Resposta.Write(＜/corpo＞)
Resposta.Write(＜/html＞)
%>
Fragmento /app2/final_1.asp
Linha de base = 5,57 ms/página
Tempo de resposta = 8,85 ms/página
Diferença = +3,28 ms (aumento de 58,9%)
Pode parecer óbvio, mas é mais importante entender que o código que colocamos na página tem impacto no desempenho. Às vezes, pequenas alterações na página podem aumentar significativamente os tempos de resposta.
Resumo das regras
* Evite o uso excessivo de ASP in-line.
* Sempre concatene instruções Response.Write consecutivas em uma única instrução.
* Nunca use funções wrapper em torno de Response.Write para anexar CRLF.
* Se a saída HTML precisar ser formatada, anexe CRLF diretamente na instrução Response.Write.
* Sempre habilite o buffer através das configurações do servidor.
*Desde que usadas moderadamente, as anotações ASP têm pouco ou nenhum impacto no desempenho.
* Defina a configuração de idioma padrão do servidor para corresponder ao idioma usado no site.
* Não defina uma declaração de idioma, a menos que esteja usando um idioma não padrão.
* Sempre use Opção explícita em VBScript.
* Sempre desative o estado da sessão no nível da página ou do aplicativo quando não for necessário.
* Use Incluir arquivos somente quando o código for compartilhado entre páginas.
* Em uma página, se o código for usado mais de uma vez, coloque o código em uma área de função.
* Quando apropriado, mova as declarações de variáveis para o escopo da função.
* Use identificadores de erro somente se ocorrerem condições que estejam além dos recursos do teste ou controle.
* Use o processamento de contexto somente quando duas ou mais operações forem executadas como uma unidade.
Olhando para trás agora, há uma série de questões que podem servir como diretrizes gerais:
* Evite redundância – não defina propriedades que já estão definidas por padrão.
* Limite o número de chamadas de função.
* Reduza o escopo do código.