Plano de solução de problemas de desempenho do Office 365

Você precisa saber as etapas a serem seguidas para identificar e corrigir atrasos, travamentos e desempenho lento entre o SharePoint Online, o OneDrive for Business, o Exchange Online ou o Skype for Business Online e o computador cliente? Antes de chamar o suporte, este artigo pode ajudá-lo a solucionar Office 365 problemas de desempenho e até mesmo corrigir alguns dos problemas mais comuns.

Este artigo é, na verdade, um plano de ação de exemplo que você pode usar para capturar dados valiosos sobre seu problema de desempenho enquanto ele está acontecendo. Alguns dos principais problemas também estão incluídos neste artigo.

Se você for novo no desempenho de rede e quiser fazer um plano de longo prazo para monitorar o desempenho entre os computadores cliente e o Office 365, dê uma olhada no ajuste de desempenho e na solução de problemas do Office 365 – Administrador e administrador de ti Pro.

Exemplo de plano de ação de solução de problemas de desempenho

Este plano de ação contém duas partes; uma fase de preparação e uma fase de registro em log. Se você tiver um problema de desempenho no momento e precisar fazer a coleta de dados, poderá começar a usar esse plano imediatamente.

Preparar o computador cliente

  • Localize um computador cliente que possa reproduzir o problema de desempenho. Este computador será usado durante a solução de problemas.
  • Anote as etapas que fazem com que o problema de desempenho ocorra para que você esteja pronto quando chegar a hora de testar.
  • Instale ferramentas para coletar e gravar informações:
    • Instale o Netmon 3.4 (ou use uma ferramenta de rastreamento de rede equivalente).
    • Instale a Edição Básica gratuita do HTTPWatch (ou use uma ferramenta de rastreamento de rede equivalente).
    • Use um gravador de tela ou execute o Gravador de Etapas (PSR.exe) que vem com o Windows Vista e posterior, para manter um registro das etapas executadas durante o teste.

Registrar em log o problema de desempenho

  • Feche todos os navegadores de Internet desnecessários.

  • Inicie o Gravador de Etapas ou outro gravador de tela.

  • Inicie a captura do Netmon (ou a ferramenta de rastreamento de rede).

  • Limpe o cache DNS no computador cliente da linha de comando digitando ipconfig /flushdns.

  • Inicie uma nova sessão do navegador e ative o HTTPWatch.

  • Opcional: se você estiver testando Exchange Online, execute a ferramenta Exchange client Performance Analyzer no console Office 365 administrador.

  • Reproduza as etapas exatas que causam o problema de desempenho.

  • Interrompa o rastreamento do Netmon ou de outra ferramenta.

  • Na linha de comando, execute uma rota de rastreamento para sua assinatura Office 365 digitando o seguinte comando e pressionando ENTER:

    tracert <subscriptionname>.onmicrosoft.com
    
  • Pare o Gravador de Etapas e salve o vídeo. Certifique-se de incluir a data e a hora da captura e se ela demonstra um desempenho bom ou ruim.

  • Salve os arquivos de rastreamento. Novamente, certifique-se de incluir a data e a hora da captura e se ela demonstra um desempenho bom ou ruim.

Se você não estiver familiarizado com a execução das ferramentas mencionadas neste artigo, não se preocupe, pois forneceremos essas etapas em seguida. Se você estiver acostumado a fazer esse tipo de captura de rede, poderá pular para Como coletar linhas de base, que descrevem a filtragem e a leitura dos logs.

Liberar o Cache DNS primeiro

Por quê? Ao liberar o cache DNS, você está iniciando os testes com um slate limpo. Ao limpar o cache, você está redefinindo o conteúdo do resolvedor de DNS para as entradas mais atualizadas. Lembre-se de que uma liberação não remove entradas de arquivo HOST. Se você usar entradas de arquivo HOST extensivamente, deverá copiar essas entradas para um arquivo em outro diretório e esvaziar o arquivo HOST.

Liberar o cache do resolvedor DNS

  1. Abra o prompt de comando (cmd Iniciar > Execução > ou Windows cmd de > tecla).

  2. Digite o comando a seguir e pressione ENTER:

    ipconfig /flushdns
    

Netmon

A ferramenta de Monitoramento de Rede (Netmon) da Microsoft analisa pacotes, ou seja, o tráfego, que passa entre computadores em redes. Usando o Netmon para rastrear o tráfego com Office 365 você pode capturar, exibir e ler cabeçalhos de pacote, identificar dispositivos interveniência, verificar configurações importantes no hardware de rede, procurar pacotes descartados e seguir o fluxo de tráfego entre computadores em sua rede corporativa e Office 365. Como o corpo real do tráfego é criptografado, ou seja, ele (viaja na porta 443 via SSL/TLS, você não pode ler os arquivos que estão sendo enviados. Em vez disso, você obtém um rastreamento não filtrado do caminho que o pacote usa, o que pode ajudá-lo a rastrear o comportamento do problema.

Certifique-se de não aplicar um filtro no momento. Em vez disso, execute as etapas e demonstre o problema antes de interromper o rastreamento e salvar.

Depois de instalar o Netmon 3.4, abra a ferramenta e execute estas etapas:

Fazer um rastreamento do Netmon e reproduzir o problema

  1. Inicie o Netmon 3.4. Há três painéis na página Inicial: Capturas Recentes, Selecionar Redes e o Introdução com o Microsoft Network Monitor 3.4. Observe. O painel Selecionar Redes também fornecerá uma lista das redes padrão das quais você pode capturar. Verifique se as placas de rede estão selecionadas aqui.

  2. Clique em Nova Captura na parte superior da página Inicial. Isso adiciona uma nova guia ao lado da guia Página Inicial chamada Captura 1. Interface do usuário do Netmon com os botões Nova Captura, Iniciar e Parar realçados.

  3. Para fazer uma captura simples, clique em Iniciar na barra de ferramentas.

  4. Reproduza as etapas que apresentam um problema de desempenho.

  5. Clique em Parar > Arquivo > Salvar como. Lembre-se de fornecer a data e a hora com o fuso horário e mencionar se ele demonstra um desempenho ruim ou bom.

HTTPWatch

O HTTPWatch é cobrado e uma edição gratuita. A Edição Básica gratuita abrange tudo o que você precisa para este teste. O HTTPWatch monitora o tráfego de rede e o tempo de carregamento da página diretamente da janela do navegador. HTTPWatch é um plug-in do Internet Explorer que descreve graficamente o desempenho. A análise pode ser salva e exibida no HTTPWatch Studio.

Observação

Se você usar outro navegador, como Firefox, Google Chrome ou se não puder instalar o HTTPWatch no Internet Explorer, abra uma nova janela do navegador e pressione F12 no teclado. Você deverá ver o pop-up Ferramenta de Desenvolvedor na parte inferior do navegador. Se você usar o Opera, pressione CTRL+SHIFT+I para o Inspetor da Web, clique na guia Rede e conclua o teste descrito abaixo. As informações serão ligeiramente diferentes, mas os tempos de carregamento ainda serão exibidos em milissegundos. > HTTPWatch também é muito útil para problemas com SharePoint de carregamento de página online.

Executar HTTPWatch e reproduzir o problema

O HTTPWatch é um plug-in do navegador, portanto, expor a ferramenta no navegador é um pouco diferente para cada versão do Internet Explorer. Normalmente, você pode encontrar HTTPWatch na barra De comandos no navegador Internet Explorer. Se você não vir o plug-in HTTPWatch na janela do navegador, > verifique a versão do navegador clicando em Ajuda sobre ou em versões posteriores do Internet Explorer, clique no símbolo de engrenagem e sobre o Internet Explorer. Para iniciar a barra comandos , clique com o botão direito do mouse na barra de menus no Internet Explorer e clique na barra de comandos.

No passado, o HTTPWatch foi associado aos comandos e às barras do Explorer, portanto, depois de instalar, se você não vir imediatamente o ícone (mesmo após a reinicialização) verificar ferramentas e suas barras de ferramentas para o ícone. Lembre-se de que as barras de ferramentas podem ser personalizadas e as opções podem ser adicionadas a elas.

Barra de ferramentas Comando do Internet Explorer com o ícone HTTPWatch exibido.

  1. Inicie o HTTPWatch em uma janela do navegador Internet Explorer. Ele aparecerá encaixado no navegador na parte inferior dessa janela. Clique em Gravar.

  2. Reproduza as etapas exatas envolvidas no problema de desempenho. Clique no botão Parar em HTTPWatch.

  3. Salve o HTTPWatch ou Envie por Email. Lembre-se de nomear o arquivo para que ele inclua informações de data e hora e uma indicação de se seu Relógio contém uma demonstração de desempenho bom ou ruim.

HTTPWatch mostrando a guia Rede para um carregamento de página da home page do Office 365.

Esta captura de tela é da Professional do HTTPWatch. Você pode abrir rastreamentos feitos na Versão Básica em um computador com uma Professional e lê-lo lá. Informações adicionais podem estar disponíveis no rastreamento por meio desse método.

Gravador de Etapas do Problema

O Gravador de Etapas, PSR.exe, permite que você registre problemas à medida que eles estão ocorrendo. É uma ferramenta muito útil e simples de executar.

Execute o Gravador de Etapas do Problema (PSR.exe) para gravar seu trabalho

  1. Use o tipo Iniciar > Execução > PSR.exe > OK ou clique no Windows tecla > **** >PSR.exee pressione ENTER.

  2. Quando a janela PSR.exe pequena for exibida, clique em Iniciar Registro e reproduza as etapas que reproduzem o problema de desempenho. Você pode adicionar comentários conforme necessário, clicando em Adicionar Comentários.

  3. Clique em Parar Registro quando concluir as etapas. Se o problema de desempenho for uma renderização de página, aguarde até que a página seja renderizada antes de interromper a gravação.

  4. Clique em Salvar.

Uma captura de tela do Gravador de Etapas ou PSR.exe.

A data e a hora são gravadas para você. Isso vincula seu PSR ao rastreamento do Netmon e AO HTTPWatch a tempo e ajuda na solução de problemas de precisão. A data e a hora no registro PSR podem mostrar que um minuto passou entre o logon e a navegação da URL e a renderização parcial do site de administração, por exemplo.

Ler seus rastreamentos

Não é possível ensinar tudo sobre a solução de problemas de rede e desempenho que alguém precisaria saber por meio de um artigo. Obter bom desempenho requer experiência e conhecimento de como sua rede funciona e geralmente funciona. Mas é possível arredondar uma lista dos principais problemas e mostrar como as ferramentas podem facilitar a eliminação dos problemas mais comuns.

Se você quiser obter habilidades de leitura de rastreamentos de rede para seus sites do Office 365, não há professor melhor do que criar rastreamentos de carregamentos de página regularmente e obter experiência em lê-los. Por exemplo, quando você tiver uma chance, carregue um serviço Office 365 e rastreie o processo. Filtre o rastreamento para o tráfego DNS ou pesquise o Nome do serviço que você navegueu no FrameData. Examine o rastreamento para ter uma ideia das etapas que ocorrem quando o serviço é carregado. Isso ajudará você a aprender como deve ser a aparência normal da carga de página e, no caso de solução de problemas, especialmente em relação ao desempenho, comparar rastreamentos bons a ruins pode ensinar muito.

O Netmon usa o Microsoft IntelliSense no campo Filtro de exibição. O IntelliSense, ou preenchimento inteligente de código, é aquele truque em que você digita um ponto e todas as opções disponíveis são exibidas em uma caixa de seleção suspensa. Por exemplo, você está preocupado com o dimensionamento de janelaS TCP, você pode encontrar seu caminho para um filtro ( .protocol.tcp.window < 100como) por esse meio.

Captura de tela do Netmon mostrando que o campo Filtro de Exibição usa o IntelliSense.

Rastreamentos netmon podem ter muito tráfego neles. Se você não tiver experiência com a leitura deles, é provável que esteja sobrecarregado ao abrir o rastreamento pela primeira vez. A primeira coisa a fazer é separar o sinal do ruído de fundo no rastreamento. Você testou Office 365, e esse é o tráfego que você deseja ver. Se você estiver acostumado a navegar pelos rastreamentos, talvez não precise dessa lista.

O tráfego entre o cliente e Office 365 viaja por meio do TLS, o que significa que o corpo do tráfego será criptografado e não poderá ser lido em um rastreamento netmon genérico. Sua análise de desempenho não precisa saber as especificações das informações no pacote. No entanto, ele está muito interessado nos cabeçalhos de pacote e nas informações que eles contêm.

Dicas obter um bom rastreamento

  • Conheça o valor do endereço IPv4 ou IPv6 do computador cliente. Você pode obter isso no prompt de comando digitando IPConfig e pressionando ENTER. Saber esse endereço permitirá que você informe rapidamente se o tráfego no rastreamento envolve diretamente o computador cliente. Se houver um proxy conhecido, execute ping nele e obtenha seu endereço IP também.

  • Libere o cache do resolvedor DNS e, se possível, feche todos os navegadores, exceto aquele em que você está executando os testes. Se você não conseguir fazer isso, por exemplo, se o suporte estiver usando alguma ferramenta baseada em navegador para ver a área de trabalho do computador cliente, esteja preparado para filtrar o rastreamento.

  • Em um rastreamento ocupado, localize o Office 365 serviço que você está usando. Se você nunca ou raramente viu seu tráfego antes, essa é uma etapa útil para separar o problema de desempenho de outros ruídos de rede. Há algumas maneiras de fazer isso. Diretamente antes do teste, você pode usar ping ou PsPing na URL do serviço específico (ping outlook.office365.com ou psping -4 microsoft-my.sharepoint.com:443, por exemplo). Você também pode encontrar facilmente esse ping ou PsPing em um rastreamento netmon (pelo nome do processo). Isso lhe dará um lugar para começar a procurar.

Se você estiver usando apenas o rastreamento do Netmon no momento do problema, tudo bem também. Para se orientar, use um filtro como ContainsBin(FrameData, ASCII, "office") ou ContainsBin(FrameData, ASCII, "outlook"). Você pode gravar o número do quadro do arquivo de rastreamento. Você também pode querer rolar o painel Resumo do Quadro até a direita e procurar a coluna ID da Conversa. Há um número indicado lá para a ID dessa conversa específica que você também pode registrar e examinar isoladamente mais tarde. Lembre-se de remover esse filtro antes de aplicar qualquer outra filtragem.

Dica

O Netmon tem muitos filtros internos úteis. Experimente o botão Filtro de Carga na parte superior do painel Filtro de exibição.

Localize seu IP usando PSPing na linha de comando no computador cliente.

Rastreamento netmon do cliente mostrando o mesmo comando PSPing por meio do TCP de filtro. Flags.Syn == 1.

Familiarize-se com o tráfego e saiba como localizar as informações necessárias. Por exemplo, saiba como determinar qual pacote no rastreamento tem a primeira referência ao Office 365 serviço que você está usando (como "Outlook").

Usando Office 365 Outlook Online como exemplo, o tráfego começa algo assim:

  • Consulta Padrão DNS e Resposta DNS para outlook.office365.com com QueryIDs correspondentes. É importante observar o deslocamento de tempo para esse turn-around e onde, no mundo, o DNS global do Office 365 envia a solicitação de resolução de nomes. Idealmente, o mais localmente possível, em vez de no meio do mundo.

  • Uma solicitação HTTP GET cujo relatório de status foi movido permanentemente (301)

  • Tráfego RWS, incluindo solicitações Conexão RWS e Conexão respostas. (Esse é o Winsock remoto que está fazendo uma conexão para você.)

  • Uma conversa TCP SYN e TCP SYN/ACK. Muitas configurações nesta conversa afetam o desempenho.

  • Em seguida, uma série de tráfego TLS:TLS, que é onde ocorrem as conversas de handshake do TLS e do certificado TLS. (Lembre-se de que os dados são criptografados via SSL/TLS.)

Todas as partes do tráfego são importantes e conectadas, mas pequenas partes do rastreamento contêm informações importantes em termos de solução de problemas de desempenho, portanto, vamos nos concentrar nessas áreas. Além disso, como fizemos o suficiente para solucionar problemas de desempenho do Office 365 microsoft para compilar uma lista dos Dez principais problemas comuns, nos concentraremos nesses problemas e em como usar as ferramentas que temos para enraizá-los em seguida.

Se você ainda não as instalou, a matriz abaixo usará várias ferramentas sempre que possível. Os links são fornecidos para os pontos de instalação. A lista inclui ferramentas comuns de rastreamento de rede, como Netmon e Wireshark, mas use qualquer ferramenta de rastreamento com a qual você esteja familiarizado e em que esteja acostumado a filtrar o tráfego de rede. Quando estiver testando, lembre-se:

  • Feche seus navegadores e teste com apenas um navegador em execução – isso reduzirá o tráfego geral capturado. Isso faz com que um rastreamento menos ocupado.
  • Liberar o cache do resolvedor DNS no computador cliente – isso lhe dará um slate limpo quando você começar a fazer a captura, para um rastreamento mais limpo.

Problemas comuns

Alguns problemas comuns que você pode enfrentar e como encontrá-los no rastreamento de rede.

Dimensionamento Windows TCP

Encontrado no SYN – SYN/ACK. O hardware herdado ou antigo pode não aproveitar o dimensionamento de janelas TCP. Sem as configurações de dimensionamento de janelas TCP adequadas, o buffer padrão de 16 bits em cabeçalhos TCP preenche em milissegundos. O tráfego não pode continuar a ser enviado até que o cliente receba uma confirmação de que os dados originais foram recebidos, causando atrasos.

Ferramentas

  • Netmon
  • Wireshark

O que procurar

Procure o tráfego SYN – SYN/ACK no rastreamento de rede. No Netmon, use um filtro como tcp.flags.syn == 1. Esse filtro é o mesmo no Wireshark.

Filtre nos pacotes Netmon ou Wireshark para Syn para ambas as ferramentas: TCP. Flags.Syn == 1.

Observe que, para cada SYN, há um número de porta de origem (SrcPort) que é correspondido na porta de destino (DstPort) da confirmação relacionada (SYN/ACK).

Para ver o Windows de dimensionamento que é usado pela conexão de rede, expanda primeiro o SYN e, em seguida, o SYN/ACK relacionado.

Gráfico que mostra como corresponder SrcPort a DstPort em um rastreamento para obter o delta de tempo.

Tempo de ociosidade do TCP Configurações

Historicamente, a maioria das redes de perímetro é configurada para conexões transitórias, o que significa que as conexões ociosas geralmente são encerradas. As sessões TCP ociosas podem ser encerradas por proxies e firewalls com mais de 100 a 300 segundos. Isso é problemático para o Outlook Online porque ele cria e usa conexões de longo prazo, independentemente de elas estiverem ociosas ou não.

Quando as conexões são encerradas por dispositivos proxy ou firewall, o cliente não é informado e uma tentativa de usar o Outlook Online significará que um computador cliente tentará, repetidamente, reavivar a conexão antes de fazer uma nova. Você pode ver travamentos no produto, prompts ou desempenho lento no carregamento da página.

Ferramentas

  • Netmon
  • Wireshark

O que procurar

No Netmon, examine o campo Deslocamento de Tempo para uma viagem de ida e volta. Uma viagem de ida e volta é o tempo entre o cliente enviar uma solicitação para o servidor e receber uma resposta de volta. Verifique entre o Cliente e o ponto de saída (por exemplo, Cliente –> Proxy) ou o cliente a Office 365 (Cliente –> Office 365). Você pode ver isso em vários tipos de pacotes.

Por exemplo, o filtro no Netmon pode ser semelhante .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12ou, no Wireshark, ip.addr == 10.102.14.112 &amp;&amp; ip.addr == 10.201.114.12.

Dica

Não sabe se o endereço IP no rastreamento pertence ao servidor DNS? Tente procurá-lo na linha de comando. Clique em > Iniciar Execução > e digite cmd ou pressione Windows Tecla e > digite cmd. No prompt, digite nslookup <the IP address from the network trace>. Para testar, use nslookup no endereço IP do seu próprio computador. > para ver uma lista dos intervalos de IP da Microsoft, consulte Office 365 URLs e intervalos de endereços IP.

Se houver um problema, espere que deslocamentos de tempo longos apareçam, nesse caso (Outlook Online), especialmente em pacotes TLS:TLS que mostram a passagem de Dados do Aplicativo (por exemplo, no Netmon, você pode encontrar pacotes de dados do aplicativo por meio .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"de ). Você deverá ver uma progressão suave no tempo em toda a sessão. Se você vir longos atrasos ao atualizar seu Outlook Online, isso pode ser causado por um alto grau de redefinições que estão sendo enviadas.

Latência/Tempo de ida e volta

A latência é uma medida que pode mudar muito dependendo de muitas variáveis, como a atualização de dispositivos de envelhecimento, a adição de um grande número de usuários a uma rede e a porcentagem de largura de banda geral consumida por outras tarefas em uma conexão de rede.

Há calculadoras de largura de banda para Office 365 disponíveis neste planejamento de rede e ajuste de desempenho para Office 365 página.

Precisa medir a velocidade da conexão ou a largura de banda da conexão ISP? Experimente este site (ou sites como ele): agilize o Site Oficial ou consulte seu mecanismo de pesquisa favorito para o teste de velocidade de frase.

Ferramentas

  • Ping
  • PsPing
  • Netmon
  • Wireshark

O que procurar

Para acompanhar a latência em um rastreamento, você se beneficiará de ter registrado o endereço IP do computador cliente e o endereço IP do servidor DNS no Office 365. Isso é para filtragem de rastreamento mais fácil. Se você se conectar por meio de um proxy, precisará do endereço IP do computador cliente, do endereço IP de proxy/saída e do endereço IP Office 365 DNS para facilitar o trabalho.

Uma solicitação de ping enviada outlook.office365.com informará o nome do datacenter que está recebendo a solicitação, mesmo que o ping possa não ser capaz de se conectar para enviar os pacotes ICMP consecutivos da marca. Se você usar PsPing (uma ferramenta gratuita para download) e especificar a porta (443) e talvez usar IPv4 (-4), você obterá um tempo médio de viagem de ida e volta para pacotes enviados. Isso funcionará para outras URLs nos serviços Office 365, como psping -4 yourSite.sharepoint.com:443. Na verdade, você pode especificar um número de pings para obter uma amostra maior para sua média, tente algo como psping -4 -n 20 yourSite-my.sharepoint.com:443.

Observação

O PsPing não envia pacotes ICMP. Ele executa pings com pacotes TCP em uma porta específica, para que você possa usar qualquer um que saiba estar aberto. No Office 365, que usa SSL/TLS, tente anexar a porta :443 ao seu PsPing.

Captura de tela que mostra um ping resolvendo outlook.office365.com e um PSPing com o 443 fazendo o mesmo, mas também relatando uma RTT média de 6,5 ms.

Se você carregou a página de Office 365 ao fazer um rastreamento de rede, deverá filtrar um rastreamento netmon ou Wireshark para DNS. Este é um dos IPs que estamos procurando.

Aqui estão as etapas a serem seguidas para filtrar o Netmon para obter o endereço IP (e dar uma olhada na Latência de DNS). Este exemplo usa outlook.office365.com, mas também pode usar a URL de um locatário SharePoint Online (hithere.sharepoint.com por exemplo).

  1. Execute ping na URL ping outlook.office365.com e, nos resultados, registre o nome e o endereço IP do servidor DNS para o qual a solicitação de ping foi enviada.
  2. Rastreamento de rede abrindo a página ou executando a ação que oferece o problema de desempenho ou, se você vir uma alta latência no ping, em si, rastreie-o.
  3. Abra o rastreamento no Netmon e filtre por DNS (esse filtro também funciona no Wireshark, mas é sensível a maiúsculas e minúsculas -- dns). Como você sabe o nome do servidor DNS do seu ping, você também pode filtrar mais rapidamente no Netmon da seguinte forma: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), que se parece com isso no dns do Wireshark e o quadro contém "namnorthwest".
    Abra o pacote de resposta e, na janela Detalhes do Quadro do Netmon, clique em DNS para expandir para obter mais informações. Nas informações de DNS, você encontrará o endereço IP do servidor DNS para o qual a solicitação foi Office 365. Você precisará desse endereço IP para a próxima etapa (a ferramenta PsPing). Remova o filtro e clique com o botão direito do mouse na Resposta DNS no Netmon ( > > DNS de Localização de Conversas do Resumo do Quadro) para ver a Consulta DNS e a Resposta lado a lado.
  4. No Netmon, observe também a coluna Deslocamento de Tempo entre a Solicitação e a Resposta dns. Na próxima etapa, a ferramenta PsPing fácil de instalar e usar é muito útil, pois o ICMP geralmente é bloqueado em Firewalls e porque o PsPing rastreia elegantemente a latência em milissegundos. O PsPing conclui uma conexão TCP com um endereço e uma porta (em nosso caso, abra a porta 443).
  5. Instale o PsPing.
  6. Abra um prompt de comando (> > cmd do tipo Iniciar Execução ou cmd do tipo chave Windows>) e altere o diretório para o diretório em que você instalou o PsPing para executar o comando PsPing. Nos meus exemplos, você pode ver que fiz uma pasta 'Perf' na raiz de C. Você pode fazer o mesmo para acesso rápido.
  7. Digite o comando para que você esteja fazendo seu PsPing no endereço IP do servidor DNS do Office 365 do rastreamento anterior do Netmon, incluindo o número da porta, como psping -n 20 132.245.24.82:445. Isso fornecerá uma amostragem de 20 pings e a latência média quando o PsPing for interrompido.

Se você for percorrer Office 365 um servidor proxy, as etapas serão um pouco diferentes. Primeiro, psPing para o servidor proxy para obter um valor médio de latência em milissegundos para proxy/saída e, em seguida, executar PsPing no proxy ou em um computador com uma conexão direta com a Internet para obter o valor ausente (aquele para Office 365 e voltar).

Se você optar por executar o PsPing do proxy, terá dois valores de milissegundos: computador cliente para servidor proxy ou ponto de saída e servidor proxy para Office 365. E pronto! Bem, gravando valores, de qualquer maneira.

Se você executar o PsPing em outro computador cliente que tenha uma conexão direta com a Internet, ou seja, sem um proxy, terá dois valores de milissegundos: computador cliente para servidor proxy ou ponto de saída e computador cliente para Office 365. Nesse caso, subtraia o valor do computador cliente para o servidor proxy ou ponto de saída do valor do computador cliente para o Office 365, e você terá os números RTT do computador cliente para o servidor proxy ou ponto de saída e do servidor proxy ou ponto de saída para Office 365.

No entanto, se você puder encontrar um computador cliente no local afetado que está conectado diretamente ou ignorar o proxy, poderá optar por ver se o problema se reproduz lá para começar e testá-lo posteriormente.

A latência, como visto em um rastreamento do Netmon, esses milissegundos extras podem ser adicionados, se houver o suficiente deles em qualquer sessão específica.

Latência geral no Netmon, com a coluna de Intervalo de Tempo padrão do Netmon adicionada ao Resumo do Quadro.

Observação

Seu endereço IP pode ser diferente dos IPs mostrados aqui, por exemplo, seu ping pode retornar algo mais parecido com 157.56.0.0/16 ou um intervalo semelhante. Para obter uma lista de intervalos usados pelo Office 365, confira Office 365 URLs e intervalos de endereços IP.

Lembre-se de expandir todos os nós (há um botão na parte superior para isso) se você quiser pesquisar, por exemplo, 132.245.

Autenticação de proxy

Isso só se aplica a você se você estiver passando por um servidor proxy. Caso contrário, você pode ignorar essas etapas. Ao trabalhar corretamente, a autenticação de proxy deve ocorrer em milissegundos, de forma consistente. Você não deve ver um desempenho ruim intermitente durante períodos de uso de pico (por exemplo).

Se a autenticação de proxy estiver ativada, sempre que você fizer uma nova conexão TCP com Office 365 obter informações, precisará passar por um processo de autenticação nos bastidores. Portanto, por exemplo, ao alternar de Calendário para Email no Outlook Online, você se autenticará. E no SharePoint Online, se uma página exibir mídia ou dados de vários sites ou locais, você se autenticará para cada conexão TCP diferente necessária para renderizar os dados.

No Outlook Online, você pode experimentar tempos de carregamento lentos sempre que alternar entre o Calendário e sua caixa de correio ou carregamentos de página lentos no SharePoint Online. No entanto, há outros sintomas não listados aqui.

A autenticação de proxy é uma configuração no servidor proxy de saída. Se estiver causando um problema de desempenho com Office 365, você deverá consultar sua equipe de rede.

Ferramentas

  • Netmon
  • Wireshark

O que procurar

A autenticação de proxy ocorre sempre que uma nova sessão TCP deve ser criada, normalmente para solicitar arquivos ou informações do servidor ou para fornecer informações. Por exemplo, você pode ver a autenticação de proxy em torno de solicitações HTTP GET ou HTTP POST. Se você quiser ver os quadros em que está autenticando solicitações em seu rastreamento, adicione a coluna 'Resumo de NTLMSSP' ao Netmon e filtre .property.NTLMSSPSummarypor . Para ver quanto tempo a autenticação está demorando, adicione a coluna Delta de Tempo.

Para adicionar uma coluna ao Netmon:

  1. Clique com o botão direito do mouse em uma coluna, como Descrição.
  2. Clique em Escolher Colunas.
  3. Localize o Resumo do NTLMSSP e o Delta de Tempo na lista e clique em Adicionar.
  4. Mova as novas colunas para o lugar antes ou para trás da coluna Descrição para que você possa lê-las lado a lado.
  5. Clique em OK.

Mesmo que você não adicione a coluna, o filtro Netmon funcionará. Mas sua solução de problemas será muito mais fácil se você puder ver em qual estágio de autenticação você está.

Ao procurar instâncias de Autenticação de Proxy, lembre-se de estudar todos os quadros em que há um Desafio NTLM ou uma Mensagem de Autenticação está presente. Se necessário, clique com o botão direito do mouse na parte específica do tráfego e localize o TCP de > Conversas. Lembre-se dos valores de Delta de Tempo nessas Conversas.

Rastreamento do Netmon mostrando a autenticação de proxy, filtrada por conversa.

Um atraso de quatro segundos na autenticação de proxy, conforme visto no Wireshark. O delta De hora da coluna de quadro exibida anteriormente foi feito clicando com o botão direito do mouse no campo de mesmo nome nos detalhes do quadro e selecionando Adicionar como Coluna.
No Wireshark, a coluna "Delta de tempo do quadro exibido anterior" pode ser feita clicando com o botão direito do mouse no campo de mesmo nome nos detalhes do quadro e selecionando Adicionar como Coluna.

Desempenho de DNS

A resolução de nomes funciona melhor e mais rapidamente quando ocorre o mais próximo possível do país do cliente.

Se a resolução de nomes DNS estiver ocorrendo no exterior, ela poderá adicionar segundos aos carregamentos de página. O ideal é que a resolução de nomes ocorra em menos de 100 ms. Caso contrário, você deve fazer uma investigação adicional.

Dica

Não tem certeza de como a conectividade do cliente funciona Office 365? Dê uma olhada no documento referência de conectividade do cliente aqui.

Ferramentas

  • Netmon
  • Wireshark
  • PsPing

O que procurar

A análise do desempenho de DNS normalmente é outro trabalho para um rastreamento de rede. No entanto, o PsPing também é útil para decidir dentro ou fora uma possível causa.

O tráfego DNS é baseado em solicitações TCP e UDP e as respostas são claramente marcadas com uma ID que ajudará a corresponder uma solicitação específica com sua resposta específica. Você verá o tráfego DNS quando, por exemplo, o SharePoint Online usa um nome de rede ou URL em uma página da Web. Como regra geral, a maior parte desse tráfego, exceto ao transferir zonas, é executada por UDP.

No Netmon e no Wireshark, o filtro mais básico que permitirá que você examine o tráfego DNS é simplesmente dns. Certifique-se de usar letras minúsculas ao especificar o filtro. Lembre-se de liberar o cache do resolvedor DNS antes de começar a reproduzir o problema no computador cliente. Por exemplo, se você tiver uma carga de página do SharePoint Online lenta para a home page, feche todos os navegadores, abra um novo navegador, inicie o rastreamento, libere o cache do resolvedor dns e navegue até o site do SharePoint Online. Depois que a página inteira for resolvida, você deverá parar e salvar o rastreamento.

No Netmon, um filtro básico para DNS é DNS.

Você quer examinar o deslocamento de tempo aqui. E pode ser útil adicionar a coluna Delta de Tempo ao Netmon, o que você pode fazer concluindo estas etapas:

  1. Clique com o botão direito do mouse em uma coluna, como Descrição.
  2. Clique em Escolher Colunas.
  3. Localize o Delta de Tempo na lista e clique em Adicionar.
  4. Mova a nova coluna para o local antes ou para trás da coluna Descrição para que você possa lê-la lado a lado.
  5. Clique em OK.

Se você encontrar uma consulta de interesse, considere isola-la clicando com o botão direito do mouse nessa consulta no painel de detalhes do quadro, escolhendo Localizar DNS de Conversas>. Observe que o painel Conversas de Rede vai direto para a conversa específica em seu log de tráfego UDP.

Um rastreamento netmon de Outlook online filtrado por DNS e usando Localizar Conversas e DNS para restringir os resultados.

No Wireshark, você pode criar uma coluna para o horário DNS. Faça o rastreamento (ou abra um rastreamento) no Wireshark e filtre dnspor, ou, mais útilmente, dns.time. Clique em qualquer consulta DNS e, no painel mostrando detalhes, expanda os Domain Name System (response) detalhes. Você verá um campo por tempo (por exemplo, [Time: 0.001111100 seconds]. Clique com o botão direito do mouse desta vez e selecione Aplicar como Coluna. Isso lhe dará uma coluna Hora para classificação mais rápida do rastreamento. Clique na nova coluna para classificar por valores decrescentes para ver qual chamada DNS levou mais tempo para ser resolvida.

Uma procura do SharePoint Online filtrada no Wireshark por dns.time (minúsculas), com o tempo dos detalhes transformado em uma coluna e classificado em ordem crescente.

Se você quiser fazer mais investigação do tempo de resolução dns, tente um PsPing em relação à porta DNS usada pelo TCP (por exemplo, psping <IP address of DNS server>:53) . Você ainda vê um problema de desempenho? Se você fizer isso, é mais provável que o problema seja um problema de rede mais amplo do que um problema específico do aplicativo DNS que você está atingindo para fazer a resolução. Também vale a pena mencionar, novamente, que um ping para outlook.office365.com informará onde a resolução de nome DNS para o Outlook Online está ocorrendo (por exemplo, outlook-namnorthwest.office365.com).

Se o problema parece ser específico do DNS, talvez seja necessário entrar em contato com o departamento de TI para examinar as configurações de DNS e os Encaminhadores de DNS para investigar ainda mais esse problema.

Escalabilidade de proxy

Serviços como Outlook Online em Office 365 conceder aos clientes várias conexões de longo prazo. Portanto, cada usuário pode usar mais conexões que exigem uma vida mais longa.

Ferramentas

Matemática

O que procurar

Não há nenhum rastreamento de rede ou ferramenta de solução de problemas específica para isso. Em vez disso, ele se baseia em cálculos de largura de banda, considerando limitações e outras variáveis.

Tamanho máximo do segmento TCP

Encontrado no SYN – SYN/ACK. Faça essa verificação em qualquer rastreamento de rede de desempenho que você tenha feito para garantir que os pacotes TCP estejam configurados para transportar a quantidade máxima de dados possível.

A meta é ver uma MSS de 1460 bytes para transmissão de dados. Se você estiver atrás de um proxy ou estiver usando um NAT, lembre-se de executar esse teste do cliente para proxy/saída/NAT e de proxy/saída/NAT para Office 365 para obter melhores resultados! Essas são sessões TCP diferentes.

Ferramentas

Netmon

O que procurar

O MSS (Tamanho Máximo de Segmento) do TCP é outro parâmetro do handshake de três vias no rastreamento de rede, o que significa que você encontrará os dados necessários no pacote SYN - SYN/ACK. MSS é realmente muito simples de ver.

Abra qualquer rastreamento de rede de desempenho que você tenha e localize a conexão sobre a qual está curioso ou que demonstre o problema de desempenho.

Observação

Se você estiver examinando um rastreamento e precisar localizar o tráfego relevante para sua conversa, filtre pelo IP do Cliente, pelo IP do servidor proxy ou pelo ponto de saída ou ambos. Indo diretamente, você precisará executar ping na URL que está testando para o endereço IP Office 365 no rastreamento e filtre por ela.

Olhando para o rastreamento de segunda mão? Tente usar filtros para se orientar. No Netmon, execute uma pesquisa com base na URL, como Containsbin(framedata, ascii, "sphybridExample"), anote o número do quadro.

No Wireshark, use algo como frame contains "sphybridExample". Se você observar que encontrou o tráfego RWS (Remote Winsock) (ele pode aparecer como um [PSH, ACK] no Wireshark), lembre-se de que as conexões RWS podem ser vistas pouco antes de SYN – SYN/ACKs relevantes, conforme discutido anteriormente.

Neste ponto, você pode gravar o número do quadro, remover o filtro, clicar em Todo o Tráfego na janela Conversas de Rede no Netmon para examinar o SYN mais próximo.

Importante, se você não recebeu nenhuma das informações de endereço IP no momento do rastreamento, localizar sua URL no rastreamento ( sphybridExample-my.sharepoint.comparte de, por exemplo), fornecerá endereços IP pelos qual filtrar.

Localize a conexão no rastreamento que você está interessado em ver. Você pode fazer isso examinando o rastreamento, filtrando por endereços IP ou selecionando IDs de Conversa específicas usando a janela Conversas de Rede no Netmon. Depois de encontrar o pacote SYN, expanda o TCP (no Netmon) ou o Protocolo de Controle de Transmissão (no Wireshark) no painel Detalhes do Quadro. Expanda opções de TCP e MaxSegmentSize. Localize o quadro SYN-ACK relacionado e expanda opções TCP e MaxSegmentSize. O menor dos dois valores será o tamanho máximo do segmento. Nesta imagem, faço uso da Coluna interna no Netmon chamada TCP Troubleshoot.

Rastreamento de rede filtrado no Netmon usando as colunas internas.

A coluna interna está na parte superior do painel Detalhes do Quadro. (Para voltar ao modo de exibição normal, clique em Colunas novamente e escolha Fuso Horário.)

Onde encontrar a lista suspensa Colunas para a opção Solução de Problemas de TCP (na parte superior do Resumo do Quadro).

Aqui está um rastreamento filtrado no Wireshark. Há um filtro específico para o valor do MSS (tcp.options.mss). Os quadros de um handshake SYN, SYN/ACK e ACK são vinculados na parte inferior do Wireshark equivalente a Frame Details (portanto, o quadro 47 ACK, links para 46 SYN/ACK, links para 43 SYN) para facilitar esse tipo de trabalho.

Rastreamento filtrado no Wireshark por tcp.options.mss para MSS (Tamanho Máximo de Segmento).

Se você precisar verificar a Confirmação Seletiva (próximo tópico nesta matriz), não feche o rastreamento!

Confirmação Seletiva

Encontrado no SYN – SYN/ACK. Deve ser relatado como Permitido em SYN e SYN/ACK. A SACK (Confirmação Seletiva) permite uma retransmissão mais suave de dados quando um pacote ou pacotes estão ausentes. Os dispositivos podem desabilitar esse recurso, o que pode levar a problemas de desempenho.

Se você estiver atrás de um proxy ou estiver usando um NAT, lembre-se de executar esse teste do cliente para proxy/saída/NAT e de proxy/saída/NAT para Office 365 para obter melhores resultados! Essas são sessões TCP diferentes.

Ferramentas

Netmon

O que procurar

A CONFIRMAÇÃO Seletiva (SACK) é outro parâmetro no handshake SYN-SYN/ACK. Você pode filtrar seu rastreamento para SYN – SYN/ACK de várias maneiras.

Localize a conexão no rastreamento que você está interessado em ver verificando o rastreamento, filtrando por endereços IP ou clicando em uma ID de Conversa usando a janela Conversas de Rede no Netmon. Depois de encontrar o pacote SYN, expanda o TCP no Netmon ou o Protocolo de Controle de Transmissão no Wireshark na seção Detalhes do Quadro. Expanda opções de TCP e, em seguida, SACK. Localize o quadro SYN-ACK relacionado e expanda opções TCP e seu campo SACK. Verifique se o SACK é permitido no SYN e no SYN/ACK. Aqui estão os valores SACK, como visto no Netmon e no Wireshark.

Reconhecimento Seletivo (SACK) no Netmon como resultado de tcp.flags.syn == 1.

SACK como visto no Wireshark com o filtro tcp.flags.syn == 1.

Geolocalização dns

Em que no mundo Office 365 tentar resolver sua chamada DNS afeta a velocidade da conexão.

No Outlook Online, depois que a primeira pesquisa de DNS for concluída, o local desse DNS será usado para se conectar ao datacenter mais próximo. Você será conectado a um servidor CAS do Outlook Online, que usará a rede de backbone para se conectar ao datacenter (dC) em que os dados estão armazenados. Isso é mais rápido.

Ao acessar o SharePoint Online, um usuário que estiver viajando para o exterior será direcionado para seu datacenter ativo – esse é o dC cuja localização é baseada na base inicial do locatário do SPO (portanto, um dC nos EUA se o usuário se basear nos EUA).

O Lync online tem nós ativos em mais de um dC por vez. Quando as solicitações são enviadas para instâncias online do Lync, o DNS da Microsoft determinará de onde veio a solicitação e retornará endereços IP do dC regional mais próximo em que o Lync online está ativo.

Dica

Precisa saber mais sobre como os clientes se conectam ao Office 365? Dê uma olhada no artigo de referência de Conectividade do Cliente (e seus gráficos úteis).

Ferramentas

  • Ping
  • PsPing

O que procurar

As solicitações de resolução de nomes dos servidores DNS do cliente para os servidores DNS da Microsoft devem, na maioria dos casos, resultar em DNS da Microsoft retornando o endereço IP de um datacenter regional (dC). O que isso significa para você? Se sua sede estiver em Bangalore, índia, mas você estiver viajando no Estados Unidos, quando o navegador fizer uma solicitação para o Outlook Online, os servidores DNS da Microsoft deverão entregar endereços IP para datacenters no Estados Unidos , um datacenter regional. Se o email for necessário Outlook dados, esses dados percorrerão a rede de backbone rápida da Microsoft entre os datacenters.

O DNS funciona mais rapidamente quando a resolução de nomes é feita o mais próximo possível do local do usuário. Se estiver na Europa, você deseja ir para um DNS da Microsoft na Europa e (idealmente) lidar com um datacenter na Europa. O desempenho de um cliente na Europa que vai para o DNS e um datacenter na América será mais lento.

Execute a ferramenta Ping em outlook.office365.com para determinar para onde no mundo sua solicitação DNS está sendo roteada. Se você estiver na Europa, deverá ver uma resposta de algo como outlook-emeawest.office365.com. Nas Américas, espere algo como outlook-namnorthwest.office365.com.

Abra o prompt de comando no computador cliente (por meio do cmd Start > Run > ou Windows tipo de > chave cmd). Digite ping outlook.office365.com e pressione ENTER. Lembre-se de especificar -4 se você quiser especificar o ping via IPv4. Talvez você não receba uma resposta dos pacotes ICMP, mas deverá ver o nome do DNS para o qual a solicitação foi roteada. Se você quiser ver os números de latência para essa conexão, tente PsPing para o endereço IP do servidor retornado pelo ping.

Ping de outlook.office365.com mostrando a resolução em outlook-namnorthwest.

PSPing para o endereço IP retornado pelo ping para outlook.office365.com com latência média de 28 milissegundos.

Office 365 solução de problemas do aplicativo

Ferramentas

  • Netmon
  • HTTPWatch
  • Console F12 no navegador

Não abordamos as ferramentas usadas na solução de problemas específica do aplicativo neste artigo específico da rede. Mas você encontrará recursos que pode usar nesta página.

Gerenciar pontos de extremidade do Office 365

Perguntas frequentes sobre pontos de extremidade do Office 365