Embed Size (px)
Citation preview
IGTI – Instituto de Gestão e Tecnologia da Informação
Pós-Graduação: Estratégias em Arquitetura de Software
Otimização de Desempenho de Websites desenvolvidos em Microsoft
ASP.NET e hospedados em servidores Microsoft IIS
RAFAEL DO CARMO SCHETTINO1
RESUMO
A construção de websites envolve um conjunto de fatores que podem afetar o
desempenho de um website de forma positiva ou negativa. Este trabalho foi desenvolvido para
demonstrar diretrizes que podem ser úteis para elevar a performance de uma aplicação e
auxiliar na compreensão deste universo que abrange protocolos, clientes, servidores,
ferramentas de desenvolvimento, tecnologias e práticas, através de duas visões diferentes: a
visão do lado cliente e a visão do lado servidor.
As práticas adequadas para a construção de websites de alto desempenho e as práticas
que devem ser evitadas no desenvolvimento destas aplicações são algumas das questões
abordadas neste trabalho, que demonstra também como pequenas mudanças realizadas na
configuração ou codificação de um website podem se transformar em grandes benefícios para
a melhoria do tempo de resposta.
Palavras-chave: Otimização, Desempenho, Tempo de Resposta Cliente, Servidor.
ABSTRACT
The websites development involves a group of factors that could affect the websites
performance positively or negatively. This work was developed to demonstrate guidelines that
could be useful to increase an application performance and assist in comprehension of this
universe that involves protocols, clients, servers, development tools, technologies and
practices, through two different visions: the client-side and server-side visions.
The appropriate practices for build high performance websites and the practices that
should be avoid in these application’s development are some questions approached in this
work, that also demonstrate how little changes in configuration or codification of a website
can become in big benefits to decrease response time.
Keywords: Optimization, Performance, Response Time, Client, Server.
1 Tecnólogo em Sistemas para Internet pela Faculdade INED, possui aperfeiçoamento em Gestão e Tecnologia
da Informação pelo IETEC (Instituto de Educação Tecnológica) e é pós-graduando em Estratégias em
Arquitetura de Software pelo IGTI (Instituto de Gestão e Tecnologia da Informação). E-mail:
2
1. INTRODUÇÃO
Este artigo trata do tema desempenho de websites, com o objetivo de retratar conceitos
e técnicas, obtidas através de pesquisa exploratória, direcionadas à diminuição do tempo de
resposta no carregamento das páginas web, visando propiciar a melhor experiência de
navegação aos usuários.
De acordo com o dicionário Michaelis da língua portuguesa, desempenho pode ser
caracterizado como “rendimento total que, juntamente com a facilidade de utilização,
constitui um dos principais fatores determinantes da produtividade dos componentes físicos e
lógicos de um sistema de computação”. O termo desempenho foi classificado pela letra P
(performance) do sistema de classificação de requisito FURPS, apresentado por Grady
(1992). Nesse sistema, o desempenho é responsável por agrupar o conjunto de restrições de
sistemas de software referentes a variáveis como velocidade, tempo de resposta, vazão, tempo
de inicialização, dentre outros.
De acordo com Nielsen (2010, tradução nossa), “a lentidão (ou velocidade) causa tanto
impacto que pode ser associada pelos clientes como um dos valores da marca associada ao
website”, relatando ainda que o tempo de resposta é “relevante como sempre” – se referindo,
em 2010, a um artigo que escrevera em 1993 - e a capacidade de resposta é uma “regra básica
do design de interfaces, ditada por necessidade humanas, não por tecnologias individuais”.
Normalmente, no momento de realizar o desenvolvimento de um website, a restrição
de desempenho imposta é: “o site deve ser o mais rápido possível”. Nielsen (1993, p. 135-
136) realizou uma pesquisa acerca da interação humano-computador e obteve algumas
conclusões em relação aos tempos de resposta adequados:
0.1 segundo: limite de tempo no qual o usuário sente que há reações instantâneas
do sistema. Isso significa que não é necessário nenhum feedback especial, mas
somente a exibição dos resultados;
1.0 segundo: limite de tempo no qual o usuário sente que seu fluxo é ininterrupto,
mesmo notando que há algum atraso, mas sem perder a percepção que está
operando diretamente sobre os dados. Normalmente, nenhum feedback especial é
necessário quando o tempo de resposta está entre 0.1 e 1 segundo.
10 segundos: limite de tempo que o usuário mantém a atenção focada em um
diálogo. Para atrasos longos, o usuário quer realizar outras tarefas enquanto
aguarda o computador finalizar a atividade atual. Contudo, ele espera um feedback
do computador informando a expectativa de tempo para conclusão. O feedback
durante a resposta é especialmente importante se o tempo para resposta é altamente
variável e o usuário não sabe por quanto tempo terá que aguardar.
Segundo Nielsen (2010, tradução nossa), um website com “[...] atraso de 10 segundos
é, muitas vezes, é suficiente para que um usuário saia de um local imediatamente.”. Nielsen
(2010, tradução nossa) também relata que “você pode facilmente perder metade das suas
3
vendas (para clientes menos comprometidos) porque seu site é mais lento que outros para
cada página.”.
Esse trabalho foi desenvolvido através de pesquisa exploratória e tem como objetivo
demonstrar mudanças direcionadas ao aumento do desempenho que podem ser realizadas no
momento da construção ou implantação de uma aplicação web. Portanto, este artigo explanará
sobre o funcionamento das requisições HTTP; a arquitetura cliente x servidor de aplicações
web; algumas técnicas de otimização do lado servidor – tais como hardware, cache,
codificação e banco de dados – e algumas técnicas de otimização do lado cliente – tais como
requisições HTTP, JavaScript, CSS e redes de conteúdo (CDN).
2. PROTOCOLO HTTP
Mantido pelo consórcio W3C (World Wide Web Consortium), pela comunidade IETF
(Internet Engineering Task Force) e utilizado pela web desde 1990, o protocolo HTTP –
Hypertext Transfer Protocol - é o responsável por permitir a distribuição de hipermídia
através da Internet e está contido na camada de aplicação do modelo OSI2.
O protocolo HTTP opera através de mensagens no formato cliente-servidor. Um
cliente (como, por exemplo, um navegador de internet), realiza uma requisição ao servidor.
Esta requisição é composta por meta-dados, utilizados pelo servidor web para filtrar,
processar e responder à requisição de acordo com as informações requeridas.
De acordo com o IETF (1999, p.31), as mensagens HTTP consistem em “[...]
requisições feitas pelo cliente ao servidor e respostas enviadas pelo servidor ao cliente”.
Todas as mensagens são compostas de acordo com o padrão genérico estabelecido na RFC
822, no qual tanto as mensagens de requisição quanto de resposta são compostas de uma linha
inicial, um cabeçalho (header) e opcionalmente um corpo (body).
Figura 1 – Requisição HTTP - cliente e servidor.
(GOURLEY; TOTTY, 2002, p. 4, tradução nossa)
As requisições HTTP são realizadas diretamente a um URI (Uniform Resouce
Identifiers), que segundo o IEFT (1999, p. 18, tradução nossa), “[...] são cadeias de caracteres
formatadas de forma simples para identificar um recurso através do nome, da localização ou
de outra característica”. Ainda de acordo com o IEFT (1999, p 18, tradução nossa), “URIs são
conhecidos por diversos nomes: endereços WWW, Universal Document Identifiers, Universal
2 O modelo OSI, segundo ZIMMERMANN (1980), é o modelo universal aberto para interconexão de sistemas
de redes de computadores, que adota o conceito arquitetural de camadas e é composto por sete dessas. De cima
para baixo, as camadas OSI são: Aplicação, Apresentação, Sessão, Transporte, Rede, Enlace, Física.
4
Resource Identifiers e também a combinação de Uniform Resource Locators (URL) e Names
(URN)”. Um exemplo de URI é o endereço http://www.google.com.br.
Uma requisição HTTP também é composta por métodos, que são informados na linha
inicial da requisição, juntamente com o URI. De acordo com o IETF (1999, p. 36), os
métodos aceitos pelo protocolo são: OPTIONS, GET, HEAD, POST, PUT, DELETE,
TRACE, CONNECT ou algum método personalizado que pode ser estendido por um cliente
ou servidor específico.
A requisição GET é a requisição padrão feita pelos clientes para buscar quaisquer
recursos em um determinado servidor. Os itens de um website como seu conteúdo, suas
imagens, seus arquivos auxiliares e suas definições de cores, normalmente são carregados
através de requisições que utilizam o método GET. Na figura 2, é possível ver
um exemplo dos cabeçalhos (headers) de uma requisição GET feita ao endereço
https://www.google.com.br/images/srpr/logo4w.png (que representa a logomarca do portal
Google).
Além do cabeçalho, uma resposta a uma requisição GET retorna ao cliente um código
de status, na linha inicial, e os dados correspondentes ao conteúdo, que no exemplo da
figura 2 são um conjunto de bytes, com sua contagem representada pelo atributo Content-
Length e o tipo de conteúdo representado pelo atributo Content-Type. Segundo o IEFT (1999,
p. 58-59), os códigos de status podem indicar uma resposta: informativa (100 e 101); bem
sucedida (200 ao 206); de redirecionamento (300 ao 307); de erro do cliente (400 ao 417) ou
de erro no servidor (500 ao 505).
Requisição:
GET /images/srpr/logo4w.png HTTP/1.1
Host: www.google.com.br
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML,
like Gecko) Chrome/26.0.1410.43 Safari/537.31
Connection: keep-alive
Resposta:
HTTP/1.1 200 OK
Cache-Control: private, max-age=31536000
Date: Sun, 31 Mar 2013 00:05:06 GMT
Expires: Sun, 31 Mar 2013 00:05:06 GMT
Content-Length: 18946
Content-Type: image/png
Last-Modified: Mon, 25 Mar 2013 19:02:15 GMT
Server: sffe
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Figura 2 – Exemplo de requisição HTTP
O método POST, que também é muito utilizado em websites, “foi desenhado para
enviar dados de entrada para o servidor. Na prática, ele é utilizado para suportar formulários
HTML” (GOURLEY; TOTTY, 2002, p.55, tradução nossa).
5
O tempo de resposta é o tempo transcorrido entre o momento em que uma requisição
HTTP é iniciada e o momento que a resposta é completamente recebida pelo cliente, com
cabeçalhos e conteúdo.
3. O LADO SERVIDOR
3.1. O QUE SÃO OS SERVIDORES WEB
Os servidores que fornecem suporte a requisições HTTP com o objetivo de
disponibilizar conteúdo para websites são conhecidos como “servidores web” (ou web
servers). Segundo Gourley e Totty (2002, p.109, tradução nossa), “o termo web server pode
se referir tanto a um software de servidor web quando a um dispositivo particular um
computador dedicado a servir páginas de internet”.
Servidores web armazenam e disponibilizam recursos web aos clientes. “Um recurso
web é uma fonte de conteúdo na web. O tipo mais simples de recurso web é um arquivo
estático armazenado no sistema de arquivos do servidor.” (GOURLEY; TOTTY, 2002, p. 4,
tradução nossa). São exemplos de arquivos estáticos: uma imagem, um arquivo de texto, um
vídeo.
Além de arquivos físicos e estáticos, recursos dinâmicos também podem ser providos
por servidores web. De acordo com Gourley e Totty (2002, p.5, tradução nossa), “[...]
recursos dinâmicos podem ser softwares programados que geram conteúdo sob demanda”.
Uma página da internet que exibe determinada informação tendo como base na identidade do
usuário ou em alguma informação fornecida por ele, ou uma página que realiza uma busca em
determinado conteúdo e exibe os resultados para o usuário são exemplos de conteúdo
dinâmico.
No mercado, existem diversos tipos de servidores web. Os servidores mais utilizados,
de acordo com estatísticas da NetCraft3 (2013) demonstradas na figura 4, são o servidor open-
source Apache web server e a solução comercial Microsoft IIS (Internet Information Server).
Para realizar a geração de conteúdo dinâmico dos websites, é necessária a utilização de
linguagens de programação adequadas a cada tipo de servidor. Servidores como Apache e
Microsoft IIS suportam vários tipos de linguagens de programação, de forma nativa ou
através da instalação através de módulos específicos. De acordo com a figura 4, as linguagens
de programação para web mais utilizadas no mercado para o desenvolvimento de websites são
a linguagem open-source PHP – que pode ser executada tanto no Apache quanto no Microsoft
IIS através da instalação de módulos - e a linguagem comercial, proprietária, Microsoft
ASP.NET – que pode ser executada no IIS ou em servidores Apache através da plataforma
Mono4.
Neste trabalho o enfoque será da otimização do lado servidor será dado sobre a
linguagem de programação ASP.NET e o servidor web Microsoft IIS, pelo fato de serem as
tecnologias comerciais mais utilizadas pelo mercado.
3 NetCraft é uma empresa inglesa que realiza pesquisa e análise de dados sobre a internet desde 1995. 4 Mono é uma plataforma de desenvolvimento open-source baseada no framework Microsoft.NET que permite a
desenvolvedores criarem aplicações multiplataforma e/ou para Linux - tanto do lado cliente quanto do lado
servidor - utilizando a linguagem C#.
6
Figura 3 – Servidores web mais utilizados. (NETCRAFT, 2013, tradução nossa)
Figura 4 – Linguagens de programação server-side mais utilizadas.
(W3TECHS, 2013, tradução nossa).
3.2. PLATAFORMA MICROSOFT ASP.NET
ASP.NET é uma tecnologia da Microsoft que foi criada com objetivo de substituir a
tecnologia ASP (Application Server Pages), também da Microsoft. De acordo com Hasan e
Tu (2003, tradução nossa) “a plataforma ASP.NET é construída com uma arquitetura
extensível que fornece uma excelente performance e uma metodologia lógica para responder
às solicitações de clientes”.
7
Segundo Johnson e Northrup (2007), as páginas ASP.NET também são conhecidas
como Web Forms, que suportam grande conjunto de componentes, possuem código HTML
separado da lógica de programação (code behind), são extensíveis e fornecem suporte ao
ViewState – uma técnica de gerenciamento de estado do lado do cliente que permite o
tratamento de dados e configurações das páginas, entre as requisições, de forma transparente
para o desenvolvedor. Além disso, o ASP.NET permite realizar o gerenciamento de estado, do
lado do servidor, em nível de aplicação (Application State) e em nível de usuário (Session
State).
Conforme pode ser visto na figura 5, a configuração das aplicações do ASP.NET,
segundo Johnson e Northrup (2007), é realizada de forma hierárquica através de arquivos e
configuração XML. Configurações em nível de servidor são realizadas no arquivo
Machine.config, que fica instalado no mesmo local que o framework .NET utilizado. Abaixo
deste arquivo, a configuração é realizada em nível de diretório, através de arquivos
web.config. O arquivo web.config que fica na pasta-raiz da aplicação é responsável pela
configuração da aplicação como um todo, mas outros arquivos podem ser inseridos em seus
subdiretórios para configurações específicas.
Figura 5 – Exemplo de hierarquia de configuração no ASP.NET.
(JOHNSON; NORTHTUP, 2007, tradução nossa).
3.3. OTIMIZAÇÃO DO LADO SERVIDOR
Segundo Souders (2008, pos. 286), “menos de 10 a 20% do tempo de resposta de uma
página da web é gasto na transferência do documento HTML do cliente para o servidor”.
Neste tempo de envio do documento HTML, é considerado, também, o tempo de geração
deste documento pelo servidor web.
Quando o website serve páginas com conteúdo dinâmico, o tempo de geração do
conteúdo é influenciado diretamente por parâmetros relacionados à programação das páginas:
as fontes de dados utilizadas, a maneira de escrever o código, os recursos utilizados do
servidor, o gerenciamento de memória, dentre outros.
8
Perdeck (2010) classifica o tempo de geração de conteúdo e disponibilização para o
cliente como “tempo para primeiro byte”. Segundo ele, a redução deste tempo é importante
para a retenção do usuário como visitante do website e os principais gargalos causados do
lado servidor de uma aplicação ASP.NET são: sobrecarga de memória, caching, utilização de
CPU, utilização de threads e tempo longo de espera por recursos externos.
Hasan e Tu (2003, tradução nossa) complementam que “os impactos das decisões de
desenho da aplicação podem ser profundas, tanto no desempenho quanto na complexidade do
código”. Segundo eles, quando a escolha de um componente para o desenvolvimento de
determinada funcionalidade é realizada, ela deve feita de forma consciente, considerando os
benefícios do novo componente e os impactos que trará para o desempenho da aplicação.
De acordo com Perdeck (2010, tradução nossa), “antes de aprofundar e realizar
alterações em seu website, é importante identificar os gargalos mais significantes. Isso lhe
ajudará a priorizar as áreas para correção e utilizar melhor o seu tempo.”
3.3.1. O DESEMPENHO DO IIS
Do ponto de vista da administração de um servidor web, Stanek (2007) acredita que
gargalos podem ser causados por processos sendo executados no servidor e concorrendo pelo
uso de memória e CPU com os processos do IIS, problemas de hardware que podem causar
lentidão – como discos rígidos defeituosos, por exemplo – e páginas web que executam
procedimentos desnecessários ou ineficientes.
“Para obter o melhor desempenho do servidor, é necessário identificar gargalos,
maximizar a vazão e minimizar o tempo utilizado por aplicações web para processar
requisições dos usuários.” (STANEK, 2007).
Stanek (2007) afirma que alguns processos importantes são necessários para extrair o
melhor desempenho do servidor:
Monitoramento da utilização de CPU e memória, realizando passos necessários
durante o monitoramento para diminuir a carga do servidor ou a concorrência entre
processos;
Substituição, conserto ou incremento de itens de hardware que podem estar
causando problemas, como um disco rígido com atraso na escrita ou leitura ou
placas de redes que estejam sobrecarregadas;
De acordo com Stanek (2007), antes de realizar qualquer monitoramento no IIS, é
recomendável criar uma linha de base de métricas de desempenho para o servidor, que será
utilizada para comparar o desempenho antes e depois das mudanças, quando realizadas. A
criação desta linha de base pode ser feita através do acompanhamento da medição de
variáveis pré-determinadas em diferentes momentos.
Para monitorar os diversos recursos de um servidor IIS com sistema operacional
Windows, as principais ferramentas são:
9
Windows Performance Monitor: permite a configuração de contadores para
acompanhar a utilização de recursos. A informação gerada por ele pode ser
utilizada para determinar as áreas que devem ser otimizadas;
Windows Reliability Monitor: com esta ferramenta, você poderá visualizar de
forma gráfica a relação entre as modificações realizadas no sistema e os efeitos
sobre a estabilidade do servidor;
IIS Access Logs: arquivos de log gerados pelo servidor web são úteis para
encontrar problemas em páginas, aplicações e também no próprio IIS;
Windows Event Logs: através dos logs de eventos do Windows, é possível
identificar problemas ocorridos com o sistema operacional, com suas aplicações e
com os serviços em execução.
Através do resultado fornecido pelas ferramentas de monitoramento, pode-se tomar
decisões e realizar mudanças nas configurações de software ou hardware do servidor para
obter melhor resultado de desempenho.
De acordo com Stanek (2007), a memória RAM é uma fonte frequente de problemas
relacionados à lentidão e é recomendável avaliá-la antes de examinar outras áreas do sistema.
Ele afirma também que a memória RAM geralmente deve ficar com disponibilidade de, no
mínimo, 5% em relação à quantidade total de memória física. Portanto, se o servidor estiver
com pouquíssima memória RAM disponível (menos de 5%), uma solução pode ser
acrescentar mais memória ao sistema.
Ainda conforme Stanek (2007), incluir mais memória RAM não irá solucionar o
gargalo se o servidor estiver com problemas de configuração de cache ou configuração de
memória virtual e paginação. Stanek (2007) afirma que embora o objetivo do caching seja
melhorar o desempenho, seu uso em excesso ou sua configuração feita de forma errônea
podem causar efeitos negativos no sistema, propiciando o excesso de consumo de memória
RAM. Para evitar problemas como esse, é importante gerenciar o tempo de vida dos objetos
em cache de forma adequada. Se a liberação dos objetos de cache estiver ocorrendo
lentamente, você deve diminuir o tempo de vida dos objetos. Caso contrário, você pode
aumentá-los até o nível que não comprometa o sistema.
Stanek (2007, tradução nossa) afirma que “o acesso à memória RAM é muito mais
rápido que o acesso a discos”. Perdeck (2010, tradução nossa) complementa que “quando o
servidor estiver com memória RAM insuficiente para suprir a demanda, o aumento de
consumo de CPU e I/O aumentará em função do mecanismo de paginação (swap) utilizado
pelo sistema operacional”.
No Windows, há duas áreas de memórias: área paginada (que pode ser transferida para
o disco rígido quando não estiver sendo utilizada) e a área não paginada. Para melhorar o
desempenho, se o tamanho da área paginada for muito grande em relação à quantidade de
memória física atual, você pode aumentar a quantidade de memória. Da mesma forma, se a
área não paginada, você pode aumentar a quantidade de memória virtual destinada ao sistema.
10
Outro recurso de hardware que impacta significativamente no desempenho dos
servidores web é a CPU, no entanto, Stanek (2007) recomenda direcionar os esforços para
resolver os problemas de CPU somente após eliminar os gargalos de memória RAM.
Segundo Perdeck (2010), cada requisição HTTP feita ao IIS é executada em uma
thread diferente no servidor, no entanto, a quantidade máxima de threads que podem ser
utilizadas é limitada pelo IIS. Quando uma requisição é realizada e a quantidade de threads
em execução já atingiu o máximo estabelecido pelo IIS, a requisição é enfileirada em uma
área compartilhada por todos os processadores do sistemas até que haja disponibilidade de
resposta pelo servidor. Quando a fila estiver muito grande ou o tempo para resposta à
requisição for muito longo, a requisição é rejeitada e descartada pelo IIS. Perdeck (2010)
recomenda que se adicione novos processadores aos existentes ou atualize os mesmos se a
quantidade de threads enfileiradas frequentemente for maior ou igual a 10, o que, segundo
ele, também é recomendável se o percentual de tempo de utilização de CPU estiver alto
enquanto a vazão de I/O das interfaces de rede e/ou dos discos rígidos estiver relativamente
baixa.
Contudo, Stanek (2007) afirma que os discos rígidos raramente são causadores de
gargalos, levando em consideração que no mercado há grande quantidade de discos rígidos de
alta velocidade disponíveis no mercado e existem possibilidades de incremento desta
velocidade através de técnicas como RAID.
“No mundo real, na maioria dos casos, um único servidor não é suficiente para
suportar o tráfego de rede. Nesse caso, você pode escalar seu website através de múltiplos
servidores” (STANEK, 2007).
3.3.2. O DESEMPENHO DA APLICAÇÃO
Segundo Stanek (2007), a otimização das páginas web e das aplicações que estão
sendo executadas pelo IIS podem colaborar para a melhoria do desempenho de um servidor
web através da eliminação de procedimentos desnecessários e otimização de processos
ineficientes.
Realizar o gerenciamento adequados dos recursos de memória RAM utilizados pela
aplicação é o primeiro passo para evitar gargalos no servidor. O ASP.NET possui um recurso
para disponibilização de memória denominado Garbage Collector, que possui a função de
liberar memória para novas instâncias de objetos.
Segundo Perdeck (2010), quando uma nova instância de um tipo ou objeto é realizada,
se não houver memória disponível para aquele novo objeto, o Garbage Collector inicia a
limpeza dos recursos de memória não utilizados pela aplicação. A verificação de recursos não
utilizados e disponibilização de memória são procedimentos “caros” do ponto de vista
computacional. Diante disso, Perdeck (2010), sugere algumas práticas para otimizar o
desempenho no gerenciamento de memória:
Instancie tarde: crie as instâncias de objetos o mais tarde possível. Isso economiza
memória e evita objetos com ciclo de vida longo em memória;
Libere cedo: se um objeto for necessário por um curto espaço de tempo, faça com
que ele seja anulado imediatamente após o seu uso;
11
Utilize a classe StringBuilder para concatenar strings (cadeias de caracteres):
cadeias de caracteres são objetos imutáveis na memória. Sempre que você
concatena um objeto string diretamente com outro objeto string, você cria um
novo objeto em memória. Com o StringBuilder, a concatenação de strings não cria
objetos grandes ou intermediários na memória.
Implemente a interface IDisposable em suas classes: a interface IDisposable,
disponibilizada pelo framework .NET, expõe o método Dispose(), que deve ser
utilizado para anular o objeto instanciado. Quando a interface IDisposable é
implementada em uma classe, o objeto pode ser instanciado utilizando a palavra
reservada using, que ao final do bloco chama o método Dispose()
automaticamente, conforme a figura 6.
using (MeuObjeto obj = new MeuObjeto())
{
// utilize o objeto MeuObjeto...
} // ao final do bloco, o obj.Dispose() é chamado.
Figura 6 – Exemplo da utilização de using e Dispose()
A utilização da CPU também é um ponto crítico para a otimização de aplicações web.
Perdeck (2010) relatou, também, algumas práticas importantes para reduzir ou otimizar
recursos de processamento:
Utilizar o pool de conexões: O ASP.NET mantém um pool de conexões a bancos
de dados abertas. Para cada string de conexão, um pool de conexões é criado.
Quando houver a necessidade de abrir uma nova conexão, mantenha sempre a
mesma string de conexão, para que o ASP.NET possa lhe fornecer alguma das
conexões já abertas no pool;
Utilizar List<T> ao invés de DataSet: Testes realizados por Perdeck (2010)
comprovaram que a utilização de coleções genéricas, como List<T>, fornece
melhor desempenho de processamento quando comparadas a objetos de dados do
ADO.NET, como o DataSet;
Obter múltiplos ResultSets: Ao executar scripts para obter dados em um banco de
dados, utilize o recurso do ADO.NET que permite obter retorno de vários
ResultSets de uma só vez;
Agrupar comandos de inserção: Quando for necessário inserir dados em um banco
de dados, agrupe todos os comandos de INSERT, separando-os por ponto-e-vírgula
(;) e envie de uma só vez ao banco de dados. Com isso, você economizará tempo
de espera ao retorno do banco de dados, ciclos de CPU e tempo de execução de
threads;
Utilizar provedores de dados nativos: quando possível, utilize provedores de dados
nativos do ADO.NET como System.Data.OleDb e System.Data.ODBC ao invés de
provedores específicos como System.Data.SqlClient ou System.Data.OracleClient.
Os provedores nativos tendem a ter um melhor desempenho em função da
abstração menor;
12
Evitar exceções: o disparo de exceções é “caro” do ponto de vista computacional.
Não utilize exceções para realizar controle do fluxo da aplicação, mas somente
quando não houver outra saída e for extremamente necessário;
Evitar DataBinder.Eval: Quando for necessário utilizar componentes de repetição
em páginas web – tais como GridView ou Repeater – ao invés de utilizar Eval, ou
DataBinder.Eval na página aspx para buscar os dados na coleção de origem,
converta o Container.DataItem na sua classe de origem e utilize seus atributos.
Outro mecanismo importante para a otimização de uma aplicação web é o caching. O
caching é uma forma de armazenar uma cópia da última versão de um recurso do servidor por
determinado tempo, para evitar que o mesmo seja gerado a cada requisição. De acordo com
Perdeck (2010), no ASP.NET, do lado servidor, há três tipos importantes de caching: o output
caching (cache de saída) e o data caching (cache de dados), que é utilizado para realizar o
armazenamento temporário de objetos de dados específicos.
A ativação do Output Caching é realizada através dos arquivos de configuração
web.config ou diretamente no cabeçalho de um web form. Quando é habilitada, o servidor
inclui os campos Cache-Control e Expires na resposta HTTP dada ao cliente.
Souders (2008, pos. 770-778) explica que a inclusão e controle de cache nos
componentes de uma página web evita a realização de requisições HTTP desnecessárias pelo
cliente ao servidor.
O data caching é utilizado via programação e é útil para o armazenamento de objetos
específicos, evitando conexões desnecessárias a recursos de dados externos. Imagine, por
exemplo, que em determinada tela de um website há um componente que exibe a lista de
todas as unidades federativas do Brasil e essas UFs são buscadas diretamente em uma base de
dados do IBGE. A inclusão ou alteração de UFs de um país não é frequente, portanto, a lista
de UFs seria uma forte candidata a ser armazenada em data caching.
Para evitar bloqueios durante a execução e permitir a execução paralela de diversas
tarefas pelo servidor web, Perdeck (2010) recomenda também a utilização de threads para
operações que podem ser assíncronas, como o acesso a webservices, o acesso à camada de
dados, a utilização de handlers genéricos (ashx) para chamadas externas e a escrita em
arquivos físicos.
Perdeck (2010) e para Souders (2008) compartilham da opinião que a ativação de
compressão GZIP no servidor é muito importante para reduzir o tempo transferência de dados
do servidor para o cliente. Mas é importante estar atento à utilização de CPU após a ativação
da compressão, pois ela requer mais processamento do servidor. Ativar a compressão em
conjunto com output caching é uma prática recomendada.
4. O LADO CLIENTE
Segundo Souders (2008), 80 a 90% do tempo de resposta de um website é gasto lado
cliente, através do download e renderização de componentes da página, tais como estilos CSS,
imagens, arquivos de scripts, dentre outros.
13
4.1. NAVEGADOR DE INTERNET
Para que um usuário tenha acesso e consiga visualizar um website, é necessário que
ele utilize um browser – ou navegador de internet. O navegador é um aplicativo que faz o
papel de cliente em uma aplicação web, que utiliza o conceito cliente/servidor.
Segundo Smith (2013, tradução nossa), “navegadores de internet são uma das peças
mais importantes do software na internet moderna e a competição entre fornecedores é
cruel[...]” e “[...] esta competição é uma boa notícia para os consumidores, mas é bem
diferente para os desenvolvedores, que devem ajustar seus websites para serem exibidos em
diversos navegadores, que muitas vezes não se comportam de forma padrão.”.
Há diversos navegadores no mercado. Como é possível ver na figura 7, segundo a
StatCounter5 (2013), os navegadores Google Chrome, Internet Explorer (IE) e Firefox
mantém a liderança do mercado. É através do navegador que o usuário percebe a velocidade
com que um website é carregado. Assim como é através do navegador que o usuário pode sair
de um site caso se sinta frustrado com a lentidão e ir diretamente para o site do possível
concorrente.
Para monitorar o tempo de resposta de um website do lado cliente, algumas
ferramentas - que permitem o monitoramento das requisições, o debug de código JavaScript,
dentre outras funcionalidades - são disponibilizadas pelos fornecedores de navegadores ou
pela comunidade de desenvolvimento open-source:
No Google Chrome, a ferramenta Developer Tools é fornecida de forma integrada
ao navegador, sem a necessidade de instalar nenhum plug-in adicional;
A partir do Internet Explorer 8, a Microsoft disponibiliza de forma integrada ao
seu navegador as “Ferramentas para Desenvolvedores”;
No Firefox, não há ferramenta nativa de auxilio ao desenvolvimento, mas é
possível instalar o plug-in FireBug, que é um dos mais utilizados por
desenvolvedores web.
5 A StatCounter é uma empresa irlandesa que oferece serviços de contagem de visitas a websites. Através de seus
contadores, ela obtém informações sobre a navegação dos usuários, como o sistema operacional, o navegador,
dentre outras.
14
Figura 7 – 5 navegadores mais utilizados no mundo de Abril/2012 a Março/2013.
(STATCOUNTER, 2013).
Figura 8 – Ferramenta de desenvolvimento do Google Chrome.
(Fonte: captura de tela).
15
4.2. OTIMIZAÇÃO DO LADO CLIENTE
Souders (2008) afirma que para cada arquivo referenciado no documento HTML, o
navegador precisa realizar uma requisição HTTP GET com o objetivo de buscar o recurso no
servidor correspondente. Contudo, há limites de velocidade da rede do cliente e também de
requisições simultâneas pelo navegador que podem causar atrasos na realização dessas
requisições.
Souders (2008, tradução nossa) constatou que o tempo para obter o conteúdo da
página (HTML) geralmente não ultrapassa 20% do tempo de resposta. Portanto, ele afirma
que “[...] há mais potencial para melhoria focando no lado cliente”, e complementa que:
[...] se conseguirmos reduzir o tempo do lado servidor pela metade, nós
estaremos reduzindo apenas 5% a 10% do todo. Contudo ao, melhorarmos o desempenho do lado cliente pela metade, estaremos reduzindo o tempo de
resposta do todo entre 40% a 45%.
Para Souders (2008), alguns pontos afetam diretamente o tempo de resposta no cliente:
a quantidade de componentes referenciados em uma página HTML; o tamanho desses
componentes em bytes; a distância entre o cliente e o servidor que hospeda tais componentes;
a quantidade e periodicidade das requisições HTTP ao servidor; o posicionamento dos
componentes no código HTML (se estão no topo, no meio ou no final do arquivo); a forma de
escrever os estilos CSS; caching; DNS e redirecionamentos.
Perdeck (2010), acredita que também alguns itens específicos do ASP.NET podem
afetar diretamente o tempo de resposta, tais como: o tamanho do ViewState gerado pelos web
forms; a quantidade de HTML gerado pelos componentes ASP.NET; o limite de requisições
que podem ser efetuadas paralelamente pelo navegador e o tempo de carregamento de
arquivos JavaScript.
Diante dos problemas que podem causar impacto negativo no tempo de resposta,
algumas medidas práticas foram propostas por Souders (2008; 2009) e Perdeck (2010):
Reduzir as requisições HTTP: retirar algumas referências que não são importantes
no HTML, juntar arquivos de scripts e imagens são apenas algumas das formas de
reduzir a quantidade de requisições HTTP realizadas pelo navegador. No caso das
imagens, é possível utilizar a metodologia conhecida como sprite, que realiza a
junção de várias imagens em um só arquivo físico, realizando a exibição na página
através da posição da imagem;
Utilizar uma CDN (Content Delivery Network): uma CDN é uma rede de
servidores de alto desempenho destinada a fornecer conteúdo estático. Quando um
cliente faz uma requisição de uma imagem, por exemplo, a CDN automaticamente
redireciona as requisições para o servidor geograficamente mais próximo do
cliente;
Posicionar as folhas de estilo CSS no topo do HTML: quando as referências a
arquivos CSS são colocadas no final do arquivo HTML, o navegador bloqueia a
exibição da página até que todos os elementos sejam carregados. Quando o CSS é
colocado no cabeçalho (head) da página, o navegador carrega e exibe os elementos
16
na tela de forma progressiva, provendo um feedback do carregamento ao usuário,
que de acordo com Nielsen (1993) é uma boa prática de usabilidade;
Colocar os scripts no final do arquivo HTML: ao contrário das folhas de estilo
CSS, quando os scripts e/ou suas referências são colocadas no topo da página, todo
o conteúdo abaixo deles não é exibido de forma progressiva. Quando os scripts são
colocados no final da página, a página carrega progressivamente fornecendo
feedback ao usuário;
Realizar requisições paralelas utilizando vários cabeçalhos de host: por padrão da
especificação HTTP/1.1, os navegadores são limitados a duas requisições paralelas
para cada cabeçalho de host. Para aumentar a quantidade de requisições, pode-se
criar vários endereços DNS para fornecer o conteúdo de forma paralela para
melhorar o tempo de download;
Evitar expressões CSS: para definir estilos CSS dinamicamente, é possível utilizar
as expressões CSS. As expressões CSS funcionam apenas no Internet Explorer e
aceitam, como parâmetro, a utilização de código JavaScript. O grande problema é
que a cada renderização da página (como no momento em que a rolagem é
utilizada ou há algum movimento com o mouse, por exemplo) as expressões são
executadas novamente, ocasionando em perda de performance da página. Além
disso, se uma expressão estiver referenciada por uma classe CSS, e esta for
utilizada por 50 componentes da página, a expressão será executada pelo menos 50
vezes;
Utilizar JavaScript em arquivos externos: embora a execução de código JavaScript
inline (escrito no próprio HTML) seja mais rápida do ponto de vista da execução
inicial – pelo fato de não ser necessário o download do arquivo externo -, a
utilização de arquivos externos à página e referenciados no HTML habilita a
possibilidade de armazená-los em cache, fazendo com que o usuário não tenha que
recarregar aquele código em páginas que utilizam o mesmo script ou nas visitas
futuras àquela página;
Minimizar (minify) os arquivos JavaScript e CSS: Minification é o nome da técnica
de remover caracteres desnecessários do código. Quando o código é minimizado,
todos os comentários, espaços em branco e quebras de linha são removidos,
diminuindo significativamente, em bytes, o tamanho dos arquivos JavaScript e
CSS;
Evitar redirecionamentos: quando um redirecionamento HTTP (códigos de status
300 a 307) é utilizado, todas as outras requisições da página são paralisadas até
que o redirecionamento seja finalizado, fazendo com que nenhum elemento seja
exibido na página durante este processamento;
Remover referências duplicadas a scripts: Quando um arquivo de script é
referenciado duas vezes, navegadores como Internet Explorer fazem duas
requisições ao mesmo arquivo. Além disso, a execução do script pode ser
prejudicada diretamente.
17
5. RESULTADOS
Para atestar a eficiência das diretrizes sugeridas neste trabalho, alguns autores
pesquisados realizaram experiências práticas que envolviam métricas específicas para cada
situação.
Algumas diretrizes recomendadas para o lado servidor, foram medidas por Perdeck
(2010) através de ciclos de CPU, comparando a execução entre códigos antes e depois de
aplicar cada diretriz. Para cada diretriz medida, o percentual de melhoria em relação à redução
de ciclos de CPU é informado no quadro 1:
Diretriz Melhoria
Utilizar List<T> ao invés de DataSet 19,26%
Obter múltiplos RecordSets 16,57%
Agrupar comandos de inserção 44,89%
Evitar exceções (utilizou Int32.TryParse ao invés de disparar exceção) 99,85%
Evitar DataBinder.Eval 93,28%
Quadro 1 – Percentual de melhoria em diretrizes do lado servidor.
Para as diretrizes do lado cliente, Souders (2008) criou um site com diversos testes e
disponibilizou no endereço http://stevesouders.com/hpws/ para que qualquer usuário possa,
também, executá-los. Algumas diretrizes puderam ser medidas por Souders através do tempo
de resposta da página web em milissegundos. No quadro 2, o percentual de melhoria para
estas diretrizes foram indicados com base nos registros que Souders (2008) demonstrou em
seu livro, utilizando internet com velocidade aproximada de 900 Kbps e o navegador Internet
Explorer 6.0:
Diretriz Melhoria
Reduzir as requisições HTTP 50% ou mais
Utilizar uma CDN 18%
Minizar arquivos JavaScript e CSS 21-25%
Quadro 2 – Percentual de melhoria em diretrizes do lado cliente.
As diretrizes do lado cliente que não foram listadas no quadro 1 dependem de outras
variáveis – subjetivas ou complexas – para serem medidas. Como, por exemplo, a diretriz
“Posicionar as folhas de estilo CSS no topo do HTML”, que conforme afirma Souders (2008),
afeta diretamente na percepção do usuário sobre o carregamento da página.
6. CONCLUSÃO
Unir técnicas para otimização, tanto do lado cliente quanto do lado servidor, é uma
forma poderosa de tornar aceitável o desempenho de um website e tempo de resposta
adequado para a maioria dos usuários, que estão se tornando cada vez mais exigentes em
relação à velocidade.
Através dos resultados, foi possível perceber que as melhorias realizadas do lado
servidor possuem, de forma geral, um percentual de melhoria maior quando aplicadas
pontualmente. Contudo, é importante também estar atento ao lado servidor para que as
18
mudanças surtam efeito direto para o usuário, considerando que o processamento no servidor
é realizado até que o primeiro byte seja enviado ao navegador.
Conclui-se que o bom desempenho de um website é fruto de um conjunto de fatores
associados: a conexão do cliente, a conexão entre componentes que compõe a arquitetura da
aplicação e suas respectivas fontes de dados, o hardware do(s) servidor(es), o código-fonte da
aplicação, a organização dos dados e dos arquivos e/ou páginas utilizadas, a distribuição
geográfica, dentre outros.
7. TRABALHOS FUTUROS
Sugere-se, como temas para trabalhos futuros, a experimentação prática das diretrizes
relacionadas neste trabalho, por exemplo, através do monitoramento e registro científico das
métricas avaliadas ou da implementação de provas de conceito que abordem os preceitos aqui
indicados.
8. GLOSSÁRIO
Byte: unidade de medida de informação, equivalente a oito bits.
Feedback: retorno, resposta, reação a alguma coisa.
Framework: conjunto de conceitos ou de classes implementadas com o objetivo de
prover funcionalidades genéricas, que podem ser utilizadas por diversos programas de
computador.
Hardware: conjunto de elementos físicos (mecânicos e/ou eletrônicos) necessários
para o funcionamento um computador ou parte dele.
Software: programa de computador.
Thread: divisão de um processo realizada por um sistema operacional para permitir a
execução de tarefas de forma concorrente ou simultânea.
Web: redução do termo world wide web. Representa o sistema de interligação de
documentos e recursos através da internet.
Website (ou site): Página ou conjunto de páginas da internet com informação diversa,
acessível através de computador ou outro meio eletrônico.
9. REFERÊNCIAS
IETF. RFC 2616: Hypertext Transfer Protocol – HTTP/1.1. 1999. Disponível em
<http://www.ietf.org/rfc/rfc2616.txt>. Acessado em 30/03/2013, às 17:44.
GRADY, R. B. Practical Software Metrics for Project Management and Process
Improvement. Prentice Hall. 1992.
GOURLEY, D; TOTTY, B. HTTP: The Definitive Guide. O’Reilly. 2002.
19
JOHNSON, G; NORTHRUP, T. Microsoft .NET FRAMEWORK 2.0: Web-Based
Client Development. Microsoft Press. 2007.
HASAN, J; TU, K. Performance Tuning and Optimizing ASP.NET Applications.
Apress. 2003.
MICHAELIS. Dicionário de Português Online. Acessado em 29/03/2013, às 17:33.
Disponível em <http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues
-portugues& palavra=desempenho>.
MONO. Mono Project: About. Acessado em 31/03/2013, às 10:25. Disponível em
<http://www.mono-project.com/about>.
NETCRAFT. Web Server Survey. 2013. Acessado em 31/03/2013, às 10:25.
Disponível em <http://news.netcraft.com/archives/category/web-server-survey/>.
_______. About NetCraft. Acessado em 31/03/2013, às 10:27. Disponível em
<http://news.netcraft.com/about-netcraft/>.
NIELSEN, J. Website Response Times. 2010. Acessado em 29/03/2013, às 17:54.
Disponível em < http://www.nngroup.com/articles/website-response-times/>;
_______. Usability Engineering. Ed. Morgan Kaufmann.1993.
PERDECK, M. ASP.NET Site Performance Secrets. Packt Publishing. 2010.
PRIBERAM INFORMÁTICA. Dicionário Priberam da Língua Portuguesa. 2011.
Edição digital para dispositivo Amazon Kindle.
SOUDERS, S. High Performance Web Sites. O’Reilly Media. 2008. Edição digital
para dispositivo Amazon Kindle.
_______. Even Faster Web Sites. O’Reilly Media. 2009. Edição digital para
dispositivo Amazon Kindle.
STANEK, W. R. Internet Information Services (IIS) 7.0 Administrator’s Pocket
Consultant. Microsoft Press. 2007.
_______. Even Faster Web Sites. O’Reilly Media. 2009. Edição digital para
dispositivo Amazon Kindle.
SMITH, P. G. Professional Website Performance: Optimizing the Front End and the
Back End. John Wiley & Sons, Inc. 2013.
STATCOUNTER. Top 5 browsers from Apr 2012 to Mar 2013. Acessado em
31/03/2013, às 21:44. Disponível em <http://gs.statcounter.com/#browser-ww-monthly-
201204-201303>.
W3TECHS. Usage of server-side programming languages for websites. 2013.
Acessado em 31/03/2013, às 11:46. Disponível em <http://w3techs.com/technologies/
overview/programming_language/all>.
20
ZIMMERMANN, H. OSI Reference Model – The ISO Model of Architecture for Open
Systems Interconnection. 1980. Disponível em <http://impact.asu.edu/~mcn/cse534fa06/
reading/RightsManagement_eid%3D136833.pdf>. Acessado em 30/03/2012, às 18:02.
