Exportar (0) Imprimir
Expandir Tudo

Executando testes de carga em ambientes mistos

Este tópico abrange a execução de testes de carga do Visual Studio em um ambiente misto. “Ambiente misto” é um onde os componentes do teste de carga são hospedados em diferentes contextos, como no local ou como funções de trabalho do Windows Azure. Por exemplo, um ambiente misto seria um onde os agentes de teste são executados no local e o repositório de dados é localizado em um servidor do Banco de dados SQL do Windows Azure. Isso contrasta com o sistema descrito em Visão geral do teste de carga do Visual Studio no Windows Azure. Neste tópico, todos os componentes, com exceção da estação de trabalho, são executados como funções de trabalho do Windows Azure.

Executar o teste de carga nesses ambientes mistos pode ser necessário por razões regulamentares, ou por razões específicas do aplicativo. Em qualquer caso, este tópico abrange as opções que você tem e como configurar esses cenários diversos.

Autores: Jaimie Alva Bravo, Sidney Higa, Paolo Salvatori.

Baixar

Os arquivos necessários para estes procedimentos estão localizados em: VSLoadTestInMixedEnvironments

Simultaneidade

Um fator usado para ponderar as configurações diferentes é o aumento da simultaneidade da execução e muitos processos em um grande data center. Simultaneidade é definida como uma propriedade do sistema onde várias tarefas são executadas simultaneamente, e possivelmente interagindo. Um fator que limita a simultaneidade é o número de endereços IP disponíveis. Quanto mais endereços IP o sistema usa, maior é o processamento simultâneo. Normalmente, o número de endereços disponíveis depende do tamanho do provedor de IP. Se o contrato de nível de serviço for substancial, normalmente é atribuído um grande número de endereços IP. Mas esses contratos não são comuns. No entanto, quando você usa o Windows Azure como plataforma, tem a vantagem de usar um data center da Microsoft e seus recursos. Isso inclui um grande pool de endereços IP. Os serviços hospedados do Windows Azure são atribuídos a endereços IP virtuais. Nesta discussão, os endereços IP são usados pelo balanceador de carga de uso externo (Internet) (não os serviços hospedados). E ter um grande número é uma vantagem do data center da Microsoft. Observe também que nem todos os sistemas requerem esse nível de simultaneidade.

Essa capacidade maior para simultaneidade é outro grande benefício de executar os testes de carga no Windows Azure. Esse nível de simultaneidade também é o mais difícil de reproduzir fora de um grande data center.

Fatores

Há seis fatores que afetam a simultaneidade. Os dois primeiros fatores são os contextos em que você executa o teste de carga: na nuvem e no local.

  • No local

  • Nuvem

Os outros quatro fatores são os componentes do teste de carga. São eles:

  • Controlador de teste

  • Agentes de teste

  • Repositório de resultados

  • Sistema testado

Os quatro componentes são mostrados aqui:

Fatores do teste de carga

No gráfico, as larguras relativas das linhas representam a quantidade de dados transferidos; quanto mais espessa a linha, maior a quantidade de dados. A transferência de dados mais pesada ocorre entre o controlador de teste e o repositório de resultados. A carga mais leve ocorre entre o sistema testado e o controlador. (No entanto, a carga real depende de quantos registros o sistema testado gera.) Para referência, consulte o gráfico em Visão geral do teste de carga do Visual Studio no Windows Azure.

noteObservação
Para clareza, o gráfico parte do princípio de que a estação de trabalho que hospeda o Visual Studio também hospeda o controlador de teste. Essa configuração facilita a comunicação entre o Visual Studio e o controlador de teste. Durante um teste de carga, o controlador transmite uma grande quantidade de dados ao Visual Studio para monitorar o desempenho em tempo real.

Topologias

Considerando os quatro componentes, e os dois contextos, várias opções topológicas são evidentes. Os quatro componentes do teste de carga podem existir em um contexto ou no outro. Por exemplo, as duas as topologias mais simples são indicadas aqui.

  1. Todos os componentes em nuvem.

  2. Todos os componentes no local.

Para clareza, as duas opções mais simples são mostradas nesta tabela.

 

Controlador Agentes Repositório Sistema testado Observações

No local

No local

No local

No local

Simultaneidade limitada, nenhum tráfego de rede fora do local.

Nuvem

Nuvem

Nuvem

Nuvem

Simultaneidade grande (mais endereços IP) e nenhum tráfego de rede fora da nuvem.

Agora as topologias estão mais complicadas. Para manter as coisas simples, esta tabela mostra uma divisão principal. Nesta tabela, o controlador é executado no local.

O tráfego dos agentes para o sistema testado não é levado em conta, pois é considerado parte dos custos de teste. Observe também que o tráfego de rede nas tabelas a seguir tem um custo monetário. Você é cobrado pelos dados transferidos fora do data center. O tráfego interno não é cobrado. Para obter detalhes sobre os preços, consulte o artigo sobre detalhes de preço e pesquisa por "transferências de dados medidas em GB".

A tabela a seguir mostra um ponto de divisão principal: quando o controlador de teste é executado no local. Nesse caso, o tráfego entre os componentes deve cruzar o limite, com vários graus de consequências, dependendo do componente e de seu nível de "conversa".

O controlador é executado no local

Controlador Agentes Repositório Sistema testado Observações

No local

No local

No local

Nuvem

Simultaneidade limitada, tráfego de rede do sistema testado para o controlador.

No local

No local

Nuvem

No local

Simultaneidade limitada, tráfego de rede do controlador para o repositório.

No local

No local

Nuvem

Nuvem

Simultaneidade limitada, tráfego de rede do sistema testado para o controlador e de volta para o repositório.

No local

Nuvem

No local

No local

Simultaneidade maior, tráfego de rede dos agentes para o controlador.

No local

Nuvem

No local

Nuvem

Simultaneidade maior, tráfego de rede dos agentes e do sistema testado para o controlador.

No local

Nuvem

Nuvem

No local

Simultaneidade maior, tráfego de rede dos agentes para o controlador e de volta para o repositório.

No local

Nuvem

Nuvem

Nuvem

Simultaneidade maior, tráfego de rede do agente e do sistema testado para o controlador e de volta para o repositório.

Esta tabela mostra a segunda divisão principal. Nesta tabela, o controlador é executado na nuvem.

O controlador é executado na nuvem

Controlador Agentes Repositório Sistema testado Observações

Nuvem

No local

No local

No local

Simultaneidade limitada, tráfego de rede do agente e do sistema testado para o controlador e de volta para o repositório.

Nuvem

No local

No local

Nuvem

Simultaneidade limitada, tráfego de rede do agente para o controlador e de volta para o repositório.

Nuvem

No local

Nuvem

No local

Simultaneidade limitada, tráfego de rede do agente e do sistema testado para o controlador.

Nuvem

Nuvem

Nuvem

Nuvem

Simultaneidade maior, tráfego de rede dos agentes para o controlador.

Nuvem

Nuvem

No local

No local

Simultaneidade maior, tráfego de rede do sistema testado para o controlador e de volta para o repositório.

Nuvem

Nuvem

No local

Nuvem

Simultaneidade maior, tráfego de rede do controlador para o repositório.

Nuvem

Nuvem

Nuvem

No local

Simultaneidade maior, tráfego de rede do sistema testado para o controlador.

Nuvem

Várias nuvens

Nuvem

Nuvem

Simultaneidade maior, pelo menos do sistema testado em DC1 para o controlador em DC2 (possivelmente mais, dependendo da configuração).

Recomendações

As topologias são mostradas para manter a integridade. A escolha da topologia não pode ser sua. Por exemplo, se você precisar de mais de 100 GB de armazenamento de dados do SQL Server, deverá armazená-los no local; atualmente, 100 GB é o limite do Banco de dados SQL. No entanto, se você tiver alguma reserva, estas são as melhores topologias. Estas recomendações são mais eficientes e geram os níveis mais altos de simultaneidade nas duas divisões principais (controlador no local ou controlador em nuvem).

Melhor quando o controlador é executado no local

Controlador Agentes Repositório Sistema testado Observações

No local

Nuvem

No local

No local

Simultaneidade maior, tráfego de rede dos agentes para o controlador.

No local

Nuvem

No local

Nuvem

Simultaneidade maior, tráfego de rede dos agentes e do sistema testado para o controlador.

Melhor quando o controlador é executado na nuvem

Controlador Agentes Repositório Sistema testado Observações

Nuvem

No local

Nuvem

No local

Simultaneidade limitada, tráfego de rede do agente e do sistema testado para o controlador.

Nuvem

Nuvem

Nuvem

Nuvem

Simultaneidade maior, tráfego de rede dos agentes para o controlador.

Nuvem

Várias nuvens

Nuvem

Nuvem

Simultaneidade maior, pelo menos do sistema testado em DC1 para o controlador em DC2 (possivelmente mais, depende da configuração).

Demanda de aumento de complexidade

No mundo real, o layout real dos componentes pode ser complexo. Um sistema em teste pode ter muitos subcomponentes, cada um em execução como função de trabalho ou função da Web, ou usando serviços locais. Por exemplo, um componente inicializa o sistema ou forneça serviços de validação. É provável que muitos dos componentes devem se comunicar com outras partes do sistema. Esse conjunto de componentes é um adicional do próprio do sistema de teste (que consiste em controlador, agentes e repositório). O gráfico a seguir mostra um sistema que tem muitas partes. Ele tem a finalidade apenas de ilustrar que uma solução real pode ter muitas partes e vários requisitos de comunicação. Os detalhes do sistema não são o ponto principal.

Exemplo de uma configuração complexa

Com tamanha complexidade, ainda é possível localizar vários componentes no Windows Azure, ou no local, conforme necessário. A próxima seção descreve as etapas necessárias.

Configuração

A configuração aqui é um conjunto de alternativas para a configuração básica encontrada neste documento: Provisionando o Windows Azure para um teste de carga. Os procedimentos especificam como configurar o Portal de Gerenciamento com as partes corretas. Por exemplo, explica como configurar uma conta de armazenamento e um grupo do Windows Azure Connect.

A primeira alternativa aqui permite usar o Banco de dados SQL como repositório de resultados. A segunda alternativa instrui como configurar pontos de extremidade em cada função de trabalho. Os pontos de extremidade permitem a comunicação entre os agentes, o sistema testado, o controlador de teste e (se necessário) um fator auxiliar – a estação de trabalho que hospeda o Visual Studio. No modo mais simples, o computador encontra-se no local. Mas se seu aplicativo requer que você o use durante a execução do teste, ele também pode ser hospedado como função de trabalho do Windows Azure.

Pré-requisitos

É necessário fazer o seguinte:

  • Baixar o arquivo LoadTest2010.bacpac.

  • Opcional. Instalar o Visual Studio 2010 Ultimate em uma função de trabalho.

    Se você pretende executar o controlador de teste em uma função de trabalho, instale o Visual Studio 2010 Ultimate na função de trabalho. Adicione uma função de trabalho ao projeto do Windows Azure no Visual Studio. Verifique se a Área de Trabalho Remota está habilitada. Adicione a função de trabalho a um grupo do Connect para conectá-la ao site local. Use a Área de Trabalho Remota para se conectar à função de trabalho e instale o Visual Studio 2010 Ultimate.

Usando um SQL BACPAC para provisionar o Banco de dados SQL do Windows Azure

Use este método para armazenar os resultados em um Banco de dados SQL para armazenar os dados do teste de carga. Carregue o arquivo chamado LoadTest2010.bacpac em sua conta de armazenamento do Azure. Você também deve ter os seguintes pré-requisitos:

  1. Uma conta do Banco de dados SQL.

  2. Uma instância de servidor SQL criada em uma assinatura. Para obter mais informações, consulte o artigo sobre como criar um servidor de Banco de dados SQL do Windows Azure.

  3. Um nome e uma senha de logon com permissão para modificar a instância de servidor.

Para provisionar o Banco de dados SQL com um BACPAC

  1. Carregue o arquivo LoadTest2010.bacpac em sua conta de armazenamento do Azure.

    Use o StorageServicesSmartClient para carregar o arquivo em um contêiner público. Uma vez carregado o arquivo .dacpac, você pode usar a função Importar do Portal de Gerenciamento para criar o banco de dados.

  2. No Portal de Gerenciamento, clique em Banco de Dados.

  3. Expanda a assinatura que contém o servidor de Banco de dados SQL que você usa e selecione o servidor.

  4. Na seção Banco de Dados da faixa de opções, clique em Importar.

  5. Siga as instruções para importar o arquivo LoadTest2010.bacpac: Como importar um aplicativo da camada de dados (Banco de dados SQL do Windows Azure).

Uma vez criado o repositório no Banco de dados SQL, configure o controlador de teste. Especificamente, configure a cadeia de conexão para o repositório de resultados. A caixa de diálogo para configurar o valor é encontrada somente no Visual Studio Ultimate. No entanto, antes de você continuar, há uma escolha a fazer. Decida se o controlador de teste será executado:

  1. Em um computador local.

    Se você escolher essa opção, em um computador local, siga o próximo conjunto de instruções.

  2. Em uma função de trabalho no Windows Azure, executando uma instância do Visual Studio.

    Se você decidir executar o controlador de teste em uma função de trabalho no Windows Azure:

    1. Crie o grupo do Windows Azure Connect.

    2. Adicione a estação de trabalho local ao grupo.

    3. Após a implantação do serviço hospedado, use a Área de Trabalho Remota para se conectar à função de trabalho que hospedará o Visual Studio.

    4. Instalar o Visual Studio 2010 Ultimate a partir de um arquivo de instalação (.msi) em sua rede

Para configurar a instância local do controlador de teste

  1. Execute o Visual Studio como Administrador.

  2. No Visual Studio, no menu Testar, clique em Gerenciar Controladores de Teste.

  3. Sob o texto Carregar repositório de resultados de teste, clique no botão de reticências.

  4. Na caixa de diálogo Propriedades da Conexão, cole o nome do servidor de Banco de dados SQL.

  5. Sob o texto Fazer logon no servidor, selecione a opção Usar Autenticação do SQL Server.

  6. Defina o valor de Nome de usuário como o nome de logon do administrador do Banco de dados SQL.

  7. Defina o valor do campo Senha como o valor da senha do administrador do Banco de dados SQL.

  8. Na seção Conectar a um banco de dados, selecione o banco de dados LoadTest2010.

    Se a cadeia de conexão e as credenciais estiverem corretas, examine a caixa de diálogo Configurar Controlador de Teste. A caixa de diálogo será preenchida com os valores corretos.

Usando pontos de extremidade em vez do grupo do Azure Connect

Há uma alternativa ao uso do grupo do Connect: configurar pontos de extremidade em cada função de trabalho para comunicação entre as instâncias. A vantagem aqui é que a conexão é mais segura. Use as etapas a seguir para tentar essa alternativa.

Para configurar pontos de extremidade em instâncias de função de trabalho

  1. No Visual Studio, abra o projeto Teste de Carga.

  2. Configure cada função de trabalho com pontos de extremidade TCP internos. Para obter instruções gerais sobre como adicionar pontos de extremidade à função, consulte Como definir pontos de extremidade internos para uma função. Para cada ponto de extremidade, especifique um número de porta privada diferente. A tabela a seguir mostra as configurações de ponto de extremidade para cada função. Observe que todos esses pontos de extremidade são portas privadas que usam o protocolo TCP:

     

    Nome da Função Nome da porta Número da Porta

    Agente

    SQL

    1433

    Agente

    WFS

    137-445

    Agente

    Porta do Ouvinte do Agente

    6910

    Agente

    AgentDownload

    80

    Controlador

    SQL

    1433

    Controlador

    WFS

    137-445

    Controlador

    Controlador

    6910

    Controlador

    AgentDownload

    80

    Controlador

    Porta do Ouvinte do Controlador

    6901

    Controlador

    Agente

    6910

    Controlador/Estação de trabalho

    Talkback

    49152

  3. Configure uma porta específica para permitir que o controlador envie mensagens aos agentes. Use a seguinte chave de registro na função de trabalho que hospeda o controlador:

    1. HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeStart

    2. HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\VisualStudio\10.0\EnterpriseTools\QualityTools\ListenPortRange\PortRangeEnd

  4. Na inicialização da função de trabalho, execute o arquivo setupwfw.cmd.

  5. Conecte a Área de Trabalho Remota a cada função e faça o seguinte:

    1. Abra o seguinte diretório: \Windows\System32\drivers\etc\

      Abra o arquivo hosts para editá-lo. O arquivo pode ser aberto com o Notepad.exe. Coloque o arquivo "hosts" em cada sistema que tem o nome do host e o endereço IP. Editar o arquivo é um processo manual. Para localizar o endereço IP de uma função, abra uma janela de comando em cada função e digite IPCONFIG. Um exemplo de arquivo Hosts:

    2. 
      # Copyright (c) 1993-2009 Microsoft Corp.
      #
      # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
      #
      # This file contains the mappings of IP addresses to host names. Each
      # entry should be kept on an individual line. The IP address should
      # be placed in the first column followed by the corresponding host name.
      # The IP address and the host name should be separated by at least one
      # space.
      #
      # Additionally, comments (such as these) may be inserted on individual
      # lines or following the machine name denoted by a '#' symbol.
      #
      # For example:
      #
      #      102.54.94.97     rhino.acme.com          # source server
      #       38.25.63.10     x.acme.com              # x client host
      
      # localhost name resolution is handled within DNS itself.
      #127.0.0.1       localhost
      #::1             localhost
      10.115.222.131 RD00155D317984    # workstation
      10.115.218.125 RD00155D3175BF    # Controller
      10.115.222.142 RD001455316FEE    # Agent00
      10.115.196.26 RD00D32D6747       # Agent01
      10.115.228.52  RD000155D317EBD  # Agent02
      10.115.222.131 RD00155D317984    # Agent03
      
      
  6. Cada função pode se comunicar e você pode instalar os binários em cada sistema. Para acelerar o processo, coloque os binários no repositório de blob. Além disso, execute comandos adicionais como parte da tarefa de inicialização. Para obter mais informações, consulte Como definir tarefas de inicialização para uma função).

  7. No SQL Server, crie uma conta local do SQL para o controlador e a estação de trabalho para acessar o banco de dados de resultados. Em seguida, configure o repositório para usar essas contas. Crie o banco de dados quando você configurar o controlador e depois o configure para usar a conta do IDE.


Data da compilação:

2013-07-25

Contribuições da comunidade

Mostrar:
© 2014 Microsoft