Considerações para testes de carga
Este tópico fornece dicas para a realização de testes de carga grande no Visual Studio Ultimate. Os seguintes assuntos são discutidos:
Escolhendo o padrão de carga adequada
Escolher o modelo de conexão apropriada
Taxa de amostragem e coleta de dados
Think Time
Solicitações de teste de metas de tempo de resposta de configuração para desempenho de Web
Incluindo detalhes de tempo para coletar dados de percentil
Definir a porcentagem da nova propriedade de usuários
Ativando o ASP.NET Profiler
Ativar o log de Virtual
Ativar o rastreamento de SQL
Manter um número apropriado de computadores de agente
Escolhendo o padrão de carga adequada
Existem três tipos de padrões de carga: constante, por etapa e baseado em objetivo. Para escolher o padrão de carga é apropriado para seu teste de carga, você deve compreender as vantagens de cada tipo. Para obter mais informações, consulte Edição de padrões de carga para modelar as atividades do usuário Virtual.
Constante |
Um padrão de carga constante é útil quando você deseja executar o teste de carga com a mesma carga de usuário por um longo período de tempo. Se você especificar uma carga alta de usuário com um padrão de carga constante, é recomendável que você especificar também um tempo de aquecimento para o teste de carga. Quando você especifica um tempo de aquecimento, você evita pela sobrecarga de seu site por ter centenas de novas sessões de usuário, acessando o site ao mesmo tempo. |
Por Etapa |
Um padrão de carga de etapa é um dos padrões de carga mais comuns e úteis, porque ele permite monitorar o desempenho do seu sistema, como os aumentos de carga do usuário. Monitorar seu sistema de medida que aumenta a carga usuário permite que você determine o número de usuários que podem ser suportadas com tempos de resposta aceitável, ou por outro lado, o número de usuários em que desempenho torna-se inaceitável. Se cada etapa adiciona um grande número de usuários, por exemplo, mais de 50 usuários, considere o uso de Tempo Etapa propriedade escalone o início dos usuários na etapa. Para obter mais informações, consulte Como: Especificar a propriedade de tempo de rampa de etapa para um padrão de carga de etapa. |
Baseado em objetivo |
Um padrão de carga baseado em objetivo é semelhante a um padrão de carga da etapa, a carga de usuário normalmente está aumentando ao longo do tempo, mas permite que você especifique que a carga deve parar o aumentar quando algum contador de desempenho atinge um determinado nível. Por exemplo, você pode usar um padrão de carga baseado em objetivo para continuar a aumentar a carga até que um de seus servidores de destino é de 75% ocupado e manter a carga estável. |
Se nenhum padrão de carga predefinidas atender às suas necessidades, também é possível implementar um plug-in de teste de carga personalizados que controla a carga de usuário como a execução de teste de carga. Para obter mais informações, consulte Criar e usar o Custom Plug-ins para carga e testes de desempenho de Web.
Escolhendo o modelo de conexão de teste de desempenho da Web apropriados
Load Test Run Settings diferentes opções de suporte para modelagem de conexões de usuário para o servidor Web usando o Modelo de conexão de teste da Web propriedade. Existem três tipos de modelo de conexão: conexão por usuário, o pool de conexão e conexão por iteração do teste. Para escolher o modelo de conexão que é apropriado para seu teste de carga, você deve compreender as vantagens de cada tipo.
Conexão por usuário |
A conexão por modelo de usuário mais parecida simula o comportamento de um navegador real. Cada usuário virtual que esteja executando um teste de desempenho da Web usa conexões de até seis para cada servidor Web. Conexão são mantidas abertas para o servidor Web que são dedicados a esse usuário virtual. A primeira conexão é estabelecida quando a primeira solicitação no teste de desempenho da Web é emitida. Conexões adicionais podem ser usados quando uma página contém mais de uma solicitação dependente; Essas solicitações podem ser emitidas em paralelo usando as conexões adicionais. Usam navegadores mais antigos até duas conexões por servidor Web, mas o FireFox 3 e o Internet Explorer 8 usam até 6 conexões por servidor Web. Essas mesmas conexões são reutilizadas para o usuário virtual durante todo o teste de carga. A desvantagem da conexão modelo por usuário é que o número de conexões mantidas abertas no computador agente pode ser tão alto quanto a carga de usuário seis vezes, ou ainda mais altos se destinam-se vários servidores Web e os recursos necessários para oferecer suporte a contagem dessa alta conexão podem limitar a carga de usuário pode ser ativada em um agente de teste de carga único. |
Pool de conexão |
O modelo de pool de conexão preserva os recursos no agente de teste de carga por compartilhar as conexões ao servidor Web entre vários usuários de teste de desempenho Web virtuais. No modelo de pool de conexão, o tamanho do pool de conexão Especifica o número máximo de conexões para certificar-se entre o agente de teste de carga e o servidor Web. Se a carga de usuário for maior que o tamanho do pool de conexão, testes de desempenho de Web que executam em nome de diferentes usuários virtuais irão compartilhar uma conexão. Este é o melhor modelo para usar para orientar a maioria dos carga no nível do aplicativo. Compartilhando uma conexão significa que um teste de desempenho da Web talvez precise aguardar antes de emitir uma solicitação quando outro teste de desempenho de Web está usando a conexão. O tempo médio de um teste de desempenho de Web aguarda antes de enviar uma solicitação é controlado pelo contador de desempenho de teste de carga Média Tempo de espera da conexão. Esse número deve ser menor que o tempo médio de resposta para uma página. Se não estiver, o tamanho do pool de conexão é provavelmente muito pequeno. |
Conexão por iteração do teste |
Conexão por iteração teste fecha a conexão após cada iteração do teste e abre uma nova conexão na próxima iteração. Essa configuração colocará a tensão da maioria nos seus logons de rede. A menos que esse é um requisito, é recomendável que você use uma das duas opções anteriores. |
Taxa de amostragem e coleta de dados
Escolha uma taxa de amostragem apropriado com base no comprimento do seu teste de carga. Uma taxa de amostra pequena, por exemplo, cinco segundos, coleta mais dados para cada contador de desempenho do que uma taxa de amostra grande. Coletar grande quantidade de dados para um longo período de tempo pode causar erros de espaço em disco. Para testes extensos de carga, você pode aumentar a taxa de amostragem para reduzir a quantidade de dados que você coleta. O número de contadores de desempenho também afeta a quantidade de dados é coletado. Para computadores em teste, reduzindo o número de contadores reduzirá a quantidade de dados coletados.
Você deve testar para determinar a taxa de amostragem que funcionará melhor para seu teste de carga específico. No entanto, a tabela a seguir fornece as taxas de amostragem de recomendado que você pode usar para começar.
Duração do teste de carga |
Recomendado a taxa de amostragem |
|---|---|
< 1 Hora |
5 segundos |
1 - 8 Horas |
15 segundos |
8 - 24 Horas |
30 segundos |
> 24 Horas |
60 segundos |
Think Time
O tempo de reflexão para solicitações de teste de desempenho da Web tem um efeito significativo sobre o número de usuários que podem ser suportadas com tempos de resposta razoável. Alterando tempos de reflexão de 2 segundos para 10 segundos será normalmente permitem que você simule 5 vezes a tantos usuários. No entanto, se o seu objetivo é simular usuários reais, você deve definir o tempo de reflexão com base em como você acha que os usuários irão se comportar em seu site. Aumentar o tempo de reflexão e o número de usuários não necessariamente colocará fadiga adicional no seu servidor Web. Se o site for autenticado, o tipo de esquema usado afetará o desempenho.
Se você desabilitar os tempos de reflexão para um teste de desempenho da Web, você poderá gerar um teste de carga que possui o maior throughput em termos de solicitações por segundo. Se você desabilitar os tempos de reflexão, você também deve reduzir o número de usuários para um muito menor número quando pensa vezes são ativados. Por exemplo, se você desabilitar os tempos de reflexão e tente executar a 1.000 usuários, você provavelmente sobrecarregar o servidor de destino ou o agente de teste de carga.
Para obter mais informações, consulte Os tempos de reflexão para simular os atrasos de interação humana do Site da Web em cenários de testes de carga de edição..
A definição de objetivos de tempo de resposta para solicitações de teste de desempenho da Web
Uma das propriedades de uma solicitação de teste da Web é o objetivo de tempo de resposta. Se você definir objetivos de tempo de resposta para suas solicitações de teste de desempenho de Web, quando o teste de desempenho de Web é executado em um teste de carga, o Load Test Analyzer irá relatar o percentual de testes de desempenho da Web para o qual o tempo de resposta não atendeu a meta. Por padrão, não há nenhuma resposta objetivos de tempo definidos para solicitações da Web.
Além disso, se você usar a regra de validação de meta de tempo de resposta, páginas que não atenderem a meta de tempo de resposta resultará em um erro no teste de carga. Se você usar o log de erro, você pode ver qual era virtual que usuário estava fazendo quando ocorreu a página lenta.
Para obter mais informações, consulte Como: Definir metas de tempo de resposta de página em um teste de desempenho de Web.
Incluindo detalhes de tempo para coletar o dados de percentil e o modo de exibição de detalhes de ativação
As configurações de execução incluem uma propriedade chamada Timing Details Storage. Se essa propriedade estiver ativada, o tempo que leva para executar cada teste individual, a transação e a página durante o teste de carga será armazenado no repositório de resultados de teste de carga. Isso permite que o gráfico de atividade de usuários virtuais no analisador de teste de carga. Ele também permite que os percentuais de 90th, 95th e 99th e o desvio padrão a ser mostrado no analisador de teste de carga na testes, transações, e páginas tabelas.
Por padrão, Timing Details Storage propriedade estiver habilitada para suportar o gráfico de atividade do usuário Virtual no modo de exibição de detalhes no resultado de teste de carga usando o Load Test Analyzer.
Você deve considerar a desativação do Timing Details Storage propriedade para grandes testes. Há dois motivos importantes para fazer isso.
A quantidade de espaço necessária no repositório de resultados de teste de carga para armazenar dados de detalhes de tempo pode ser muito grande, especialmente para testes de carga longo.
O tempo para armazenar esses dados no repositório de resultados no final do teste de carga é longo, porque esses dados são armazenados em agentes de teste de carga até que o teste de carga tenha terminado a execução de teste de carga.
Se houver espaço em disco suficiente no repositório de resultados de teste de carga, você pode habilitar Timing Details Storage para obter os dados percentil. Você tem duas opções para habilitar Timing Details Storage: StatisticsOnly e AllIndividualDetails. Com opção, todos os testes individuais, páginas e as transações são calculadas e dados de percentil são calculados a partir de dados de tempo individuais. Se você optar por StatisticsOnly, dados de tempo individual são excluídos do repositório após os dados percentil foi calculados. A exclusão de dados reduz a quantidade de espaço necessária no repositório. No entanto, se você deseja processar dados de detalhes de tempo diretamente, usando ferramentas SQL ou Ativar visualização virtual detalhes do usuário no gráfico de atividade do usuário Virtual escolher AllIndividualDetails para que os dados de detalhes de tempo é salvo no repositório.
Para obter mais informações, consulte Analisando a atividade do usuário Virtual no modo de exibição de detalhes do analisador de teste de carga de teste de carga e Como: Configurar os testes de carga para coletar detalhes completos para habilitar a atividade do usuário Virtual nos resultados de teste.
Definir a porcentagem da nova propriedade de usuários
Cada cenário em um teste de carga tem uma propriedade chamada Percentual de novos usuários. Esta propriedade afeta a maneira como o mecanismo de tempo de execução de teste de carga simula o armazenamento em cache seria realizado por um navegador da Web. O valor padrão para Percentual de novos usuários é 0. Isso significa que cada usuário virtual mantém um cache de virtual de solicitações dependentes e uma lista de cookies entre iterações de teste. O cache funciona como um cache do navegador, portanto, não serão feitas as solicitações subseqüentes para a url, que mais se aproxime modela os navegadores da Web reais.
Se a porcentagem de novos usuários é definido como 100%, a cada usuário é efetivamente um "usuário de uma vez" e nunca retorna ao site. Nesse caso, cada iteração de teste de desempenho de Web é executada em um teste de carga é tratada como um usuário ao site da Web, que não possui conteúdo do site no cache do navegador em visitas anteriores. Portanto, todas as solicitações no teste de desempenho da Web, incluindo todas as solicitações dependentes, como, por exemplo, imagens, são baixadas.
.gif "Observação") Observação |
|---|
Uma exceção é o caso em que o mesmo recurso armazenáveis em cache é solicitado várias vezes em um teste de desempenho da Web. |
Use o valor padrão de 0 por cento de novos usuários para orientar a carga mais para a camada de aplicativo do site da Web. Não apenas oferece isso mais detalhadamente modelar usuários reais, mas ele também será unidade mais carga à camada do aplicativo onde ocorrem a maioria dos problemas de desempenho. Para obter mais informações, consulte Como: Especifique a porcentagem de usuários virtuais que usam dados de Cache da Web.
Ativando o ASP.NET Profiler
Um novo recurso do Microsoft Visual Studio 2010 é o ASP.NET adaptador de dados de diagnóstico do profiler que permite que você colete ASP.NET dados do profiler da camada de aplicativo, enquanto você executa um Test de carga. Você não deve executar o profiler para testes extensos de carga, por exemplo em testes de carga executando mais de uma hora, como o arquivo do profiler pode se tornar grandes (de centenas de megabytes). Em vez disso, execute testes de carga menores com o ASP.NET profiler, que ainda fornecerá o benefício do diagnóstico profunda de problemas de desempenho.
Para obter mais informações, consulte Como: Configure o ASP.NET o Profiler para carregar testes usando o teste das configurações.
Ativar o log de Virtual
Um novo recurso do Microsoft Visual Studio 2010 permite que você colete logs completos para testes com falha ou especificando uma freqüência para fazer testes. O log será controlado pelo Salvar o Log em caso de falha do teste, Salvar a freqüência de Log para testes concluídos, e Máximo Logs de teste propriedades. O número de logs coletados é controlado pelo Logs de teste máximo e o Salvar a freqüência de Log para testes concluídos configurações de propriedade. As configurações padrão de impedirem que um grande número de logs sendo coletados. Para testes de execução demorada que irá gerar milhões de solicitações, não use o Salvar a freqüência de Log para testes concluídos configuração ou o número de logs se tornará muito grande. Além disso, manter o Logs de teste máximo configuração de propriedade (que, na verdade, controla o número máximo de registros por tipo de erro) em um número razoável. Você deve manter essas configurações para evitar a coleta de dezenas de milhares de logs, pois isso aumentará o tempo no final do teste para coletar os logs e levará o espaço de armazenamento do banco de dados de teste de carga.
Para obter mais informações, consulte Modificar configurações de log de teste de carga.
Ativar o rastreamento de SQL
As configurações de execução incluem uma propriedade chamada sql Tracing Enabled. Essa propriedade permite que você ativar o recurso de rastreamento do de Microsoft SQL Server para a duração do teste de carga. Esta é uma alternativa para iniciar uma sessão separada do gerador de perfil SQL durante a execução do teste de carga para diagnosticar problemas de desempenho de SQL. Se a propriedade estiver habilitada, os dados de rastreamento SQL são exibidos no analisador de teste de carga. Você pode visualizá-lo no tabelas página o O rastreamento de SQL tabela.
Para ativar esse recurso, o usuário que está executando o teste de carga deve ter privilégios SQL necessários para executar o rastreamento de SQL. Quando um teste de carga é executado em uma máquina remota, usando um agente de teste e o controlador de teste, o usuário controlador deve ter os privilégios SQL. Você também deve especificar um diretório, geralmente um compartilhamento de rede, onde o arquivo de dados de rastreamento será gravado. Após a conclusão do teste de carga, o arquivo de dados de rastreamento é importado para o repositório de teste de carga e associado com o teste de carga, para que possam ser exibida posteriormente usando o Load Test Analyzer.
Para obter mais informações, consulte Definindo as configurações de execução de teste de carga e Como: Integrar dados de rastreamento SQL usando o Load Test Editor..
Manter um número apropriado de computadores de agente
Se um computador agente tem mais de 75% de utilização da CPU ou tiver menos de 10% de memória física disponível, está sobrecarregado. Adicione mais agentes para o seu controlador de teste para garantir que o computador do agente não se torna o gargalo em seu teste de carga.
Para obter mais informações, consulte Distribuindo os testes de carga em várias máquinas de teste usando o controladores de teste e agentes de teste e Como: Especificar os agentes de teste para usar nos cenários de teste de carga.
Consulte também
Tarefas
Testes de carga de solução de problemas
Conceitos
Análise de erros em testes de carga usando a tabela de erros
Analisando as violações de regra de limite nos testes de carga usando o Load Test Analyzer
Outros recursos
Criando e editando testes de carga
Consideration for Load Tests that Contain Web Performance Tests