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

Existem algumas maneiras simples de marcar o desempenho da conexão entre o Office 365 e sua empresa que permitirão que você estabeleça 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 antecipadamente, identificar e prever problemas.

Se você não está acostumado a trabalhar com problemas de desempenho, este artigo foi projetado para ajudá-lo a considerar algumas perguntas comuns. Como você sabe que o problema que está enfrentando é um problema de desempenho e não um incidente de serviço do 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 estão observando um desempenho lento ao usar o Office 365, e você está se perguntando sobre qualquer uma dessas perguntas, continue lendo.

Importante

Tem um problema de desempenho entre seu cliente e o Office 365 no momento? Siga as etapas descritas no Plano de solução de problemas de desempenho do Office 365.

Algo que você deve saber sobre o desempenho do Office 365

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

As melhorias de desempenho nunca param na nuvem, portanto, nem a experiência em manter a nuvem saudável e rápida. Se você tiver um problema de desempenho ao se conectar do seu local ao 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 da sua rede e vá até o Office 365. Antes de abrir uma ocorrência com o Suporte, você pode coletar dados e executar ações que explorarão e poderão resolver o problema.

Importante

Esteja ciente do planejamento de capacidade e dos limites do Office 365. Essas informações o colocarão à frente da curva ao tentar resolver um problema de desempenho. Veja um link para as descrições dos serviços Microsoft 365 e Office 365. Este é um hub central, e todos os serviços oferecidos pelo Office 365 têm um link que vai para suas próprias descrições de serviço a partir daqui. Isso significa que, se você precisar ver os limites padrão do SharePoint, por exemplo, clique em Descrição do Serviço do SharePoint e localize a seção Limites do SharePoint.

Entre na solução de problemas entendendo que o desempenho é uma escala móvel. Não se trata de alcançar um valor idealizado e mantê-lo permanentemente. Tarefas ocasionais de alta largura de banda, como integrar um grande número de usuários ou fazer grandes migrações de dados, serão estressantes, portanto, planeje os impactos no desempenho. Você deve ter uma ideia aproximada de suas metas de desempenho, mas muitas variáveis influenciam o desempenho, portanto, o desempenho varia.

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

Ok, como é um problema de desempenho?

Primeiro, você precisa ter certeza de que o que está enfrentando é realmente 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.

Os Incidentes de Serviço acontecem quando o próprio serviço do Office 365 está enfrentando 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 ao Office 365 é lento. Por exemplo, se a Integridade atual relatar um ícone vermelho e você vir Investigando ao lado de Exchange, você também poderá receber chamadas de pessoas da sua organização que reclamam que as caixas de correio de clientes que usam o Exchange Online estão lentas. Nesse caso, é razoável supor que seu desempenho no Exchange Online foi vítima de problemas de serviço.

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

Um problema de desempenho não é um incidente de serviço, mesmo que incidentes possam causar lentidão no desempenho. Um problema de desempenho tem esta aparência:

• Ocorrerá um problema de desempenho independentemente do que a integridade atual do centro de administração estiver 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 ele acontece se você fizer a série correta de etapas.

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

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

Como definir e testar o problema de desempenho

Os problemas de desempenho geralmente surgem com o tempo, portanto, pode ser um desafio definir o problema real. Crie uma boa declaração de problema com uma boa ideia do contexto do problema e, em seguida, você precisará repetir as etapas de teste. Aqui estão alguns exemplos de declarações de problemas que não fornecem informações suficientes:

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

• Carregar meus arquivos no SharePoint está demorando uma eternidade. Por que é lento à tarde, mas em qualquer outro momento, é rápido? Não pode ser rápido?

Existem vários grandes desafios colocados pelas declarações de problemas acima. Especificamente, muitas ambiguidades para lidar. Por exemplo:

• Não está claro como alternar entre a caixa de entrada e o Calendar costumava agir no laptop.

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

• Quanto tempo dura "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 a partir de declarações gerais como essas. Por exemplo, eles não sabem quando o problema começou a acontecer. A solução de problemas pode não saber que o usuário trabalha em casa e só vê a alternância lenta enquanto está em sua rede doméstica. Ou que o usuário executa outros aplicativos com uso intensivo de RAM no cliente local. Os administradores podem não saber que o usuário está executando um sistema operacional mais antigo ou que não executou atualizações recentes.

Quando os usuários relatam um problema de desempenho, há muitas informações a serem coletadas. Obter e registrar informações é chamado de escopo do problema. Aqui está uma lista básica de escopo 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 comercial (VPN, com fio, sem fio)?

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

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

• Percorra as etapas que estão causando problemas para que você possa escrever as ações que executa.

• Qual é a lentidão em segundos ou minutos do desempenho?

• Onde no mundo você está localizado?

Algumas dessas perguntas são mais óbvias do que outras. A maioria das pessoas entenderá que uma solução de problemas precisa das etapas exatas para reproduzir o problema. Afinal, de que outra forma você pode registrar o que está errado e de que outra forma você pode testar se o problema foi corrigido? Menos óbvias são coisas como "Em 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 horário 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 Servidor do SharePoint 2013, as atualizações podem estar em andamento no farm local. Se a sua empresa estiver toda na nuvem, a manutenção do sistema poderá incluir adicionar ou remover hardware de rede, lançar atualizações para 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 a partir das evidências. Para fazer isso, você deve obter uma boa declaração do problema reunindo evidências. 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. Esta declaração de problema deve ser, e permanecer, a página mais alta em suas anotações. Percorrendo a declaração do problema novamente depois de trabalhar na resolução, você está tomando as medidas necessárias para testar e provar se as ações executadas resolveram o problema. Isso é fundamental para saber quando seu trabalho está concluído.

Você sabe como era o desempenho quando era bom?

Se você não tiver sorte, ninguém sabe. Ninguém tinha números. Isso significa que ninguém pode responder à simples pergunta "Quantos segundos costumava levar para abrir uma caixa de entrada no Office 365?" ou "Quanto tempo levava quando os executivos tinham 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 fazer uma linha de base ocasionalmente com frequência, dependendo das necessidades de 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ê aplicar patch a todos os servidores Exchange na primeira segunda-feira do mês e a todos os servidores do SharePoint na terceira segunda-feira, sua equipe de operações provavelmente terá uma lista de tarefas e cenários executados após a aplicação de patches, para provar que as funções críticas estão operacionais. Por exemplo, abrir a Caixa de Entrada, clicar em Enviar/Receber e verificar se as pastas são atualizadas ou, no SharePoint, navegar na página principal do site, entrar na página de Pesquisa corporativa e fazer uma pesquisa que retorna resultados.

Se seus aplicativos estiverem no Office 365, algumas das linhas de base mais fundamentais que você poderá seguir medem 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 vai para o 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 ter contexto (endereços IP, tipo de dispositivo, etc.) para problemas de desempenho que surgem.

  • 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.

  • Existem 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 e quanta largura de banda você tem.

• Dentro da 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 até o ponto de saída em milissegundos

• Tempo desde o ponto de saída até o Office 365 em milissegundos

• Local no mundo do servidor que resolve as URLs do Office 365 quando você navega

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

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

O que é uma linha de base?

Você saberá o impacto quando der errado, mas se não souber seus dados históricos de desempenho, não é possível ter um contexto de quão ruim ele pode ter se tornado e quando. Portanto, sem uma linha de base, você está perdendo a pista principal para resolver o quebra-cabeça: a imagem na caixa do 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 adotar. Sua equipe de operações pode ser encarregada de realizá-los em um cronograma. Por exemplo, digamos que sua conexão tenha esta aparência:

Isso significa que você verificou com sua equipe de rede e descobriu que sai da sua empresa para a Internet por meio de um servidor proxy e que o proxy lida com todas as solicitações que seu computador cliente envia para a nuvem. Nesse caso, você deve desenhar uma versão simplificada de sua conexão que lista todos os dispositivos intervenientes. Agora, insira ferramentas que você pode usar para testar o desempenho entre o cliente, o ponto de saída (onde você deixa sua rede para a Internet) e a nuvem do 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 pelo Office 365, e porque fornecem o tempo em milissegundos que leva para sair do computador cliente ou servidor proxy (se você tiver acesso) e chegar ao Office 365. Cada salto individual de um computador para outro terminará com um valor de tempo, e isso é ótimo para linhas de base! Tão importante quanto, essas ferramentas de linha de comando permitem que você adicione um número de porta ao comando, isso é útil porque o Office 365 se comunica pela porta 443, que é a porta usada pelo Secure Sockets Layer e pelo Transport Layer Security (SSL e TLS). No entanto, outras ferramentas de terceiros podem ser soluções melhores para sua situação. A Microsoft não dá suporte a todas essas ferramentas, portanto, se, por algum motivo, você não conseguir fazer o PsPing e o TraceTCP funcionarem, passe para um rastreamento de rede com uma ferramenta como o Netmon.

Você pode obter uma linha de base antes do horário comercial, novamente durante o uso intenso e depois do expediente. Isso significa que você pode ter uma estrutura de pastas que se parece um pouco com esta no final:

Você também deve escolher uma convenção de nomenclatura para 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 sobre 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 ruim, para que possamos compará-los". Isso é útil para a solução de 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 nos pontos em que você percebe alterações no comportamento dos serviços online.

Por que coletar dados de desempenho durante um piloto?

Não há melhor momento para começar a criar 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 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 que estão testando o Office 365 pode ser projetada para vários milhares, para que você saiba onde os problemas podem surgir antes que eles aconteçam.

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

Como coletar linhas de base

Para todos os planos de solução de problemas, você precisa identificar estes itens 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 este usuário está em uma VPN para a rede, trabalhando remotamente ou na intranet da empresa)

• O ponto de saída que o computador cliente usa da rede (o ponto no qual o tráfego sai da empresa para um ISP ou para a Internet)

Você pode descobrir o layout da sua rede com o administrador da rede. Se você estiver em uma rede pequena, dê uma olhada nos dispositivos que conectam você à Internet e ligue para o seu ISP se tiver dúvidas sobre o layout. Crie 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. Abordaremos métodos simples primeiro. Mas se você tem um problema de desempenho agora, deve pular para métodos avançados e experimentar o exemplo de plano de ação de solução de problemas de desempenho.

Métodos simples

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

Observação

O TraceTCP está incluído nessa 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 outro, que a solicitação leva para chegar a um destino. O TraceTCP também pode fornecer os nomes dos servidores usados durante os saltos, o que pode ser útil para uma solução de problemas do 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! > O TraceTCP é um download gratuito, mas depende do Wincap. Wincap é uma ferramenta que também é usada e instalada pela Netmon. Também usamos Netmon na seção de 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 enviar uma solicitação ao Office 365 e o Office 365 responder à solicitação. O teste se origina dentro do seu domínio em um computador cliente e procura medir uma viagem de ida e volta de dentro da rede, através de um ponto de saída, através da Internet para o Office 365 e vice-versa.

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

• Portas 80 e 443

• TCP e HTTPs

• Conexões de saída para qualquer uma destas 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 de proxy ou autenticação. 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 no Internet Explorer, vá para Ferramentas>Opções> da InternetConexões>Configurações da LAN Avançado>. A guia avançado também é onde você encontrará seu servidor proxy e a porta do servidor proxy. Talvez seja necessário marcar a caixa de seleção Usar um servidor proxy para sua LAN, para acessar o botão Avançado . Certifique-se de que Ignorar servidor proxy para endereços locais esteja marcado. Depois de selecionar Avançado, você verá uma caixa de texto onde poderá inserir exceções. Separe as URLs curinga listadas acima com ponto-e-vírgula, por exemplo:

*.microsoftonline.com; *.sharepoint.com

Depois de ignorar seu proxy, você poderá usar ping ou PsPing diretamente em uma URL do Office 365. O próximo passo será testar o ping outlook.office365.com. Ou, se você estiver usando o PsPing ou outra ferramenta que permita fornecer um número de porta para o comando, o 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 a um servidor como o outlook.office365.com e obter uma resposta de volta que reconhece que o servidor sabe que você fez isso. Às vezes, você verá isso abreviado como RTT. Isso deve ser um período de tempo relativamente curto.

Você precisa usar o PSP ou outra ferramenta que não use pacotes ICMP bloqueados pelo Office 365 para fazer esse teste.

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

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

   1. Clique em Iniciar.

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

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

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

• psping admin.microsoft.com:443

• psping microsoft-my.sharepoint.com:443

• psping outlook.office365.com:443

• psping www.yammer.com:443

  

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

Se você não está familiarizado com o desvio de proxy e prefere fazer as coisas passo a passo, primeiro precisa descobrir o nome do seu servidor proxy. No Internet Explorer, vá para Ferramentas>Opções> da InternetConexões>Configurações> da LANAvançado. A guia Avançado é onde você verá seu servidor proxy listado. Faça ping nesse servidor proxy em um prompt de comando concluindo esta tarefa:

Para executar ping no servidor proxy e obter um valor de ida e volta em milissegundos para os estágios 1 a 2

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

   1. Clique em Iniciar.

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

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

2. Digite ping \<the name of the proxy server your browser uses, or the IP address of the proxy server\> e pressione ENTER. Se você tiver o PsPing ou alguma outra ferramenta instalada, 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ê procura. Faça uma captura de tela do prompt e salve-a 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 acessar o proxy (ou qualquer servidor de saída que saia para a Internet) rapidamente. Nesse caso, seus números podem ter a seguinte aparência:

Se o seu computador cliente for um dos poucos selecionados com acesso ao servidor proxy (ou de 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 do Office 365 a partir daí. Se você não tiver acesso a esse computador, poderá entrar em contato com os recursos de rede para obter ajuda com o próximo trecho e obter os números exatos dessa maneira. Se isso não for possível, compare um PsPing com a URL do Office 365 em questão e compare-o com o tempo de PsPing ou Ping em seu servidor proxy.

Por exemplo, se você tiver 51,84 milissegundos do cliente para a URL do Office 365 e 2,8 milissegundos do cliente para o proxy (ou ponto de saída), você terá 49,04 milissegundos da saída para o Office 365. Da mesma forma, se você tiver um PsPing de 12,25 milissegundos do cliente para o proxy durante o auge do dia e 62,01 milissegundos do cliente para a URL do 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 mantendo essas linhas de base. Por exemplo, se você descobrir que geralmente tem cerca de 40 milissegundos a 59 milissegundos de latência do ponto de proxy ou saída para a URL do Office 365 e tem 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 esse horário do dia), então você certamente saberá que algo é problemático se suas últimas três linhas de base de cliente para proxy ou saída mostrarem um latência de 45 milissegundos.

Métodos avançados

Se você realmente quer saber o que está acontecendo com suas solicitações de Internet para o Office 365, você precisa se familiarizar com os rastreamentos de rede. Não importa quais ferramentas você prefere para esses rastreamentos, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, ferramenta Developer Dashboard ou qualquer outra serve, 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 visão mais completa do problema. Quando você está testando, algumas dessas ferramentas também atuam como proxies por si só. As ferramentas usadas no artigo complementar, Plano de solução de problemas de desempenho para o Office 365, incluem Netmon 3.4, HTTPWatch ou WireShark.

Usar 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ê obtenha e armazene rastreamentos de rede. A maioria dos exemplos neste artigo usa o SharePoint, mas você deve desenvolver uma lista de ações comuns nos serviços do Office 365 que você assina para testar e gravar. Veja um exemplo de linha de base:

• Lista de linha de base para SPO – Etapa 1: navegue na home page do site do SPO e faça um rastreamento de rede. Salve o rastreamento.

• Lista de linha de base para SPO – Etapa 2: pesquise um termo (como o nome da sua empresa) por meio da Pesquisa Empresarial e faça um rastreamento de rede. Salve o rastreamento.

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

• Lista de linha de base para SPO – Etapa 4: navegue na 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 executam em relação ao SharePoint. Observe que a última etapa, para rastrear o OneDrive, inclui uma comparação entre a carga da página inicial do SharePoint (que geralmente é personalizada pelas empresas) e a página inicial 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 uma linha de base. Os rastreamentos de rede tornam-se críticos, portanto, cuidaremos de como obter os rastreamentos importantes a seguir.

Para resolver um problema de desempenho, no momento, você precisa fazer um rastreamento no momento em que estiver 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 é gravar a data e a hora do teste para que os arquivos possam ser salvos em uma pasta que reflita o tempo. Em seguida, restrinja as etapas do problema em si. Estas são as etapas exatas que você usará para testar. Não se esqueça do básico: se o problema for apenas com o Outlook, certifique-se de registrar que o comportamento do problema ocorre em apenas um serviço do Office 365. Restringir o escopo desse problema ajudará você a se concentrar em algo que pode resolver.

Confira também

Gerenciar pontos de extremidade do Office 365