O desempenho é um recurso. Você precisa projetar o desempenho antecipadamente ou terá que reescrever seu aplicativo mais tarde. Dito isso, quais são algumas boas estratégias para maximizar o desempenho de aplicativos Active Server Pages (ASP)?
Este artigo descreve técnicas para otimizar aplicativos ASP e Visual Basic® Scripting Edition (VBScript). Este artigo discute uma série de armadilhas. As sugestões listadas neste artigo foram testadas em http://www.microsoft.com e em outros sites, e os resultados foram muito significativos. Este artigo pressupõe que você já tenha um conhecimento básico de desenvolvimento ASP, incluindo VBScript e/ou JScript, Aplicativo ASP, Sessão ASP e outros objetos inerentes ao ASP (Solicitação, Resposta e Servidor).
Normalmente, o desempenho do ASP depende principalmente de muitos fatores além do próprio código ASP. Em vez de listar todas as informações em um artigo, listamos os recursos relacionados ao desempenho no final do artigo. Esses links cobrem tópicos ASP e não ASP, incluindo ActiveX® Data Objects (ADO), Component Object Model (COM), bancos de dados e configuração do Internet Information Server (IIS). Estes são alguns dos nossos links favoritos - não deixe de conferir.
Dica 1: Armazene em cache os dados usados com freqüência no servidor Web
Uma página ASP típica recupera dados de um armazenamento de dados back-end e depois converte os resultados em Hypertext Markup Language (HTML). Independentemente da velocidade do banco de dados, a recuperação de dados da memória é sempre muito mais rápida do que a recuperação de dados do armazenamento de dados back-end. A leitura de dados de um disco rígido local também é geralmente mais rápida do que a recuperação de dados de um banco de dados. Portanto, muitas vezes o desempenho pode ser melhorado armazenando dados em cache no servidor Web (armazenados na memória ou no disco).
O cache é a forma tradicional de trocar espaço por tempo. Se você armazenar em cache o conteúdo correto, poderá ver uma melhoria significativa no desempenho. Para que o armazenamento em cache seja eficaz, os dados que são frequentemente reutilizados devem ser salvos, e o recálculo desses dados requer uma sobrecarga (moderadamente) grande. Se o cache contiver todos os dados desatualizados, isso causará desperdício de memória.
Dados que mudam com pouca frequência são bons candidatos para armazenamento em cache porque você não precisa se preocupar em sincronizar esses dados com o banco de dados ao longo do tempo. Listas de caixas de combinação, tabelas de referência, fragmentos DHTML, strings Extensible Markup Language (XML), itens de menu e variáveis de configuração de site (incluindo nomes de fontes de dados (DSNs), endereços de protocolo de Internet (IP) e caminhos da Web) são todos bons caches Candidato contente. Observe que você pode armazenar em cache uma "representação" dos dados sem armazenar em cache os dados em si. Se a página ASP muda raramente e é cara para armazenar em cache (por exemplo, um catálogo inteiro de produtos), considere gerar o HTML antecipadamente em vez de exibi-lo novamente em resposta a cada solicitação.
Onde os dados devem ser armazenados em cache e quais estratégias de armazenamento em cache existem? Normalmente, os dados são armazenados em cache na memória ou no disco do servidor Web. As próximas duas dicas cobrem ambos os métodos.
Dica 2: Armazene em cache os dados usados com frequência em objetos Aplicativo ou Sessão.
Os objetos Aplicativo e Sessão ASP fornecem contêineres convenientes para armazenar dados em cache na memória. Você pode atribuir dados a objetos Aplicativo e Sessão, e os dados permanecem na memória entre chamadas HTTP. Os dados da sessão são armazenados separadamente para cada usuário, enquanto os dados do aplicativo são compartilhados entre todos os usuários.
Quando os dados devem ser carregados no Aplicativo ou na Sessão? Normalmente, os dados são carregados quando o Aplicativo ou Sessão é iniciado. Para carregar dados durante a inicialização do Aplicativo ou da Sessão, adicione o código apropriado a Application_OnStart() ou Session_OnStart() respectivamente. Essas funções devem estar em Global.asa, caso contrário você pode adicioná-las. Esses dados também podem ser carregados na primeira vez que forem necessários. Para fazer isso, adicione algum código à página ASP (ou escreva uma função de script reutilizável) para verificar se os dados existem e, se não, carregue os dados. Esta é uma técnica de desempenho tradicional chamada “avaliação preguiçosa” – não calcular um valor até saber que precisa dele. Por exemplo:
<%
Função GetEmploymentStatusList
Escurecer
d = Aplicativo(?EmploymentStatusList?)
Se d = ??Então
' Função FetchEmploymentStatusList (não mostrada)
'busca dados do banco de dados, retorna um Array
d = FetchEmploymentStatusList()
Aplicativo(?EmploymentStatusList?) = d
Terminar se
GetEmploymentStatusList = d
Função final
%>
Funções semelhantes podem ser escritas para cada bloco de dados necessário.
Em que formato os dados devem ser armazenados? Qualquer tipo de variante pode ser armazenado porque todas as variáveis de script são tipos de variante. Por exemplo, você pode armazenar strings, inteiros ou arrays. Normalmente, você armazenará o conteúdo de um conjunto de registros ADO em um desses tipos de variáveis. Para obter dados de um conjunto de registros ADO, você pode copiar manualmente os dados em variáveis VBScript, um campo por vez. É mais rápido e fácil usar uma das funções de persistência do conjunto de registros ADO GetRows(), GetString() ou Save() (ADO 2.5). Os detalhes estão além do escopo deste artigo, mas aqui está um exemplo de uma função que usa GetRows() para retornar um array de dados do conjunto de registros:
' Get Recordset, return as an Array
Função FetchEmploymentStatusList
Escurece
Definir rs = CreateObject(?ADODB.Recordset?)
rs.Open ?selecione StatusName, StatusID de EmployeeStatus?, _
?dsn=funcionários;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() Retorna dados como um array
rs.Fechar
Setrs=Nada
End Function
melhora ainda mais o exemplo acima, armazenando HTML em cache como uma lista em vez de um array. Aqui está um exemplo simples:
'Obter conjunto de registros, retornar como lista de opções HTML
Função FetchEmploymentStatusList
Dim rs, fldNome, s
Definir rs = CreateObject(?ADODB.Recordset?)
rs.Open ?selecione StatusName, StatusID de EmployeeStatus?, _
?dsn=funcionários;uid=sa;pwd=;?
s = ?<selecionar nome=??EmploymentStatus??> & vbCrLf
Set fldName = rs.Fields(?StatusName?) ' Vinculação de campo ADO
Faça até rs.EOF
' A próxima linha viola Don't Do String Concats,
' mas está tudo bem porque estamos construindo um cache
s = s & ? <opção>? & fldName & ?</option>?
rs.MoveNext
Laço
s = s & ?</select>?
rs.Fechar
Set rs = Nothing 'Ver lançamento antecipado
FetchEmploymentStatusList = s ' Retorna dados como uma String
Função final
Sob condições apropriadas, o próprio conjunto de registros ADO pode ser armazenado em cache no escopo do Aplicativo ou da Sessão. Há duas advertências:
o ADO deve ser marcado como free-threaded e conjuntos de registros desconectados devem ser usados.
Se esses dois requisitos não forem garantidos, não armazene em cache o conjunto de registros ADO. Nas dicas a seguir sobre "Componentes não ágeis" e "Não armazenar conexões em cache", discutimos os perigos de armazenar objetos COM no escopo Aplicativo ou Sessão.
Quando você armazena dados no escopo Aplicativo ou Sessão, os dados permanecem lá até que você os altere programaticamente, a Sessão expire ou o aplicativo Web seja reiniciado. E se os dados precisarem ser atualizados? Para forçar manualmente uma atualização dos dados do Aplicativo, você pode acessar uma página ASP somente de administrador para atualizar os dados. Alternativamente, você pode atualizar automaticamente os dados em intervalos regulares por meio de uma função. O exemplo a seguir armazena um carimbo de data/hora com dados armazenados em cache e atualiza os dados após um determinado período de tempo.
<%
' processamento de erro não mostrado...
Const UPDATE_INTERVAL = 300 ' Intervalo de atualização, em segundos
' Função para retornar a lista de status de emprego
Função GetEmploymentStatusList
Atualizar Status de Emprego
GetEmploymentStatusList = Aplicativo(?EmploymentStatusList?)
End Function
'Atualiza periodicamente os dados em cache
SubatualizaçãoEmploymentStatusList
Dim d, strLastUpdate
strLastUpdate = Aplicativo(?ÚltimaAtualização?)
Se (strLastUpdate = ??) Ou _
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) Then
' Nota: duas ou mais chamadas podem entrar aqui.
'resulta em algumas buscas desnecessárias (há uma solução alternativa para isso)
' Função FetchEmploymentStatusList (não mostrada)
'busca dados do banco de dados, retorna um Array
d = FetchEmploymentStatusList()
' Atualize o objeto Aplicativo. Use Application.Lock().
'para garantir dados consistentes
Aplicativo.Lock
Aplicativo(?EmploymentStatusList?) = Eventos
Aplicativo(?ÚltimaAtualização?) = CStr(Agora)
Aplicativo.Desbloquear
Terminar se
Finalizar sub
Veja ListBox mais rápido do mundo com dados de aplicativos, que também tem um exemplo.
Esteja ciente de que armazenar grandes arrays em cache em objetos Session ou Application não é uma boa prática. A sintaxe da linguagem de script exige que todo o array seja copiado temporariamente antes de acessar qualquer elemento do array. Por exemplo, se você armazenar em cache uma matriz de cadeias de caracteres de 100.000 elementos que mapeia códigos postais dos EUA para estações meteorológicas locais em um objeto Aplicativo, o ASP deverá primeiro copiar todas as 100.000 estações meteorológicas em uma matriz temporária. Somente então uma cadeia de caracteres poderá ser extraída. Nesse caso, seria melhor construir um componente personalizado com um método personalizado para armazenar a estação meteorológica - ou usar um componente de dicionário.
Apenas mais um aviso: não jogue o bebê fora junto com a água do banho: os arrays podem ser rapidamente consultados e armazenados na memória como pares de dados-chave adjacentes. A indexação de um dicionário é muito mais lenta do que a indexação de um array. Você deve escolher a estrutura de dados que oferece o melhor desempenho para sua situação.
Dica 3: Armazene dados e HTML em cache no disco do servidor Web
Às vezes, pode haver muitos dados para armazenar em cache na memória. "Muitos" é apenas uma maneira de dizer que depende de quanta memória você deseja consumir, bem como de quantos itens você precisa armazenar em cache e com que frequência deseja recuperá-los. Em qualquer caso, se houver muitos dados para serem armazenados em cache na memória, considere armazenar os dados em cache no disco rígido do servidor Web como um arquivo de texto ou XML. Os dados podem ser armazenados em cache no disco e na memória ao mesmo tempo para estabelecer a estratégia de cache mais apropriada para o seu site.
Observe que ao medir o desempenho de uma única página ASP, a recuperação de dados do disco pode não ser necessariamente mais rápida do que a recuperação de dados de um banco de dados. Mas o cache reduz a carga no banco de dados e na rede. Sob carga pesada, isso pode melhorar muito o rendimento geral. Isso é muito eficaz ao armazenar em cache os resultados de consultas caras (como junções de múltiplas tabelas ou procedimentos armazenados compostos) ou grandes conjuntos de resultados. Como sempre, teste os prós e os contras de diversas opções.
ASP e COM fornecem ferramentas para configurar soluções de cache baseadas em disco. As funções Save() e Open() do conjunto de registros ADO salvam e carregam conjuntos de registros do disco. Você pode usar esses métodos para reescrever o exemplo de código na técnica de cache de dados do aplicativo acima, usando Save() do arquivo em vez de gravar o código no objeto Aplicativo.
Existem alguns outros componentes que funcionam com arquivos:
Scripting.FileSystemObject permite criar, ler e gravar arquivos.
O analisador XML da Microsoft® (MSXML) fornecido com o Internet Explorer suporta salvar e carregar documentos XML.
O objeto LookupTable (usado no MSN, por exemplo) é a melhor opção para carregar listas simples do disco.
Por fim, considere armazenar em cache uma representação dos dados no disco, em vez dos dados em si. O HTML pré-convertido pode ser armazenado em disco em arquivos .htm ou .asp, e os hiperlinks podem apontar diretamente para esses arquivos. Você pode usar ferramentas comerciais, como o XBuilder ou o recurso Microsoft® SQL Server® Internet Publishing para automatizar o processo de geração de HTML. Alternativamente, você pode colocar o trecho de código HTML em um arquivo .asp. Você também pode usar FileSystemObject para ler arquivos HTML do disco ou usar XML para convertê-los antecipadamente.
Dica 4: Evite armazenar em cache componentes não ágeis em objetos Aplicativo ou Sessão
Embora o armazenamento em cache de dados em objetos Aplicativo ou Sessão seja uma boa prática, o armazenamento em cache de objetos COM apresenta sérias armadilhas. Normalmente, as pessoas tendem a armazenar em cache objetos COM usados com frequência em objetos Aplicativo ou Sessão. Infelizmente, muitos objetos COM (incluindo todos os objetos escritos em Visual Basic 6.0 ou anterior) causam sérios gargalos quando armazenados em objetos Aplicativo ou Sessão.
Especificamente, quando qualquer componente não ágil é armazenado em cache no objeto Sessão ou Aplicativo, isso causará um gargalo de desempenho. Um componente ágil é um componente marcado com ThreadingModel=Both, que agrega um empacotador de thread livre (FTM) ou um componente marcado com ThreadingModel=Neutral. (O modelo Neutro é novo para Windows® 2000 e COM+.) Os seguintes componentes não são ágeis:
Componentes de thread livre (a menos que agreguem FTM).
Componentes de thread de apartamento.
Componente de rosca única.
Os componentes configurados (bibliotecas Microsoft Transaction Server (MTS)/COM+ e pacotes/aplicativos de servidor) não são ágeis, a menos que sejam threads neutros. Componentes de thread de apartamento e outros componentes não ágeis são mais adequados no escopo da página (ou seja, são criados e destruídos em uma única página ASP).
No IIS 4.0, os componentes marcados com ThreadingModel=Both são considerados ágeis. No IIS 5.0, isso por si só não é suficiente. Os componentes não devem apenas ser marcados como Ambos, mas também devem ser agregados como FTM. O artigo sobre agilidade descreve como agregar FTM com componentes C++ escritos na Active Template Library. Esteja ciente de que se um componente armazenar em cache ponteiros de interface, esses ponteiros deverão ser ágeis ou devem ser armazenados na tabela de interface comum (GIT) COM. Se você não puder recompilar um componente de encadeamento Ambos para agregar FTM, poderá marcar o componente com ThreadingModel=Neutral. Como alternativa, se você não quiser que o IIS execute verificações de agilidade (portanto, você pode permitir que componentes não ágeis sejam armazenados no escopo do Aplicativo ou da Sessão), poderá definir AspTrackThreadingModel como True na metabase. Alterar AspTrackThreadingModel não é recomendado.
O IIS 5.0 gerará um erro se você quiser armazenar um componente não ágil criado com Server.CreateObject em um objeto Application. Você pode evitar esse erro usando <object runat=server scope=application ...> em Global.asa, mas isso não é recomendado, pois pode levar ao pooling e à serialização, descritos abaixo.
O que acontece se você armazenar em cache componentes não ágeis? Componentes não ágeis armazenados em cache no objeto Session bloqueiam a Session no thread de trabalho ASP. ASP mantém um conjunto de threads de trabalho para lidar com solicitações. Normalmente, uma nova solicitação é sempre tratada pelo primeiro thread de trabalho disponível. Se a sessão estiver bloqueada para um thread, a solicitação deverá aguardar até que seu thread associado esteja disponível. Aqui está uma analogia que pode ajudar: você vai a um supermercado, escolhe alguns itens e paga no caixa #_3. A partir daí, sempre que você pagar por um item naquele supermercado, terá sempre que pagar no caixa #_3, mesmo que haja menos ou nenhuma fila nos outros caixas.
Armazenar componentes não ágeis no escopo do Aplicativo tem um impacto ainda pior no desempenho. O ASP deve criar um thread especial para executar componentes não ágeis armazenados no escopo do Aplicativo. Isso tem duas consequências: todas as chamadas devem ser canalizadas para esse thread e todas as chamadas são enfileiradas. "Pooling" significa que os parâmetros devem ser armazenados em uma área compartilhada de memória; realizar uma troca de contexto cara para um thread especial; ao tópico original. "Serialização" significa que apenas um método é executado por vez. Dois threads de trabalho ASP diferentes não podem executar vários métodos em um componente compartilhado simultaneamente. Isso elimina a simultaneidade, especialmente em computadores com vários processadores. Para piorar a situação, todos os componentes que não são do escopo do Aplicativo Ágil compartilham um único thread (o host STA), portanto, o impacto da serialização é ainda mais significativo.
O que posso fazer? Aqui estão algumas regras gerais. Se você gravar objetos usando Visual Basic (6.0) ou anterior, não os armazene em cache em objetos Aplicativo ou Sessão. Se você não conhece o modelo de threading de um objeto, não o armazene em cache. Não armazene em cache objetos não ágeis; em vez disso, crie-os e libere-os em cada página. Os objetos são executados diretamente no thread de trabalho ASP, portanto não há pooling ou serialização. Se os objetos COM estiverem em execução em um servidor IIS, o desempenho será aceitável se eles não demorarem muito para inicializar e excluir. Observe que objetos de thread único não devem ser usados dessa maneira. Tenha cuidado - o VB pode criar objetos de thread único! Se você precisar usar um objeto de thread único (como uma planilha do Microsoft Excel) como este, não espere alto rendimento.
Quando o ADO é marcado como de thread livre, os conjuntos de registros ADO podem ser armazenados em cache com segurança. Para marcar o ADO como free-threaded, use o arquivo Makfre15.bat, que geralmente está localizado no diretório \Program FilesCommonSystemADO.
Aviso Se você usar o Microsoft Access como banco de dados, não deverá marcar o ADO como thread livre. O conjunto de registros ADO também deve ser desconectado. Em geral, se você não controla a configuração do ADO em seu site (por exemplo, você é um fornecedor independente de software [ISV] que vende aplicativos da Web para clientes que gerenciam suas próprias configurações), é melhor não armazenar conjuntos de registros em cache.
Os componentes do dicionário também são objetos ágeis. LookupTable carrega seus dados de um arquivo de dados e pode ser usado para dados de caixa de combinação e informações de configuração. O objeto PageCache em Duwamish Books fornece sintaxe de dicionário, assim como o Caprock Dictionary. Esses objetos ou seus objetos derivados podem formar a base de uma estratégia de cache eficaz. Observe que os objetos Scripting.Dictionary não são ágeis e não devem ser armazenados em escopos Application ou Session.
Dica 5: Não armazene em cache conexões de banco de dados no objeto Aplicativo ou Sessão
. Armazenar em cache conexões ADO geralmente é uma estratégia ruim. Se um objeto Connection for armazenado no objeto Application e usado em todas as páginas, todas as páginas competirão por esta conexão. Se o objeto Connection estiver armazenado no objeto Sessão ASP, será criada uma conexão de banco de dados para cada usuário. Isso anulará as vantagens do pool de conexões e colocará pressão desnecessária no servidor Web e no banco de dados.
Em vez de armazenar em cache conexões de banco de dados, você pode criar e excluir objetos ADO em cada página ASP que usa ADO. Isso é eficiente porque o IIS possui um pool de conexões de banco de dados integrado. Para ser mais preciso, o IIS ativa automaticamente o pool de conexões OLEDB e ODBC. Isso garante que as conexões criadas e excluídas em todas as páginas serão válidas.
Como o conjunto de registros conectado armazena uma referência à conexão do banco de dados, você não deve armazenar em cache o conjunto de registros conectado no objeto Aplicativo ou Sessão. No entanto, você pode armazenar em cache conjuntos de registros desconectados que não contêm uma referência à sua conexão de dados. Para desconectar um conjunto de registros, execute as duas etapas a seguir:
Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient 'step 1
' Preencher o conjunto de registros com dados
rs.Open strQuery, strProv
'Agora desconecte o conjunto de registros do provedor de dados e da fonte de dados
rs.ActiveConnection = Nada 'etapa 2
Informações mais detalhadas sobre o pool de conexões podem ser encontradas no material de referência do ADO e do SQL Server.
Dica 6: Use objetos de sessão corretamente
Agora que discutimos as vantagens do armazenamento em cache em aplicativos e sessões, vamos discutir como evitar o uso de objetos de sessão. Conforme discutido abaixo, Session tem diversas desvantagens quando usado em sites movimentados. "Ocupado" geralmente significa um site que requer centenas de páginas por segundo ou milhares de usuários simultâneos. Essa dica é ainda mais importante para sites que precisam ser dimensionados horizontalmente, ou seja, aqueles que utilizam vários servidores para lidar com a carga ou obter tolerância a falhas. Para sites menores, como sites de intranet, se você quiser aproveitar os benefícios trazidos pela Sessão, a sobrecarga do sistema aumentará inevitavelmente.
Resumindo, o ASP cria automaticamente uma Sessão para cada usuário que acessa o servidor Web. Cada Sessão requer cerca de 10 KB de sobrecarga de memória (o principal é que os dados sejam armazenados na Sessão), o que retarda todas as solicitações. A Sessão permanece válida até que o período de tempo limite configurado (geralmente 20 minutos) decorra.
O maior problema do Session não é o desempenho, mas a escalabilidade. A sessão não pode abranger vários servidores Web. Depois que uma sessão é criada em um servidor, seus dados permanecem lá. Isso significa que se você usar a Sessão em um farm de servidores Web, deverá criar uma política que sempre envie cada solicitação do usuário ao servidor onde a Sessão do usuário está localizada. Isso é chamado de “colar” o usuário ao servidor Web. O termo "sessão fixa" é derivado disso. Se o servidor Web falhar, os usuários "travados" perderão o estado da sessão porque a sessão não está presa ao disco.
As estratégias para alcançar sessões fixas incluem soluções de hardware e software. Soluções como o Network Load Balancing no Windows 2000 Advanced Server e o Cisco's Local Director podem implementar sessões fixas às custas de algum grau de escalabilidade. Essas soluções são imperfeitas. Não é recomendado implantar sua própria solução de software neste momento (costumávamos usar filtros ISAPI e transformações de URL, etc.).
Os objetos Aplicativo também não abrangem vários servidores; se você precisar compartilhar e atualizar dados de Aplicativo em um farm de servidores Web, deverá usar um banco de dados back-end. No entanto, os dados do aplicativo somente leitura ainda são úteis em um farm de servidores Web.
A maioria dos sites de missão crítica exige pelo menos dois servidores Web, apenas para aumentar o tempo de atividade (para lidar com failover e manutenção do servidor). Portanto, ao projetar aplicativos de missão crítica, você deve implementar "sessões fixas" ou simplesmente evitar o uso de sessões e qualquer outra tecnologia de gerenciamento de estado que armazene o estado do usuário em um único servidor Web.
Se você não estiver usando sessões, feche-as. Você pode fazer isso para um aplicativo através do Internet Services Manager (consulte a documentação do ISM). Se você decidir usar sessões, há maneiras de mitigar o impacto delas no desempenho.
Você pode mover conteúdo que não requer uma Sessão (como telas de ajuda, áreas de visitantes, etc.) para outro aplicativo ASP que tenha a Sessão fechada. Você pode avisar o ASP página por página que não precisa mais do objeto Session nessa página, usando a seguinte diretiva na parte superior da página ASP:
<% @EnableSessionState=False %>
Um bom motivo para usar isso diretiva é que essas sessões têm um problema interessante com conjuntos de quadros. O ASP garante que apenas uma solicitação seja executada na Sessão por vez. Isso garante que, se o navegador solicitar diversas páginas para um usuário, apenas uma solicitação ASP tocará a Sessão por vez, evitando assim problemas de multithreading que ocorrem ao acessar o objeto Session. Infelizmente, todas as páginas de um conjunto de quadros serão exibidas em série, uma após a outra, em vez de simultaneamente. Os usuários podem ter que esperar muito tempo para ver todos os frames. Moral da história: se algumas páginas do conjunto de quadros não dependem de Session, certifique-se de informar o ASP usando a diretiva @EnableSessionState=False.
Há muitas maneiras de gerenciar o estado da Sessão que podem substituir o uso de objetos de Sessão. Para pequenas quantidades de estado (menos de 4 KB), geralmente recomendamos o uso de Cookies, variáveis QueryString e variáveis implícitas. Para volumes de dados maiores, como carrinhos de compras, um banco de dados back-end é a escolha mais adequada. Muito tem sido escrito sobre técnicas de gerenciamento de estado em farms de servidores Web. Para obter mais informações, consulte Referência de status da sessão.
Dica 7: Encapsule código em objetos COM
Se você tiver muito VBScript ou JScript, muitas vezes poderá melhorar o desempenho movendo seu código para objetos COM compilados. O código compilado geralmente é executado mais rápido que o código interpretado. Objetos COM compilados podem acessar outros objetos COM por meio de "ligação antecipada", que é um método mais eficiente de chamar objetos COM do que "ligação tardia" usada por scripts.
Encapsular código em objetos COM tem diversas vantagens (além do desempenho):
Os objetos COM ajudam a separar a lógica de apresentação da lógica de negócios.
Objetos COM garantem a reutilização de código.
Muitos desenvolvedores acham que o código escrito em VB, C++ ou Visual J++ é mais fácil de depurar do que ASP.
Os objetos COM também apresentam desvantagens, incluindo o tempo de desenvolvimento inicial e a necessidade de diferentes habilidades de programação. Observe que o encapsulamento de uma pequena quantidade de ASP pode causar degradação do desempenho sem melhorar o desempenho. Essa situação geralmente ocorre quando uma pequena quantidade de código ASP é encapsulada em um objeto COM. Nesse caso, a sobrecarga de criação e chamada do objeto COM supera as vantagens do código compilado. Tentativa e erro devem ser usados para determinar qual combinação de script ASP e código de objeto COM produz o melhor desempenho. Observe que há melhorias significativas nos scripts e no desempenho do ADO no Windows 2000/IIS 5.0 em comparação com o Microsoft Windows NT® Portanto, com a introdução do IIS 5.0, a vantagem de desempenho do código compilado em relação ao código ASP diminuiu.
Para obter uma discussão detalhada sobre as vantagens e desvantagens de usar COM em ASP, consulte Diretrizes de componentes ASP e programação de aplicativos distribuídos com Microsoft Visual Basic 6.0. Se você implantar componentes COM, será especialmente importante testá-los sob carga. Na verdade, todos os aplicativos ASP devem ser testados em carga normalmente.
Dica 8: Obtenha recursos mais tarde e libere-os mais cedo.
Aqui está uma pequena dica para sua referência. De modo geral, é melhor obter recursos mais tarde e liberá-los mais cedo. Isso se aplica a objetos COM, bem como a identificadores de arquivos e outros recursos.
Este método de otimização é usado principalmente para conexões e conjuntos de registros ADO. Quando você terminar com um conjunto de registros, digamos, depois de exibir uma tabela e seus dados, você deverá liberá-lo imediatamente, em vez de esperar até o final da página. É uma prática recomendada definir a variável VBScript como Nothing. Não deixe um conjunto de registros sair do escopo. Além disso, libere quaisquer objetos Command ou Connection relacionados (não se esqueça de chamar Close() antes de definir o conjunto de registros ou a conexão como = Nothing). Isso reduz o tempo que o banco de dados tem para preparar recursos para você e libera a conexão do banco de dados para o pool de conexões o mais rápido possível.
Dica 9: A execução fora do processo troca desempenho por confiabilidade
Tanto o ASP quanto o MTS/COM+ possuem opções de configuração que permitem negociar confiabilidade com desempenho. Ao criar e implementar aplicativos, você deve saber como equilibrar o desempenho com ambos.
As opções ASP configuram aplicativos ASP para serem executados de três maneiras. No IIS 5.0, o termo “nível de isolamento” foi introduzido para descrever essas opções. Os três níveis de isolamento são baixo nível, médio nível e alto nível:
isolamento de baixo nível. Isto é suportado em todas as versões do IIS e é o mais rápido. Ele executa ASP em Inetinfo.exe, que é o principal processo do IIS. Se o aplicativo ASP falhar, o IIS também falhará. (Para reiniciar o IIS no IIS 4.0, o administrador do site deve monitorar o site usando uma ferramenta como o InetMon e ativar um arquivo em lote para reiniciar o servidor se o servidor falhar. O IIS 5.0 introduziu reinicialização confiável, método para reiniciar automaticamente um servidor com falha. ).
Isolamento intermediário. O IIS 5.0 introduziu esse novo nível, chamado de nível fora de processo porque o ASP é executado fora do processo do IIS. No isolamento intermediário, todos os aplicativos ASP configurados para execução como isolamento intermediário compartilham um espaço de processo. Isto reduz o número de processos necessários para executar vários aplicativos ASP fora de processo em um único servidor. O isolamento médio é o nível de isolamento padrão no IIS 5.0.
Isolamento avançado. Este nível é suportado no IIS 4.0 e IIS 5.0, e o isolamento avançado também está fora do processo. Se o ASP falhar, o servidor Web não falhará. O aplicativo ASP será reiniciado automaticamente na próxima vez que uma solicitação ASP for feita. No isolamento avançado, cada aplicativo ASP configurado para ser executado como isolamento avançado é executado em seu próprio espaço de processo. Isso protege os aplicativos ASP de interferirem uns nos outros. A desvantagem é que requer um processo separado para cada aplicativo ASP. Quando muitos aplicativos devem ser executados em um único servidor, a sobrecarga do sistema aumenta significativamente.
Qual opção é a melhor? No IIS 4.0, ficar sem processo reduzirá significativamente o desempenho. No IIS 5.0, muitas melhorias foram feitas para minimizar a sobrecarga causada pela execução de aplicativos ASP fora do processo. Na verdade, na grande maioria dos testes, os aplicativos ASP fora de processo no IIS 5.0 foram executados mais rapidamente do que os aplicativos em processo no IIS 4.0. Independentemente disso, em ambas as plataformas, o desempenho em processo (baixo nível de isolamento) é melhor. Contudo, se a taxa de acesso for relativamente baixa ou o rendimento máximo for baixo, as vantagens de um nível de isolamento baixo são menos óbvias. Portanto, definir um nível de isolamento baixo só poderá ser necessário se você precisar de centenas ou milhares de páginas por segundo por servidor Web. Como sempre, teste múltiplas configurações para determinar qual compromisso você deseja fazer.
Observe que quando você executa aplicativos ASP fora de processo (isolamento médio ou alto), eles são executados em MTS no NT4 e em COM+ no Windows 2000. Ou seja, no NT4 eles rodam em Mtx.exe; no Windows 2000, eles rodam em DllHost.exe; Você pode ver esses processos em execução no Gerenciador de Tarefas. Você também pode ver como o IIS configura um pacote MTS ou aplicativo COM+ para um aplicativo ASP fora de processo.
Opções COM Os componentes COM também possuem três opções de configuração, embora não sejam exatamente semelhantes às opções ASP. Os componentes COM podem ser "desconfigurados", configurados como um aplicativo de biblioteca ou configurados como um aplicativo de servidor. "Desconfigurado" significa que o componente não está registrado no COM+. Os componentes serão executados no espaço de processo do programa chamador, ou seja, estão "em processo". Os aplicativos de biblioteca também estão em processo, mas usam serviços COM+, incluindo segurança, transações e suporte de contexto. Os aplicativos de servidor são configurados para serem executados em seu próprio espaço de processo.
Você pode ver que os componentes não configurados têm pequenas vantagens sobre os aplicativos de biblioteca. Os aplicativos de biblioteca têm maiores vantagens de desempenho do que os aplicativos de servidor. Isso ocorre porque os aplicativos de biblioteca são executados no mesmo processo que o ASP, enquanto os aplicativos de servidor são executados em seus próprios processos. As chamadas entre processos são mais caras que as chamadas entre processos. Além disso, ao passar dados como conjuntos de registros entre processos, todos os dados devem ser copiados entre os dois processos.
armadilha! Ao usar um aplicativo de servidor COM, se você passar objetos entre ASP e COM, certifique-se de que os objetos executem "pacote por valor" ou MBV. Objetos que executam MBV se copiam de um processo para outro. Isso é melhor do que uma abordagem em que o objeto ainda está no processo do criador e outro processo chama o processo de criação repetidamente para usar o objeto. Um conjunto de registros ADO desconectado será "agrupado por valor", um conjunto de registros conectado não. Scripting.Dictionary não executa MBV e não é passado entre processos. Finalmente, uma observação aos programadores de VB: MBV não é obtido passando o parâmetro ByVal. MBV é executado pelo autor do componente original.
o que fazer?
Se nos pedissem para sugerir uma configuração razoável que equilibrasse desempenho e confiabilidade, elas seriam as seguintes:
No IIS 4.0, use o nível de isolamento baixo do ASP e use o pacote do servidor MTS.
No IIS 5.0, use o nível de isolamento médio do ASP e use um aplicativo de biblioteca COM+.
Esses são princípios muito gerais; as empresas de hospedagem normalmente executam ASP em níveis de isolamento médio ou alto, enquanto servidores Web de propósito único podem operar em níveis de isolamento baixos. Pese os prós e os contras e decida por si mesmo qual configuração atende melhor às suas necessidades.
Dica 10: Use
a opção explícita explícita de opções explícitas em arquivos .asp. Esta diretiva é colocada na parte superior do arquivo .asp e força o desenvolvedor a declarar todas as variáveis a serem usadas. Muitos programadores acham esse método útil na depuração de aplicativos, pois evita a possibilidade de elogiar nomes de variáveis e criar acidentalmente novas variáveis (por exemplo, myxmlstring =) em vez de myxlmstring = ....
Talvez o mais importante, as variáveis declaradas são mais rápidas que as variáveis não declaradas. Dessa forma, toda vez que o script usa uma variável não declarada em tempo de execução, ele o faz referência por nome. Por outro lado, as variáveis são declaradas em ordem, no tempo de compilação ou no tempo de execução. A partir de agora, as variáveis declaradas são referenciadas nesta ordem. Como a opção Força Explícita Declaração Variável, garante que todas as variáveis sejam declaradas, portanto, o acesso é rápido.
Dica 11: Use variáveis locais em sub -rotinas e funções
variáveis locais são aquelas variáveis declaradas nas sub -rotinas e funções. Dentro de uma função ou sub -rotina, o acesso variável local é mais rápido que o acesso global da variável. O uso de variáveis locais também tornará o código mais claro, para que as variáveis locais sejam usadas sempre que possível.
Dica 12: Copie os dados usados com frequência nas variáveis de script
ao acessar objetos COM no ASP, os dados de objeto usados com frequência devem ser copiados em variáveis de script. Fazer isso reduz as chamadas do método COM, que são relativamente caras em comparação com o acesso às variáveis de script. Essa técnica também reduz as pesquisas caras ao acessar objetos de coleção e dicionário.
Em geral, se você planeja acessar os dados do objeto mais de uma vez, coloque os dados nas variáveis de script. O principal alvo dessa otimização são as variáveis de solicitação (Variáveis de formulário e WERYString). Por exemplo, seu site pode passar uma variável de consulta chamada UserID. Digamos que este UserID seja referenciado 12 vezes em uma página específica. Em vez de chamar a solicitação de chamada (? UserID?) 12 vezes, você pode atribuir o UserID a uma variável na parte superior da página ASP. Em seguida, use essa variável ao longo da página. Isso salva 11 chamadas de método COM.
De fato, o acesso a propriedades ou métodos da COM não é tão caro. Aqui está um exemplo de algum código bastante comum (sintaticamente falando):
foo.bar.blah.baz = foo.bar.blah.qaz (1)
Se foo.bar.blah.zaq = foo.bar.blah.abc então '...
Quando esse código é executado, eis o que acontece:
a variável Foo é resolvida para um objeto global.
A barra variável é resolvida como um membro do Foo. Na verdade, esta é uma chamada de método COM.
A variável blá é resolvida como um membro do Foo.Bar. Esta é outra chamada de método COM.
A variável QAZ é resolvida como um membro do foo.bar.blah. É isso mesmo, esta ainda é uma chamada de método COM.
Ligue para Foo.bar.blah.quaz (1). Outra chamada de método COM. Entendi?
Execute as etapas 1 a 3 novamente para analisar Baz. O sistema não sabe se a chamada de QAZ altera o modelo de objeto; portanto, as etapas 1 a 3 devem ser executadas novamente para resolver o BAZ.
Resolva Baz como membro do foo.bar.blah. Atribuir atributos.
Execute as etapas 1 a 3 novamente para analisar o ZAQ.
Execute as etapas 1 a 3 novamente para analisar ABC.
Como você pode ver, a eficiência é bastante ruim (e lenta). Uma maneira rápida de escrever este código no VBScript é:
set myobj = foo.bar.blah 'faça a resolução do blá uma vez
Myobj.baz = myobj.qaz (1)
Se myobj.zaq = myobj.abc então '...
Se você estiver usando o VBScript 5.0 ou superior, pode escrever este código usando a declaração com com:
com foo.bar.blah
.baz = .qaz (1)
Se .zaq = .abc então '...
...
Termine com
nota que esta técnica também se aplica à programação VB.
Dica 13: Evite re-dimensionar as
matrizes Redim devem ser evitadas, se possível. Em termos de desempenho, se o computador tiver tamanho limitado de memória física, é melhor definir a dimensionalidade inicial da matriz como seu pior cenário-ou definir as dimensões em seu melhor cenário e depois re-dimensionar conforme necessário. Isso não significa apenas alocar alguns megabytes de memória quando você sabe que não precisará.
O código a seguir mostra o uso inadequado de DIM e REDIM.
<%
Dimmyarray ()
Redimmyarray (2)
Myarray (0) =? Olá?
MyArray (1) =? Adeus?
MyArray (2) =? Adeus?
...
'Algum outro código em que você acaba precisando de mais espaço acontece, então ...
Redim Preserve Myarray (5)
MyArray (3) =? Mais coisas?
MyArray (4) =? Ainda mais coisas?
MyArray (5) =? Ainda mais coisas?
%>
É muito melhor diminuir o tamanho inicial da matriz corretamente desde o início (neste caso, 5) do que redim a matriz para torná -la maior. Você pode desperdiçar alguma memória (se não usar todos os elementos), mas o benefício é que ela se torna mais rápida.
Dica 14: Use o buffer de resposta
Você pode buffer uma página inteira de saída, permitindo "buffer de resposta". Isso minimiza a quantidade de escrita no navegador, melhorando o desempenho geral. Cada operação de gravação incorre na sobrecarga significativa (tanto no IIS quanto em termos da quantidade de dados enviados pela rede), para que menos grava, melhor. Devido à sua inicialização lenta e ao uso do algoritmo Nagling (usado para aliviar o congestionamento da rede), o TCP/IP é muito mais eficiente ao enviar alguns pedaços grandes de dados do que quando deve enviar muitos pequenos pedaços.
Existem duas maneiras de ativar o buffer de resposta. Primeiro, você pode usar o Internet Services Manager para ativar o buffer de resposta para todo o aplicativo. Recomendamos essa abordagem, permitindo o buffer de resposta por padrão para novos aplicativos ASP no IIS 4.0 e IIS 5.0. Segundo, você pode ativar o buffer de resposta adicionando a seguinte linha de código perto da parte superior de cada página asp:
< % Response.buffer = true %>
Essa linha de código deve ser executada antes que qualquer dados de resposta seja gravado no navegador (ou seja, antes de qualquer HTML aparecer no script ASP e antes que qualquer cookies seja definido usando a coleção Response.cookies). Em geral, é melhor ativar o buffer de resposta para todo o aplicativo. Dessa forma, você não precisa escrever a linha de código acima na parte superior de todas as páginas.
Resposta.Flush
Uma reclamação comum sobre o buffer de resposta é que os usuários percebem que as páginas do ASP demoram a responder (mesmo que o tempo geral de resposta seja melhorado) porque precisam esperar até que a página inteira seja gerada antes que possam ver qualquer coisa. Para páginas de longa duração, você pode definir a resposta.Buffer = false para desativar o buffer de resposta. No entanto, uma estratégia melhor é utilizar o método de resposta. Este método envia todo o HTML convertido por ASP para o navegador. Por exemplo, depois de converter as primeiras 100 linhas de uma tabela de 1.000 linhas, o ASP pode chamar a resposta.Flush para forçar os resultados da conversão para o navegador, permitindo que o usuário veja as primeiras 100 linhas antes que as linhas restantes estejam prontas. Essa técnica combina perfeitamente o buffer de resposta com o navegador que exibe gradualmente dados.
(Observe que, no exemplo da tabela de 1.000 filas acima, muitos navegadores não começarão a exibir a tabela até que vejam a tag de fechamento. Menos linhas e resposta de chamada.Flush após cada tabela. A largura do conteúdo de cada célula.)
Outra reclamação comum sobre o buffer de resposta é que ele ocupa muita memória do servidor quando as páginas muito grandes são produzidas. Independentemente do método de geração de páginas grandes, esse problema também pode ser resolvido através do uso inteligente de resposta.
Dica 15: scripts incorporados em lote e resposta
. Se o buffer de resposta não estiver ativado, cada instrução executada gravará dados no navegador em muitos pacotes pequenos sobre a rede. Isso é muito lento. Além disso, a execução intercalada de uma pequena quantidade de scripts e HTML causará a alternância entre o mecanismo de script e o HTML, reduzindo assim o desempenho. Portanto, use o seguinte truque: use a resposta. Escrava chamadas em vez de expressões em linha fortemente incluídas. Por exemplo, no exemplo a seguir, há uma gravação no fluxo de resposta por campo por linha, e há muitos interruptores entre o VBScript e o HTML por linha:
<table>
< % Para cada FLD em rs.fields %>
<th> < % = fld.name %> </th>
<%
Próximo
Embora não seja Rs.eof
%>
<tr>
< % Para cada FLD em rs.fields %>
<Td> < % = fld.value %> </td>
<% A seguir
</tr>
<% rs.movenext
Wend %>
</tabela>
O código abaixo é mais eficiente, com uma gravação no fluxo de resposta por linha. Todo o código está contido em um bloco VBScript:
<table>
<%
Para cada FLD em Rs.fields
Response.write (? <th>? & Fld.name &? </th>? & Vbcrlf)
Próximo
Embora não seja Rs.eof
Response.write (? <tr>?)
Para cada FLD em Rs.Fields %>
Response.write (? <td>? & Fld.value &? </td>? & Vbcrlf)
Próximo
Response.Write? </tr>?
Wend
%>
</tabela>
Esse truque funciona especialmente bem quando o buffer de resposta é desativado. É uma boa ideia habilitar o buffer de resposta e ver se a resposta em lote. A redação ajuda a melhorar o desempenho.
(Neste exemplo em particular, o loop aninhado que constrói o corpo da tabela (enquanto não é Rs.eof ...) pode ser substituído por uma chamada de getas cuidadosamente construídas.)
Dica 16: Se a página levar muito tempo para concluir, Se os usuários forem impacientes antes de usar o Respons.IclientConnected
, eles poderão abandonar a página ASP antes de começar a executar a solicitação deles. Se eles clicarem em atualizar ou passar para outra página do servidor, há uma nova solicitação esperando no final da fila de solicitação ASP e uma solicitação desconectada no meio da fila. Isso geralmente acontece quando a carga no servidor é alta (e, portanto, a fila de solicitação é longa e os tempos de resposta são correspondentemente longos), o que só piora a situação. Não faz sentido executar páginas ASP (especialmente páginas ASP grandes lentas) se o usuário não estiver mais conectado. Você pode verificar isso usando a propriedade Response.IssclientConnected. Se retornar false, a resposta.END deve ser chamada e o restante da página deve ser descartado. De fato, o IIS 5.0 possui esse comportamento programado - toda vez que o ASP está prestes a executar uma nova solicitação, ele verifica quanto tempo a solicitação está esperando na fila. Se estiver esperando lá por mais de 3 segundos, o ASP verificará se o cliente ainda está conectado e, se não, encerrará a solicitação imediatamente. Você pode ajustar o tempo limite de 3 segundos para outro valor usando a configuração ASPQueConnectionTesttime na metabase.
Você também pode verificar a resposta. Quando o buffer de resposta é ativado, é uma boa ideia executar a resposta.FLUSH De tempos em tempos para que o usuário saiba o que está acontecendo.
Observe que no IIS 4.0, Response.SclientConnected não funcionará corretamente, a menos que a resposta.Write seja executada primeiro. Se o buffer estiver ativado, você também deve executar a resposta.flush. No IIS 5.0, não há necessidade de fazer isso - Response.ClientConnected funciona bem. De qualquer forma, o Response.ClientConnected terá alguma sobrecarga; portanto, apenas se uma operação tomar pelo menos (digamos) 500 milissegundos (muito tempo se você quiser manter uma taxa de transferência de dezenas de páginas por segundo), basta usá -lo. A experiência mostra que você não deve chamá -lo toda vez que um loop apertado é executado repetidamente, como ao exibir muitas linhas de uma tabela - chamando -a a cada vinte ou cinquenta linhas podem ser apropriadas.
Dica 17: Use a tag <ject> para objetos instanciados,
se desejar fazer referência a um objeto que não é usado em todos os caminhos de código (especialmente objetos escassos ao servidor ou aplicativos), use o <Object Runat = ID do servidor = objName> tag declaração em global.asa eles em vez de usar o método Server.CreateObject. Server.CreateObject cria objetos imediatamente. Se você não usar o objeto no futuro, você desperdiçou recursos. A tag <object id = objName> declara objName, mas o objName não é criado até que seu método ou propriedade seja usado pela primeira vez.
Este é outro exemplo de avaliação preguiçosa.
Dica 18: Use declarações de typelib para ADO e outros componentes
ao usar o ADO, os desenvolvedores geralmente adicionam Adovbs.txt para acessar várias constantes ADO. Este arquivo deve ser incluído em todas as páginas em que as constantes devem ser usadas. Esse arquivo constante é bastante grande, adicionando muita sobrecarga ao tempo de compilação e tamanho do script de cada página do ASP.
O IIS 5.0 introduziu a capacidade de se ligar às bibliotecas do tipo componente. Isso permite que você faça referência à biblioteca de tipos uma vez e use -a em cada página do ASP. Não há despesas gerais de compilação de arquivos constantes para cada página, e os desenvolvedores de componentes não precisam criar arquivos VBScript#_include para uso no ASP.
Para acessar o ADO TypeLib, coloque a seguinte declaração em global.asa.
<!- Nome dos metadados =? Microsoft ActiveX Data Objects 2.5 Library?
TIPO =? TypeLib?
ou
<!- Tipo de metadados =? TypeLib?
FILE=?C:Program FilesCommon Filessystemadomsado15.dll? -->
Tip 19: Use the browser's verification function
Today's browsers do not support some advanced functions such as XML, DHTML, Java applets and remote Data Serviços fornecem suporte. Use esses recursos sempre que possível. Todas essas tecnologias executam a validação do cliente e o cache de dados, eliminando a necessidade de uma viagem de ida e volta ao servidor da Web. Se você estiver executando um navegador inteligente, o navegador poderá fazer alguma validação para você (por exemplo, verificando se uma soma de verificação de cartão de crédito é válida antes de executar uma postagem). Use esse recurso sempre que possível. Ao reduzir as viagens de volta ao cliente-servidor, você reduz a carga no servidor da Web e reduz o tráfego de rede (embora a primeira página enviada ao navegador possa ser maior) e quaisquer recursos de back-end acessados pelo servidor. Além disso, o usuário não precisa ler uma nova página como de costume, para que o usuário se sinta melhor. Fazer isso não significa que você pode pular a validação do lado do servidor-você sempre deve fazer a validação do lado do servidor. Isso impede que o cliente gerem dados incorretos por algum motivo (como um hacker ou o navegador que não executa rotinas de validação do lado do cliente).
Muito trabalho foi realizado no desenvolvimento de HTML "independente do navegador". Devido a essa preocupação, os desenvolvedores relutam em usar recursos populares do navegador que podem melhorar o desempenho. Para alguns sites verdadeiramente de alto desempenho, os problemas de "acesso" do navegador devem estar preocupados, e uma boa estratégia é otimizar a página para adaptá-la aos navegadores populares. Os recursos do navegador podem ser facilmente detectados no ASP usando o componente Recursos do navegador. Ferramentas como o Microsoft FrontPage Ajuda Código de design apropriado para o navegador e a versão específica do HTML. Veja quando é melhor pior? Pesando as trocas de tecnologia para discussões adicionais.
Dica 20: Evite usar concatenação de string em um loop
que muitas pessoas criam uma string em um loop, como este:
s =? <Tabela>?
Para cada FLD em Rs.fields
s = s &?
Em seguida,
embora não seja Rs.eof
s = s & vbcrlf &?
Para cada FLD em Rs.fields
s = s &?
Próximo
s = s &?
rs.MoveNext
Wend
s = s & vbcrlf &? </ tabela>?
Response.write s
Alguns problemas surgem com essa abordagem. O primeiro problema é que as cordas concatenas repetidamente levam tempo ao poder de dois. Um exemplo mais simples ilustrará esse problema com mais clareza.
s = ??
Para i = ASC (? A?) ASC (? Z?)
s = s & ch (i)
Próximo
Na primeira iteração, você recebe uma corda de um caractere? A?. Na segunda iteração, o VBScript deve realocar a string e copiar dois caracteres (? AB?) Para s. Na terceira iteração, ele também deve realocar S novamente e copiar três caracteres em s. Em n (26) iterações, ele deve realocar e copiar os caracteres n para s. O total é 1+2+3+...+n, ou seja, n*(n+1)/2 cópias.
No exemplo do registro acima, se houver 100 registros e 5 campos, o loop interno será executado 100*5 = 500 vezes, e o tempo gasto em toda a cópia e a realocação é proporcional a 500*500 = 250.000. São muitas operações de cópia para um conjunto de registros de tamanho moderado.
Nesse caso, o código pode ser aprimorado usando o Response.Write () ou o script embutido (< % = fld.Value %>) em vez da concatenação da String. Se o buffer de resposta estiver ativado (deve), isso será mais rápido porque a resposta.Write apenas anexa os dados ao final do buffer de resposta. Não há realocação envolvida, por isso é muito eficiente.
No caso específico de converter um conjunto de registros ADO em uma tabela HTML, considere usar o GetRows ou o GetString.
Se você está concatenando strings no JScript, é particularmente recomendável usar o operador +=, ou seja, use s +=? Uma string? Em vez de s = s +? Uma string?.
Dica 21: Ative o navegador e o cache de proxy
por padrão, o ASP desativa o cache em navegadores e proxies. Isso faz sentido porque as páginas do ASP são, por natureza, dinâmica, com informações subjacentes que mudam ao longo do tempo. Se a página não exigir uma atualização em todas as visualizações, você deve ativar o navegador e o cache de proxy. Isso permite que os navegadores e proxies usem uma cópia "em cache" da página por um certo período de tempo, cujo comprimento você pode controlar. O cache pode reduzir bastante a carga no servidor e reduzir o tempo de espera do usuário.
Qual página dinâmica pode ser usada como uma página para ser armazenada em cache? Aqui estão alguns exemplos:
página de previsão do tempo, nesta página, a previsão do tempo é atualizada a cada 5 minutos.
Página inicial Listando notícias ou lançamentos, atualizados duas vezes por dia.
Uma lista de desempenho do fundo mútuo, onde as estatísticas básicas são atualizadas a cada poucas horas.
Observe que quando o navegador ou o cache de proxy é usado, o número de visitas registradas no servidor da Web é reduzido. Se você deseja medir com precisão todas as visualizações ou postagens da página, não deseja usar o navegador e o cache de proxy.
O cache do navegador é controlado pelo cabeçalho HTTP "Expiration", que é enviado ao navegador pelo servidor da Web. O ASP fornece dois mecanismos simples para enviar este cabeçalho. Para definir o número de minutos após o qual uma página expirará, defina a propriedade Response.Expires. O exemplo a seguir informa ao navegador que o conteúdo expira em 10 minutos:
< % Response.expires = 10 %>
Configuração de resposta.expire para um número negativo ou 0 desativa o cache. Certifique -se de usar um grande número negativo, como -1000 (pouco mais de um dia) para evitar uma incompatibilidade entre os relógios do servidor e do navegador. A segunda propriedade, Response.Expiresabsolute, permitirá definir o tempo específico em que o conteúdo expirar:
< % Response.expiresabsolute = #May 31.2001 13: 30: 15 # %>
Em vez de usar o objeto de resposta para definir o tempo de expiração, você pode escrever a tag <mEta> na seção HTML, geralmente na seção <ad Head> do arquivo HTML. Alguns navegadores respeitarão essa diretiva, enquanto os proxies não o farão.
<Meta http-equiv =? Expira?
Por fim, você pode usar a propriedade Response.CacheControl para indicar se seu conteúdo pode ser armazenado em cache por um proxy HTTP. Definir essa propriedade como "pública" permite que o proxy cache esse conteúdo.
< % Response.cacheControl =? Public? %>
Por padrão, esta propriedade está definida como "privada". Observe que o cache de proxy não deve ser ativado para páginas que exibem dados específicos para um usuário, pois o proxy pode servir as páginas do usuário pertencentes a outros usuários.
Dica 22: Use o servidor.Transfer em vez de resposta.Redirect sempre que possível
. Esta função é comumente usada para redirecionar o usuário para uma página de login ou erro. Como o redirecionamento força uma solicitação de uma nova página, o resultado é que o navegador deve fazer duas viagens de ida e volta ao servidor da Web e o servidor da Web deve lidar com mais uma solicitação. O IIS 5.0 apresenta um novo servidor de funções.Transfer, que transfere a execução para outra página ASP no mesmo servidor. Isso evita o navegador redundante viagens-redondas do servidor, melhorando o desempenho geral do sistema e o tempo de resposta do usuário. Verifique a "nova direção" em "redirecionamento", deve ser servidor.Transfer e Server.Execute.
Consulte também Aproveitando o ASP no IIS 5.0 para obter uma lista completa de novos recursos no IIS 5.0 e ASP 3.0.
Dica 23: use uma barra de barragem nos URLs de diretório
Uma dica relacionada é garantir que você use uma barra de barragem (/) nos URLs que apontam para os diretórios. Se você omitir a barra à direita, o navegador fará uma solicitação ao servidor apenas para dizer ao servidor que está solicitando um diretório. O navegador faz uma segunda solicitação, anexando uma barra ao URL e só então o servidor pode responder com o documento padrão ou a lista de diretórios do diretório (se não houver que não houver um documento padrão e a navegação do diretório estiver ativada). Aprender a barra elimina o primeiro retorno inútil. Para facilitar a leitura dos usuários, a barra de referência no nome da exibição pode ser omitida.
Por exemplo, escreva:
<a href =? Http: //msdn.microsoft.com/workshop/? Title =? Msdn web
Workshop?> Http://msdn.microsoft.com/workshop </a>
Isso também se aplica aos URLs apontando para a página inicial em um site: use o seguinte: <a href =? Http: //msdn.microsoft.com/?> Em vez de <a href =? Http: //msdn.microsoft .
Dica 24: Evite usar variáveis de servidor
. A situação é semelhante a procurar um arquivo em uma pasta em um sótão de mofo. Quando você deseja encontrar esse documento, precisa ir ao sótão, encontrar a pasta e encontrar o documento. O mesmo acontece quando você solicita uma variável de servidor - na primeira vez que solicita uma variável de servidor, o desempenho sofre. Solicitações subsequentes a outras variáveis do servidor não terão impacto no desempenho.
Nunca acesse um objeto de solicitação não qualificado (por exemplo, solicitação ("dados")). Request.Servervariables é chamado implícito para itens que não estão em request.cookies, request.form, request.querystring ou request.clientCertificate. A coleção Request.Servervariables é muito mais lenta que outras coleções.
Dica 25: A atualização para os melhores e mais recentes
componentes do sistema é uma constante e recomendamos que você os atualize para as melhores e mais recentes configurações. É melhor atualizar para o Windows 2000 (e, portanto, IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 e JScript 5.1). Nos computadores multiprocessadores, a implementação do IIS 5.0 e o ADO 2.5 pode melhorar significativamente o desempenho. Sob o Windows 2000, asp escalam bem para quatro processadores ou mais, enquanto no IIS 4.0, o ASP não escala além de dois processadores. Quanto mais código de script e ADO usar em seu aplicativo, mais melhorias de desempenho você experimentará após a atualização para o Windows 2000.
Se você ainda não puder atualizar para o Windows 2000, poderá atualizar para as versões mais recentes do SQL Server, ADO, VBScript e JScript, MSXML, Internet Explorer e NT 4 Service Packs. Ambos melhoram o desempenho e a confiabilidade.
Dica 26: Otimize o servidor da Web
Existem vários parâmetros de otimização do IIS que podem melhorar o desempenho do site. Por exemplo, com o IIS 4.0, geralmente descobrimos que aumentar o parâmetro ASP ProcessorthReadMax (consulte a documentação do IIS) pode melhorar significativamente o desempenho, especialmente em sites que tendem a esperar por recursos de back-end (como bancos de dados) ou outros produtos intermediários (como como como pincéis de tela). No IIS 5.0, você pode achar que a ativação do bloqueio do encadeamento ASP é mais eficiente do que encontrar uma configuração ideal para aspprocessorthReadMax, que agora é bem conhecida.
Para uma boa referência, consulte otimizando o IIS abaixo.
As configurações ideais de configuração dependem, entre outros fatores, o código do aplicativo, o hardware do sistema em que está sendo executado e a carga de trabalho do cliente. A única maneira de encontrar as melhores configurações é realizar testes de desempenho, que discutiremos na próxima dica.
Dica 27: Realize testes de desempenho
Como dissemos antes, o desempenho é uma característica. Se você deseja melhorar o desempenho do seu site, defina uma meta de desempenho e melhore gradualmente até alcançá -lo. Não, nenhum teste de desempenho será realizado. Freqüentemente, até o final do projeto, é tarde demais para fazer as mudanças estruturais necessárias, e seu cliente ficará desapontado. Realize o teste de desempenho como parte da sua rotina de testes. Você pode executar testes de desempenho em componentes individuais individualmente, como páginas ASP ou objetos COM ou no site como um todo.
Muitas pessoas usam um único navegador para solicitar uma página para testar o desempenho de um site. Fazer isso dará a você a sensação de que seu site é responsivo, mas na verdade não informa como o seu site é executado sob carregamento.
Normalmente, para testar com precisão o desempenho, você precisa de um ambiente de teste dedicado. Esse ambiente deve incluir hardware semelhante ao ambiente de produção em termos de velocidade do processador, número de processadores, memória, discos, configuração de rede etc. Segundo, você deve especificar a carga de trabalho do cliente: quantos usuários simultâneos existem, com que frequência eles fazem solicitações, que tipos de páginas eles clicam etc. Se você não tiver dados sobre o uso real do site, deve estimar o uso. Por fim, você precisa de uma ferramenta que possa simular cargas de trabalho esperadas do cliente. Com essas ferramentas, você pode começar a responder perguntas como "Se eu tiver n usuários simultâneos, quantos servidores precisarão?" Você também pode identificar as causas dos gargalos e otimizar contra eles.
Listados abaixo estão algumas boas ferramentas de teste de carga da Web. Recomendamos particularmente o estresse do aplicativo da Web do Microsoft (WAS). Foi permitido gravar scripts de teste e simular centenas ou milhares de usuários acessando um servidor da web. Houve relatos de várias estatísticas, incluindo solicitações por segundo, distribuição de tempo de resposta e contagem de erros. O WAS está disponível em uma interface rica em cliente e em uma interface baseada na Web que permite realizar testes remotos.
Certifique -se de ler o IIS 5.0 Tuning Guide.
Dica 28: Ler links de recursos
abaixo são links para alguns ótimos recursos relacionados ao desempenho. Se você quiser aprender sobre isso, leia o desenvolvimento de aplicativos da Web escalonáveis.
Otimização de recursos ASP Scripts Desenvolvendo aplicativos da Web
escaláveis
Obteve
algum
cache
?
,Recursos de velocidade e otimização
de Nancy Winnick Clups
,otimizando o IIS
por Charles CarrollA arte e a ciência do servidor da web sintonizando com serviços de informação da Internet 5.0
Aproveitando asp no IIS 5.0,
ajustando IIS 4.0 para sites de alto volume por JD Meier, Tuning Information Information Desempenho do servidor de Michael Stephenson
,navegando no labirinto de configurações para otimização de desempenho do servidor da web
por Mike Moore
,gerenciando o Internet Information Server 4.0 para desempenho por Todd Wanke,
ADO e SQL Server
por Hans HugliTop Dips: Acessando SQL por meio de ADO
e ASP,Melhorando O desempenho do seu aplicativo MDAC por
JD Meier
,agrupando os componentes do Microsoft Data Access por Suresh Kannan,
SQL Server: Referências de desempenho e guias de
Leland Ahlbeck e Don Willits,melhorando o desempenho dos componentes de acesso a dados com o IIS 4.0,
componentes de acesso à Microsoft (componentes de acesso à Microsoft ( MDAC) e ADO (ActiveX Data Objects (ADO) Dicas de desempenho de Leland Ahlbeck,
Microsoft
SQL Server 7.0 Ajuste e otimização de desempenho prático - a perspectiva do servidor de Leland Ahlbeck,
Microsoft SQL Server 7.0 Ajuste e otimização de desempenho prático - A perspectiva do servidor por Damien Lindaer - o Perspectiva do aplicativo de Damien Lindauer
Accessando os registros da Internet por Dino Esposito
ASP
Diretrizes de JD MEIER
Q243548
: Informações: Diretrizes de design para componentes VB sob
modelos de Threading Aspexplicados por Nancy Winnick Clucs
So Happy Together
?Componentes do servidor ativo com ATL por
Nancy Winnick Clucs
, agilidade nos componentes do servidor de George Reilly,construindo componentes de alto desempenho com C ++ por
Neil Allain
,Páginas de servidor ativo e apartamentos de Jon Flanders, por Don Box,
House of Com: Páginas de servidor ativo, por Don Box,
House of Com: Contextos, por Don Box,
House of Com: Desempenho Comer Trade-offs do ambiente de execução de componentes do Windows 2000, por Don Box,
construindo componentes que aproveitam ao máximo o Visual Basic e Scripts , por Ivo Salmre
Component Design Princípios para
o componente de dicionário
MTSCriando um objeto de cache de página, de Robert Coleridge
abregando o objeto do dicionário: a equipe ASP cria um objeto de compra de pesquisa, por Robert Carter
Caprock Dictionary
Site Server Commerce Edition Inclui um componente de
dicionário
Q175167: como: valores persistentes sem sessões
q157906: como: como manter o estado nas páginas com comportamentos de persistência baseados em vbscript
xml consertam dores de cabeça dafazenda
da web por skonnard
house of com: programação apátrida por
desempenho
da caixaSites usando o desempenho do servidor Microsoft Windows DNA Platform
Server e assassinos de escalabilidade, do
centro de escalabilidade George Reilly Microsoft Visual Studio
Fitch & Mather Stocks 2000
Application o aplicativo FMSTOCKS Aplicativo
de alto desempenho Aplicativos Visual Basic, por Ken Spencer
Duwamish Books, Fase 4
Top Windows DNA de desempenho E como evitá-los por Gary Geiger e Jon Pulsipher
Building de HTML estático a fazendas na web de alto desempenho
da ferramenta de estresse de aplicativos da Web do Microsoft
de Shawn Bice, nãoposso
estressá-lo o suficiente-carregue seu aplicativo ASP, por JD Meier
Windows DNA
Eventos de monitoramentodo kit de desempenho
em aplicativos distribuídos usando o Visual Studio Analyzer, pelo Mai-Lan Tomsen
Bibliography
Professional Active Server Pages 3.0, Wrox Press (especialmente capítulo 26: otimizando o desempenho do ASP, George Reilly com Matthew Gibbs).
Microsoft Internet Information Services 5.0 Guia de recursos (com o kit de recursos do Windows 2000 Server), Microsoft Press.
Kit de recursos do Microsoft Internet Information Server (para o IIS 4.0), Microsoft Press.
A programação distribuiu aplicativos com COM e Microsoft Visual Basic 6.0, por Ted Pattison, Microsoft Press.
Come, por Don Box, Keith Brown, Tim Ewald e Chris vende;
Desenvolvendo usabilidade na web: a prática da simplicidade, de Jakob Nielsen, New Riders.
ASP Web SitesMicrosoft
Technet para iis
Learnasp.com
4guysfromrolla.com
15SECONDS.com
asptoday.com
asp101.com
asplists.com. Muitas listas de correspondência profissional incluem:
código rápido!
ASP Avançado
Não é o Newbiestate Management
Escalabilidade
Componentes básicos visuais
XML
Construção de componentes C ++/ATL
Useit.com: Usabilidade da web
ASP ASP
ASP MELHORES PRÁTICAS DE GEORGE REILLY
ASP Lições rápidas de Charles Carroll
Planejando para as diretrizes ASP John Meade
ASPXML
por JD Meier
dentro do XML Performance de Chris Lovett
Inside Msxml3 Performance por Chris Lovett