Ajuste de desempenho do Office 365 usando linhas de base e histórico de desempenho

Há algumas maneiras simples de marcar o desempenho da conexão entre Office 365 e sua empresa que permitirão estabelecer uma linha de base aproximada de sua conectividade. Conhecer o histórico de desempenho das conexões do computador cliente pode ajudá-lo a detectar problemas emergentes precocemente, identificar e prever problemas.

Se você não estiver acostumado a trabalhar em problemas de desempenho, este artigo será projetado para ajudá-lo a considerar algumas perguntas comuns. Como você sabe que o problema que você está vendo é um problema de desempenho e não um incidente de serviço Office 365? Como você pode planejar um bom desempenho, a longo prazo? Como você pode ficar de olho no desempenho? Se sua equipe ou clientes estiverem vendo um desempenho lento ao usar Office 365 e você se perguntar sobre qualquer uma dessas perguntas, continue a ler.

Importante

Tem um problema de desempenho entre seu cliente e Office 365 agora? Siga as etapas descritas no plano de solução de problemas de desempenho para Office 365.

Algo que você deve saber sobre Office 365 desempenho

Office 365 vive dentro de uma rede Microsoft dedicada de alta capacidade que é monitorada pela automação e pessoas reais. Parte da manutenção do Office 365 nuvem é o ajuste de desempenho e a simplificação sempre que possível. Como os clientes da nuvem Office 365 têm que se conectar pela Internet, há um esforço contínuo para ajustar o desempenho em Office 365 serviços também.

Melhorias de desempenho nunca param na nuvem, então nem a experiência em manter a nuvem saudável e rápida. Se você tiver um problema de desempenho se conectando de sua localização a Office 365, é melhor não começar ou aguardar um caso de suporte. Em vez disso, você deve começar a investigar o problema de dentro para fora. Ou seja, comece dentro de sua rede e trabalhe para Office 365. Antes de abrir um caso com suporte, você pode coletar dados e executar ações que irão explorar e podem resolve o problema.

Importante

Esteja ciente do planejamento de capacidade e dos limites em Office 365. Essas informações o colocarão à frente da curva ao tentar resolve um problema de desempenho. Aqui está um link para as descrições do serviço microsoft 365 e Office 365. Este é um hub central e todos os serviços oferecidos por Office 365 têm um link que vai para suas próprias Descrições de Serviço daqui. Isso significa que, caso você precise ver os limites padrão do SharePoint, por exemplo, você clicaria em Descrição do Serviço do SharePoint e localizaria sua seção Limites do SharePoint.

Verifique se você entra na solução de problemas com a compreensão de que o desempenho é uma escala deslizante. Não se trata de alcançar um valor idealizado e mantê-lo permanentemente. Tarefas ocasionais de alta largura de banda, como embarcar em um grande número de usuários ou fazer migrações de dados grandes, serão estressantes, portanto, planeje impactos de desempenho. Você deve ter uma ideia aproximada de suas metas de desempenho, mas muitas variáveis jogam no desempenho, portanto, o desempenho varia.

A solução de problemas de desempenho não se trata de cumprir metas específicas e manter esses números indefinidamente, trata-se de melhorar as atividades existentes, dadas todas as variáveis.

Ok, como é um problema de desempenho?

Primeiro, você precisa ter certeza de que o que você está enfrentando é de fato um problema de desempenho e não um incidente de serviço. Um problema de desempenho é diferente de um incidente de serviço no Office 365. Veja como diferenciá-los.

Incidentes de serviço acontecem quando o serviço de Office 365 em si está tendo problemas. Você pode ver ícones vermelhos ou amarelos em Integridade atual no Centro de administração do Microsoft 365. Você pode notar que o desempenho em computadores cliente que se conectam a Office 365 é lento. Por exemplo, se a integridade atual relatar um ícone vermelho e você vir Investigar ao lado do Exchange, você também poderá receber chamadas de pessoas em sua organização que reclamam que as caixas de correio do cliente usando Exchange Online são lentas. Nesse caso, é razoável supor que seu desempenho Exchange Online foi vítima de problemas de serviço.

Neste ponto, você, o Office 365 administrador, deve marcar Integridade atual e, em seguida, Exibir detalhes e histórico, muitas vezes, para manter-se atualizado sobre a manutenção no sistema. O dashboard de integridade atual foi feito para atualizá-lo sobre as alterações e problemas no serviço. As anotações e explicações escritas no histórico de integridade, administradora do administrador, estão lá para ajudá-lo a medir e para mantê-lo postado sobre o trabalho contínuo.

Um problema de desempenho não é um incidente de serviço, embora incidentes possam causar um desempenho lento. Um problema de desempenho se parece com este:

• Ocorre um problema de desempenho, não importa o que o centro de administração A integridade atual esteja relatando para o serviço.

• Um comportamento que costumava fluir leva muito tempo para ser concluído ou nunca concluído.

• Você também pode replicar o problema ou saber que isso acontece se você fizer a série certa de etapas.

• Se o problema for intermitente, ainda pode haver um padrão. Por exemplo, você sabe que às 10h terá chamadas de usuários que nem sempre podem acessar Office 365. As chamadas terminarão por volta do meio-dia.

Essa lista provavelmente soa familiar; talvez muito familiar. Quando você percebe que é um problema de desempenho, a pergunta se torna: "O que você faz a seguir?" O restante deste artigo ajuda você a determinar exatamente isso.

Como definir e testar o problema de desempenho

Problemas de desempenho geralmente surgem ao longo do tempo, portanto, pode ser desafiador definir o problema real. Create uma boa instrução de problema com uma boa ideia de contexto de problema e, em seguida, você precisa repetir as etapas de teste. Aqui estão alguns exemplos de instruções de problemas que não fornecem informações suficientes:

• Mudar da minha caixa de entrada para meu calendário costumava ser algo que eu não notei, e agora é uma pausa para café. Você pode fazê-lo agir como antes?

• Carregar meus arquivos no SharePoint está demorando para sempre. Por que é lento à tarde, mas a qualquer outra hora, é rápido? Não pode ser rápido?

Há vários grandes desafios colocados pelas instruções de problema acima. Especificamente, muitas ambiguidades para lidar. Por exemplo:

• Não está claro como alternar entre a Caixa de Entrada e o Calendário costumava agir no laptop.

• Quando o usuário diz: "Não pode ser rápido", o que é "rápido"?

• Quanto tempo é "para sempre"? São vários segundos? Ou muitos minutos? Ou o usuário poderia almoçar e a ação terminaria 10 minutos depois de voltar?

O administrador e a solução de problemas não podem estar cientes dos detalhes do problema de instruções gerais como essas. Por exemplo, eles não sabem quando o problema começou a acontecer. O solucionador de problemas pode não saber que o usuário trabalha em casa e só vê a comutação lenta durante a rede doméstica. Ou que o usuário executa outros aplicativos intensivos de RAM no cliente local. Os administradores podem não saber que o usuário está executando um sistema operacional mais antigo ou não executou atualizações recentes.

Quando os usuários relatam um problema de desempenho, há muitas informações a serem coletadas. Obter e gravar informações é chamado de escopo do problema. Aqui está uma lista de escopo básica que você pode usar para coletar informações sobre problemas de desempenho. Esta lista não é exaustiva, mas é um lugar para começar:

• Em que data o problema aconteceu, e em que hora do dia ou da noite?

• Que tipo de computador cliente você estava usando e como ele se conecta à rede de negócios (VPN, Wired, Wireless)?

• Você estava trabalhando remotamente ou estava no escritório?

• Você tentou as mesmas ações em outro computador e viu o mesmo comportamento?

• Siga as etapas que estão lhe dando o problema para que você possa escrever as ações que você derrubar.

• Quão lento em segundos ou minutos é o desempenho?

• Onde no mundo você está localizado?

Algumas dessas perguntas são mais óbvias do que outras. A maioria de todos entenderá que um solucionador de problemas precisa das etapas exatas para reproduzir o problema. Afinal, de que outra forma você pode gravar o que está errado e de que outra forma você pode testar se o problema está corrigido? Menos óbvios são coisas como "Que data e hora você viu o problema?", e "Onde no mundo você está localizado?", informações que podem ser usadas em conjunto. Dependendo de quando o usuário estava trabalhando, algumas horas de diferença de tempo podem significar que a manutenção já está em andamento em partes da rede da sua empresa. Por exemplo, sua empresa tem uma implementação híbrida, como uma Pesquisa híbrida do SharePoint, que pode consultar índices de pesquisa no SharePoint no Microsoft 365 e em uma instância local do SharePoint Server 2013, as atualizações podem estar em andamento no farm local. Se sua empresa estiver toda na nuvem, a manutenção do sistema poderá incluir adicionar ou remover hardware de rede, implantar atualizações em toda a empresa ou fazer alterações no DNS ou em outra infraestrutura principal.

Quando você está solucionando um problema de desempenho, é um pouco como uma cena de crime, você precisa ser preciso e observador para tirar conclusões das evidências. Para fazer isso, você deve obter uma boa instrução de problema coletando evidências. Ele deve incluir o contexto do computador, o contexto do usuário, quando o problema começou e as etapas exatas que expuseram o problema de desempenho. Essa instrução de problema deve ser e permanecer a página mais alta em suas anotações. Ao passar pela instrução de problema novamente depois de trabalhar na resolução, você está tomando as etapas para testar e provar se as ações que você toma resolveram o problema. Isso é fundamental para saber quando seu trabalho, lá, é feito.

Sabe como o desempenho costumava ser quando era bom?

Se você não tiver sorte, ninguém sabe. Ninguém tinha números. Isso significa que ninguém pode responder à pergunta simples "Sobre quantos segundos foi necessário para criar uma caixa de entrada em Office 365?", ou "Quanto tempo demorou para levar quando os Executivos tiveram uma reunião do Lync Online?", que é um cenário comum para muitas empresas.

O que está faltando aqui é uma linha de base de desempenho.

As linhas de base fornecem um contexto para seu desempenho. Você deve usar uma linha de base ocasionalmente para com frequência, dependendo das necessidades da sua empresa. Se você for uma empresa maior, sua equipe de Operações já pode usar linhas de base para seu ambiente local. Por exemplo, se você corrigir todos os servidores do Exchange na primeira segunda-feira do mês e todos os servidores do SharePoint na terceira segunda-feira, sua equipe de Operações provavelmente terá uma lista de tarefas e cenários que executa após o patch, para provar que as funções críticas estão operacionais. Por exemplo, abrindo a caixa de entrada, clicando em Enviar/Receber e certificando-se de que as pastas sejam atualizadas ou, no SharePoint, navegando na página main do site, entrando na página Pesquisa da empresa e fazendo uma pesquisa que retorna resultados.

Se seus aplicativos estiverem em Office 365, algumas das linhas de base mais fundamentais poderão medir o tempo (em milissegundos) de um computador cliente dentro de sua rede, até um ponto de saída ou o ponto em que você sai da rede e sai para Office 365. Aqui estão algumas linhas de base úteis que você pode investigar e registrar:

• Identifique os dispositivos entre o computador cliente e o ponto de saída, por exemplo, o servidor proxy.

  • Você precisa conhecer seus dispositivos para que você tenha contexto (endereços IP, tipo de dispositivo, etc. ) para problemas de desempenho que surgem.

  • Os servidores proxy são pontos de saída comuns, portanto, você pode marcar seu navegador da Web para ver qual servidor proxy ele está definido para usar, se houver.

  • Há ferramentas de terceiros que podem descobrir e mapear sua rede, mas a maneira mais segura de conhecer seus dispositivos é perguntar a um membro da sua equipe de rede.

• Identifique seu provedor de serviços de Internet (ISP), anote suas informações de contato e pergunte quantos circuitos você tem de largura de banda.

• Dentro de sua empresa, identifique recursos para os dispositivos entre seu cliente e o ponto de saída ou identifique um contato de emergência para conversar sobre problemas de rede.

Aqui estão algumas linhas de base que testes simples com ferramentas podem calcular para você:

• Tempo do computador cliente para o ponto de saída em milissegundos

• O tempo da saída aponta para Office 365 em milissegundos

• Local no mundo do servidor que resolve a URLS para Office 365 quando você navega

• A velocidade da resolução DNS do ISP em milissegundos, inconsistências na chegada de pacotes (nervosismo de rede), upload e tempos de download em milissegundos

Se você não estiver familiarizado com a forma de executar essas etapas, entraremos em mais detalhes neste artigo.

O que é uma linha de base?

Você saberá o impacto quando ele der errado, mas se você não conhece seus dados históricos de desempenho, não é possível ter um contexto para o quão ruim ele pode ter se tornado, e quando. Portanto, sem uma linha de base, você está perdendo a pista chave para resolver o quebra-cabeça: a imagem na caixa de quebra-cabeça. Na solução de problemas de desempenho, você precisa de um ponto de comparação. Linhas de base de desempenho simples não são difíceis de usar. Sua equipe de Operações pode ser encarregada de realizar isso em uma agenda. Por exemplo, digamos que sua conexão seja assim:

Isso significa que você verificou com sua equipe de rede e descobriu que deixou sua empresa para a Internet por meio de um servidor proxy, e esse proxy manipula todas as solicitações que seu computador cliente envia para a nuvem. Nesse caso, você deve desenhar uma versão simplificada da sua conexão que lista todos os dispositivos intervenidores. Agora, insira ferramentas que você pode usar para testar o desempenho entre o cliente, o ponto de saída (em que você sai da rede para a Internet) e a nuvem Office 365.

As opções são listadas como Simples e Avançadas devido à quantidade de experiência necessária para encontrar os dados de desempenho. Um rastreamento de rede levará muito tempo, em comparação com a execução de ferramentas de linha de comando como PsPing e TraceTCP. Essas duas ferramentas de linha de comando foram escolhidas porque não usam pacotes ICMP, que serão bloqueados por Office 365 e porque dão o tempo em milissegundos necessários para deixar o computador cliente ou o servidor proxy (se você tiver acesso) e chegar a Office 365. Cada salto individual de um computador para outro acabará com um valor de tempo, e isso é ótimo para linhas de base! Igualmente importante, essas ferramentas de linha de comando permitem adicionar um número de porta ao comando, isso é útil porque Office 365 se comunica pela porta 443, que é a porta usada pela Camada de Soquetes Seguros e Segurança da Camada de Transporte (SSL e TLS). No entanto, outras ferramentas de terceiros podem ser melhores soluções para sua situação. A Microsoft não dá suporte a todas essas ferramentas, portanto, se, por algum motivo, você não conseguir que psPing e TraceTCP funcionem, passe para um rastreamento de rede com uma ferramenta como o Netmon.

Você pode usar uma linha de base antes do horário comercial, novamente durante o uso pesado e, em seguida, novamente após o expediente. Isso significa que você pode ter uma estrutura de pasta que se parece um pouco com isso no final:

Você também deve escolher uma convenção de nomenclatura de seus arquivos. Aqui estão alguns exemplos:

• Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

• Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

• Feb_08_2015_2pmEST_PerfBaseline_BADPerf

• Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

Há muitas maneiras diferentes de fazer isso, mas usar o formato <dateTime><o que está acontecendo no teste> é um bom lugar para começar. Ser diligente com isso ajudará muito quando você estiver tentando solucionar problemas mais tarde. Mais tarde, você poderá dizer "Tirei dois traços em 8 de fevereiro, um mostrou bom desempenho e outro mostrou-se ruim, para que possamos compará-los". Isso é útil para solucionar problemas.

Você precisa ter uma maneira organizada de manter suas linhas de base históricas. Neste exemplo, os métodos simples produziram três saídas de linha de comando e os resultados foram coletados como capturas de tela, mas você pode ter arquivos de captura de rede. Use o método que funciona melhor para você. Armazene suas linhas de base históricas e consulte-as em pontos em que você observa alterações no comportamento de serviços online.

Por que coletar dados de desempenho durante um piloto?

Não há melhor hora para começar a fazer linhas de base do que durante um piloto do serviço Office 365. Seu escritório pode ter milhares de usuários, centenas de milhares ou pode ter cinco, mas mesmo com alguns usuários, você pode realizar testes para medir flutuações no desempenho. No caso de uma grande empresa, uma amostra representativa de várias centenas de usuários pilotando Office 365 pode ser projetada para fora para vários milhares para que você saiba onde os problemas podem surgir antes que eles aconteçam.

No caso de uma pequena empresa, em que o embarque significa que todos os usuários vão ao serviço ao mesmo tempo e não há piloto, mantenha medidas de desempenho para que você tenha dados para mostrar a qualquer pessoa que possa ter que solucionar problemas de uma operação de mau desempenho. Por exemplo, se você notar que, de repente, você pode andar pelo seu prédio no tempo necessário para carregar um gráfico de tamanho médio onde costumava acontecer rapidamente.

Como coletar linhas de base

Para todos os planos de solução de problemas, você precisa identificar essas coisas no mínimo:

• O computador cliente que você está usando (o tipo de computador ou dispositivo, um endereço IP e as ações que causaram o problema)

• Onde o computador cliente está localizado no mundo (por exemplo, se esse usuário em uma VPN para a rede, trabalhando remotamente ou na intranet da empresa)

• A saída aponta que o computador cliente usa de sua rede (o ponto em que o tráfego deixa sua empresa para um ISP ou internet)

Você pode descobrir o layout da sua rede no administrador de rede. Se você estiver em uma rede pequena, dê uma olhada nos dispositivos que o conectam à Internet e chame seu ISP se tiver dúvidas sobre o layout. Create um gráfico do layout final para sua referência.

Esta seção é dividida em ferramentas e métodos de linha de comando simples e opções de ferramentas mais avançadas. Primeiro, abordaremos métodos simples. Mas, se você tiver um problema de desempenho no momento, vá para métodos avançados e experimente o plano de ação de solução de problemas de desempenho de exemplo.

Métodos simples

O objetivo desses métodos simples é aprender a usar, entender e armazenar corretamente linhas de base de desempenho simples ao longo do tempo para que você seja informado sobre Office 365 desempenho. Aqui está o diagrama simples para simples, como você já viu antes:

Observação

TraceTCP está incluído nesta captura de tela porque é uma ferramenta útil para mostrar, em milissegundos, quanto tempo uma solicitação leva para ser processada e quantos saltos de rede ou conexões de um computador para o outro, que a solicitação leva para chegar a um destino. O TraceTCP também pode fornecer os nomes dos servidores usados durante o salto, o que pode ser útil para uma solução de problemas Microsoft Office 365 no Suporte. > Os comandos TraceTCP podem ser muito simples, como: >tracetcp.exe outlook.office365.com:443> Lembre-se de incluir o número da porta no comando! >TraceTCP é um download gratuito, mas depende do Wincap. O Wincap é uma ferramenta que também é usada e instalada pelo Netmon. Também usamos o Netmon na seção métodos avançados.

Se você tiver vários escritórios, precisará manter um conjunto de dados de um cliente em cada um desses locais também. Esse teste mede a latência, que, nesse caso, é um valor numérico que descreve a quantidade de tempo entre um cliente que envia uma solicitação para Office 365 e Office 365 respondendo à solicitação. O teste se origina dentro de seu domínio em um computador cliente e procura medir uma viagem de ida e volta de dentro de sua rede, por meio de um ponto de saída, pela Internet para Office 365 e voltar.

Há algumas maneiras de lidar com o ponto de saída, nesse caso, o servidor proxy. Você pode rastrear de 1 a 2 e, em seguida, de 2 a 3 e, em seguida, adicionar os números em milissegundos para obter um total final à borda da rede. Ou você pode configurar a conexão para ignorar o proxy para endereços Office 365. Em uma rede maior com um firewall, proxy reverso ou alguma combinação dos dois, talvez seja necessário criar exceções no servidor proxy que permitirão que o tráfego passe para muitas URLs. Para obter a lista de pontos de extremidade usados pelo Office 365, consulte Office 365 URLs e intervalos de endereços IP. Se você tiver um proxy de autenticação, comece testando exceções para o seguinte:

• Portas 80 e 443

• TCP e HTTPs

• Connections que estão de saída para qualquer uma dessas URLs:

• *.microsoftonline.com

• *.microsoftonline-p.com

• *.sharepoint.com

• *.outlook.com

• *.lync.com

• osub.microsoft.com

Todos os usuários precisam ter permissão para acessar esses endereços sem qualquer interferência ou autenticação de proxy. Em uma rede menor, você deve adicioná-los à sua lista de bypass de proxy no navegador da Web.

Para adicioná-los à sua lista de bypass de proxy na Internet Explorer, acesse Ferramentas>Opções> de Internet Connections>CONfigurações avançadas>. A guia avançada também é onde você encontrará o servidor proxy e a porta do servidor proxy. Talvez seja necessário selecionar a caixa de seleção Usar um servidor proxy para sua LAN para acessar o botão Avançado . Você deseja verificar se o servidor proxy bypass para endereços locais está verificado. Depois de selecionar Avançado, você verá uma caixa de texto em que poderá inserir exceções. Separe as URLs curinga listadas acima com dois pontos, por exemplo:

*.microsoftonline.com; *.sharepoint.com

Depois de ignorar seu proxy, você poderá usar ping ou PsPing diretamente em uma URL de Office 365. A próxima etapa será testar o ping outlook.office365.com. Ou, se você estiver usando o PsPing ou outra ferramenta que permitirá fornecer um número de porta para o comando, psPing em portal.microsoftonline.com:443 para ver o tempo médio de ida e volta em milissegundos.

O tempo de ida e volta, ou RTT, é um valor numérico que mede quanto tempo leva para enviar uma solicitação HTTP para um servidor como outlook.office365.com e obter uma resposta de volta que reconheça que o servidor sabe que você fez isso. Às vezes, você verá isso abreviado como RTT. Este deve ser um período relativamente curto de tempo.

Você precisa usar o PSPing ou outra ferramenta que não use pacotes ICMP bloqueados por Office 365 para fazer este teste.

Como usar o PsPing para obter um tempo geral de ida e volta em milissegundos diretamente de uma URL Office 365

1. Execute um prompt de comando elevado concluindo estas etapas:

2. Clique em Iniciar.

3. Na caixa Iniciar Pesquisa, digite cmd e pressione CTRL+SHIFT+ENTER.

4. Se a caixa de diálogo Controle de Conta de Usuário for exibida, confirme se a ação exibida é o que você deseja e clique em Continuar.

5. Navegue até a pasta em que a ferramenta (nesse caso PsPing) está instalada e teste estas URLs Office 365:

• psping admin.microsoft.com:443

• psping microsoft-my.sharepoint.com:443

• psping outlook.office365.com:443

• psping www.yammer.com:443

  

Certifique-se de incluir o número da porta de 443. Lembre-se de que Office 365 funciona em um canal criptografado. Se você PsPing sem o número da porta, sua solicitação falhará. Depois de fazer ping na lista curta, procure a média de tempo em milissegundos (ms). É isso que você quer gravar!

Se você não estiver familiarizado com o bypass de proxy e preferir levar as coisas passo a passo, primeiro você precisa descobrir o nome do servidor proxy. No Explorer da Internet, acesse Ferramentas>Opções> de Internet Connections CONfigurações>deLAN Avançadas>. A guia Avançado é onde você verá seu servidor proxy listado. Pinge esse servidor proxy em um prompt de comando concluindo esta tarefa:

Para pingar o servidor proxy e obter um valor de ida e volta em milissegundos para o estágio 1 a 2

1. Execute um prompt de comando elevado concluindo estas etapas:

2. Clique em Iniciar.

3. Na caixa Iniciar Pesquisa, digite cmd e pressione CTRL+SHIFT+ENTER.

4. Se a caixa de diálogo Controle de Conta de Usuário for exibida, confirme se a ação exibida é o que você deseja e clique em Continuar.

5. Digite ping <o nome do servidor proxy que seu navegador usa ou o endereço IP do servidor> proxy e pressione ENTER. Se você tiver o PsPing ou alguma outra ferramenta instalada, você poderá optar por usar essa ferramenta.

   Seu comando pode se parecer com qualquer um destes exemplos:

• ping ourproxy.ourdomain.industry.business.com

• ping 155.55.121.55

• ping ourproxy

• psping ourproxy.ourdomain.industry.business.com:80

• psping 155.55.121.55:80

• psping ourproxy:80

3. Quando o rastreamento parar de enviar pacotes de teste, você receberá um pequeno resumo que lista uma média, em milissegundos, e esse é o valor que você está atrás. Faça uma captura de tela do prompt e salve-o usando sua convenção de nomenclatura. Neste ponto, também pode ajudar a preencher o diagrama com o valor.

Talvez você tenha feito um rastreamento no início da manhã, e seu cliente possa chegar ao proxy (ou qualquer servidor de saída sai rapidamente para a Internet) rapidamente. Nesse caso, seus números podem ser semelhantes a este:

Se o computador cliente for um dos poucos selecionados com acesso ao servidor proxy (ou saída), você poderá executar a próxima etapa do teste conectando-se remotamente a esse computador, executando o prompt de comando para PsPing em uma URL de Office 365 a partir daí. Se você não tiver acesso a esse computador, entre em contato com seus recursos de rede para obter ajuda com a próxima etapa e obter números exatos dessa forma. Se isso não for possível, use um PsPing em relação à URL Office 365 em questão e compare-o com o tempo de PsPing ou Ping em relação ao servidor proxy.

Por exemplo, se você tiver 51,84 milissegundos do cliente para a URL Office 365 e tiver 2,8 milissegundos do cliente para o proxy (ou ponto de saída), você terá 49,04 milissegundos da saída para Office 365. Da mesma forma, se você tiver um PsPing de 12,25 milissegundos do cliente para o proxy durante a altura do dia e 62,01 milissegundos do cliente para a URL Office 365, o valor médio da saída do proxy para a URL do Office 365 será de 49,76 milissegundos.

Em termos de solução de problemas, você pode encontrar algo interessante apenas de manter essas linhas de base. Por exemplo, se você descobrir que geralmente tem cerca de 40 milissegundos a 59 milissegundos de latência do proxy ou saída, aponte para a URL Office 365, e ter um cliente para proxy ou latência de ponto de saída de cerca de 3 milissegundos a 7 milissegundos (dependendo da quantidade de tráfego de rede que você está vendo durante essa hora do dia) então você certamente saberá que algo é problemático se seus últimos três clientes para proxy ou linhas de base de saída mostrarem um latência de 45 milissegundos.

Métodos avançados

Se você realmente quiser saber o que está acontecendo com suas solicitações de Internet para Office 365, você precisa se familiarizar com os rastreamentos de rede. Não importa quais ferramentas você prefere para esses rastreamentos, HTTPWatch, Netmon, Analisador de Mensagens, Wireshark, Fiddler, Ferramenta do Painel do Desenvolvedor ou qualquer outra fará desde que essa ferramenta possa capturar e filtrar o tráfego de rede. Você verá nesta seção que é benéfico executar mais de uma dessas ferramentas para obter uma imagem mais completa do problema. Quando você está testando, algumas dessas ferramentas também atuam como proxies por conta própria. As ferramentas usadas no artigo complementar, plano de solução de problemas de desempenho para Office 365, incluem Netmon 3.4, HTTPWatch ou WireShark.

Tomar uma linha de base de desempenho é a parte simples desse método e muitas das etapas são as mesmas de quando você soluciona um problema de desempenho. Os métodos mais avançados de criação de linhas de base para desempenho exigem que você leve e armazene rastreamentos de rede. A maioria dos exemplos neste artigo usa o SharePoint, mas você deve desenvolver uma lista de ações comuns entre os serviços de Office 365 aos quais você assina o teste e o registro. Aqui está um exemplo de linha de base:

• Lista de linha de base para SPO – ** Etapa 1: ** Navegue pela página inicial do site do SPO e faça um rastreamento de rede. Salve o rastreamento.

• Lista de linha de base para SPO – Etapa 2: Pesquisa para um termo (como o nome da empresa) via Enterprise Pesquisa e fazer um rastreamento de rede. Salve o rastreamento.

• Lista de linha de base para SPO – Etapa 3: carregue um arquivo grande em uma biblioteca de documentos do SharePoint e faça um rastreamento de rede. Salve o rastreamento.

• Lista de linha de base para SPO – Etapa 4: navegue pela página inicial do site do OneDrive e faça um rastreamento de rede. Salve o rastreamento.

Essa lista deve incluir as ações comuns mais importantes que os usuários tomam em relação ao SharePoint. Observe que a última etapa, para rastrear indo para o OneDrive, cria uma comparação entre a carga da home page do SharePoint (que geralmente é personalizada por empresas) e a home page do OneDrive, que raramente é personalizada. Este é um teste básico quando se trata de um site do SharePoint de carregamento lento. Você pode criar um registro dessa diferença em seus testes.

Se você estiver no meio de um problema de desempenho, muitas das etapas serão as mesmas de quando se toma uma linha de base. Os rastreamentos de rede tornam-se críticos, portanto, trataremos como fazer os rastreamentos importantes a seguir.

Para resolver um problema de desempenho, no momento, você precisa estar seguindo um rastreamento no momento em que está enfrentando o problema de desempenho. Você precisa ter as ferramentas adequadas disponíveis para coletar logs e precisa de um plano de ação, ou seja, uma lista de ações de solução de problemas a serem executadas para coletar as melhores informações possíveis. A primeira coisa a fazer é registrar a data e a hora do teste para que os arquivos possam ser salvos em uma pasta que reflita o tempo. Em seguida, reduza-se às etapas de problema por conta própria. Estas são as etapas exatas que você usará para teste. Não se esqueça do básico: se o problema for apenas com o Outlook, registre se o comportamento do problema acontece em apenas um serviço Office 365. Reduzir o escopo desse problema ajudará você a se concentrar em algo que você pode resolve.

Confira também

Gerenciar pontos de extremidade do Office 365