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

Você precisa saber as etapas a serem tomadas para identificar e corrigir atrasos, travas e desempenho lento entre SharePoint, OneDrive, Exchange Online ou Skype for Business Online e seu computador cliente? Antes de chamar o suporte, este artigo pode ajudá-lo a solucionar problemas de desempenho Office 365 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 à medida que ele está acontecendo. Alguns dos principais problemas também estão incluídos neste artigo.

Se você é novo no desempenho da rede e deseja fazer um plano de longo prazo para monitorar o desempenho entre seus computadores cliente e Office 365, dê uma olhada em Office 365 ajuste de desempenho e solução de problemas - Administração e IT Pro.

Plano de ação de solução de problemas de desempenho de exemplo

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 agora e precisar fazer a coleta de dados, poderá começar a usar esse plano imediatamente.

Preparar o computador cliente

• Encontre um computador cliente que possa reproduzir o problema de desempenho. Este computador será usado durante a solução de problemas.
• Anote as etapas que causam o problema de desempenho para que você esteja pronto na hora de testar.
• Instalar ferramentas para coletar e registrar 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, a fim de manter um registro das etapas que você executa durante o teste.

Registrar o problema de desempenho

• Feche todos os navegadores de Internet extraneous.

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

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

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

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

• Opcional: se você estiver testando Exchange Online, execute a ferramenta Performance Analyzer do Cliente do Exchange no console de administração Office 365.

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

• Pare 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 bom ou ruim desempenho.

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

Se você não estiver familiarizado com a execução das ferramentas mencionadas neste artigo, não se preocupe porque fornecemos essas etapas a seguir. Se você estiver acostumado a fazer esse tipo de captura de rede, poderá ignorar como coletar linhas de base, o que descreve filtragem e leitura dos logs.

Primeiro, libere o Cache DNS

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

Liberar seu cache de resolver DNS

1. Abra o prompt de comando (cmd iniciar>execução> oucmdda chave> do Windows).

2. Digite o comando a seguir e pressione ENTER:

   ipconfig /flushdns
   

Netmon

A Ferramenta de Monitoramento de Rede (Netmon) da Microsoft analisa pacotes (tráfego de rede) que passam entre computadores em redes. Usando o Netmon para rastrear o tráfego com Office 365 você pode capturar, exibir e ler cabeçalhos de pacotes, identificar dispositivos intervindo, marcar 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 parar o rastreamento e salvar.

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

Faça um rastreamento do Netmon e reproduza o problema

1. Inicie o Netmon 3.4. Há três painéis na página Iniciar: 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. Certifique-se de que os cartões de rede estão selecionados aqui.

2. Clique em Nova Captura na parte superior da página Iniciar . Isso adiciona uma nova guia ao lado da guia Página Iniciar chamada Captura 1.

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>Salvar arquivo>como. Lembre-se de dar a data e hora com o fuso horário e menção se ele demonstrar desempenho ruim ou bom.

HTTPWatch

HTTPWatch é cobrado e uma edição gratuita. A Edição Básica gratuita aborda tudo o que você precisa para este teste. O HTTPWatch monitora o tráfego de rede e o tempo de carga da página diretamente da janela do navegador. HTTPWatch é um plug-in no Microsoft Edge 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 Edge, abra uma nova janela do navegador e pressione F12 no teclado. Você deve ver o pop-up da Ferramenta de Desenvolvedor na parte inferior do navegador. Se você usar Opera, pressione CTRL+SHIFT+I para Inspetor Web, clique na guia Rede e conclua o teste descrito abaixo. As informações serão ligeiramente diferentes, mas os tempos de carga ainda serão exibidos em milissegundos. > HTTPWatch também é muito útil para problemas com os tempos de carga da página do SharePoint.

Executar HTTPWatch e reproduzir o problema

HTTPWatch é um plug-in do navegador, portanto, expor a ferramenta no navegador é um pouco diferente para cada versão do Microsoft Edge. Normalmente, você pode encontrar HTTPWatch na barra Comandos no navegador do Microsoft Edge. Se você não vir o plug-in HTTPWatch na janela do navegador, marcar a versão do navegador clicando em Help>About ou em versões posteriores do Microsoft Edge, clique no símbolo de engrenagem e no About Edge. Para iniciar a barra Comandos , clique com o botão direito do mouse na barra de menus no Microsoft Edge e clique na barra Comandos.

No passado, o HTTPWatch foi associado aos Comandos e às barras Explorer, portanto, depois de instalar, se você não vir imediatamente o ícone (mesmo após a reinicialização) marcar 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.

1. Inicie HTTPWatch em uma janela do navegador do Microsoft Edge. Ele aparece 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 Enviar por Email. Lembre-se de nomear o arquivo para que ele inclua informações de data e hora e uma indicação de se o relógio contém uma demonstração de bom ou mau desempenho.

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

Gravador de Etapas de Problema

O Gravador de Etapas ou PSR.exe permite que você registre problemas conforme eles estão ocorrendo. É uma ferramenta muito útil e simples de ser executada.

Executar gravador de etapas de problemas (PSR.exe) para gravar seu trabalho

1. Use o tipo Iniciar>Execução>>PSR.exeOK ou clique no tipo chave do Windows>PSR.exe> e pressione ENTER.

2. Quando a pequena janela PSR.exe 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 a renderização da página antes de interromper a gravação.

4. Clique em Salvar.

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 a entrada 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 solução de problemas de rede e desempenho que alguém precisaria saber por meio de um artigo. Obter um bom desempenho requer experiência e conhecimento de como sua rede funciona e geralmente funciona. Mas é possível reunir uma lista dos principais problemas e mostrar como as ferramentas podem facilitar a eliminação dos problemas mais comuns.

Se você quiser obter habilidades lendo rastreamentos de rede para seus sites Office 365, não há professor melhor do que criar rastreamentos de cargas de página regularmente e obter experiência lendo-os. Por exemplo, quando você tiver uma chance, carregue um serviço Office 365 e rastreie o processo. Filtre o rastreamento do tráfego DNS ou pesquise no FrameData o nome do serviço que você navegou. Examine o rastreamento para ter uma ideia das etapas que ocorrem quando o serviço é carregado. Isso ajuda você a aprender como deve ser a carga de página normal e, no caso de solução de problemas, especialmente em torno do desempenho, comparar traços bons e ruins pode ensiná-lo muito.

O Netmon usa o Microsoft Intellisense no campo Filtro de exibição. O Intelisense, ou conclusão inteligente de código, é aquele truque em que você digita em um período 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 da janela TCP, você pode encontrar seu caminho para um filtro (como .protocol.tcp.window < 100) por esse meio.

Os rastreamentos de netmon podem ter muito tráfego neles. Se você não tiver experiência em lê-los, é provável que você fique sobrecarregado abrindo o rastreamento pela primeira vez. A primeira coisa a fazer é separar o sinal do ruído de fundo no rastreamento. Você testou contra Office 365, e esse é o tráfego que você deseja ver. Se você estiver acostumado a navegar por rastreamentos, talvez não precise desta lista.

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

Dicas para obter um bom rastreamento

• Saiba o valor do endereço IPv4 ou IPv6 do computador cliente. Você pode obter isso no prompt de comando digitando IPConfig e pressionando ENTER. Conhecer esse endereço permite que você conte rapidamente se o tráfego no rastreamento envolve diretamente o computador cliente. Se houver um proxy conhecido, pinge-o e obtenha seu endereço IP também.

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

• Em um rastreamento ocupado, localize o serviço Office 365 que você está usando. Se você nunca ou raramente viu seu tráfego antes, esta é 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 orientar a si mesmo, use um filtro como ContainsBin(FrameData, ASCII, "office") ou ContainsBin(FrameData, ASCII, "outlook"). Você pode registrar o número do quadro do arquivo de rastreamento. Você também pode querer rolar o painel Resumo de Quadros até a direita e procurar a coluna ID da conversa. Há um número indicado para a ID dessa conversa específica que você também pode gravar 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 Exibir filtro.

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

Tomando 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 essa reviravolta e onde no mundo o Office 365 DNS global envia a solicitação de resolução de nomes. Idealmente, o mais localmente possível, em vez de metade do mundo.

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

• Tráfego RWS, incluindo solicitações do RWS Connect e respostas do Connect. (Este é o Winsock Remoto fazendo uma conexão para você.)

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

• Em seguida, uma série de tráfego TLS:TLS, que é onde o aperto de mão TLS e conversas de certificado TLS ocorrem. (Lembre-se de que os dados são criptografados por meio do 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, nos concentraremos nessas áreas. Além disso, como já fizemos o suficiente Office 365 solução de problemas de desempenho na Microsoft para compilar uma lista top 10 de problemas comuns, nos concentraremos nesses problemas e em como usar as ferramentas que temos para eligá-los em seguida.

Se você ainda não os instalou, a matriz abaixo usará várias ferramentas sempre que possível. Os links são fornecidos aos 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 confortável e na qual você está 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 que você captura. Faz um rastreamento menos ocupado.
• Libere seu cache de resolvedor DNS no computador cliente – isso lhe dará uma lista de limpo quando você começar a fazer a captura para obter um rastreamento mais limpo.

Problemas comuns

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

Dimensionamento do Windows TCP

Encontrado no SYN – SYN/ACK. Hardware herdado ou envelhecido pode não aproveitar o dimensionamento de janelas TCP. Sem configurações de dimensionamento de janelas TCP adequadas, o buffer padrão de 16 bits em cabeçalhos TCP preenche milissegundos. O tráfego não pode continuar a ser enviado até que o cliente receba um reconhecimento 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 em Wireshark.

Observe que para cada SYN há um número de porta de origem (SrcPort) que é correspondido na porta de destino (DstPort) do SYN/ACK (reconhecimento relacionado).

Para ver o valor do Dimensionamento do Windows usado pela conexão de rede, expanda primeiro o SYN e, em seguida, o SYN/ACK relacionado.

Configurações de tempo ocioso do TCP

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. Sessões TCP ociosas podem ser encerradas por proxies e firewalls em mais de 100 a 300 segundos. Isso é problemático para o Outlook Online porque ele cria e usa conexões de longo prazo, sejam elas 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, reviver a conexão antes de fazer uma nova. Você pode ver travas no produto, prompts ou desempenho lento na carga da página.

Ferramentas

• Netmon
• Wireshark

O que procurar

Em Netmon, veja o campo Deslocamento de Tempo para uma viagem de ida e volta. Uma 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 (ex. Cliente --> Proxy) ou o Cliente para Office 365 (Cliente --> Office 365). Você pode ver isso em muitos tipos de pacotes.

Como exemplo, o filtro no Netmon pode se parecer .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12com , ou, em Wireshark, ip.addr == 10.102.14.112 && 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>Executar> e digite cmd ou pressione Tecla> do Windows 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 de Aplicativo (por exemplo, no Netmon você pode encontrar pacotes de dados de aplicativo por meio .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Você deve ver uma progressão suave no tempo ao longo da 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 viagem de ida e volta

Latência é uma medida que pode mudar muito dependendo de muitas variáveis, como atualizar dispositivos antigos, adicionar um grande número de usuários a uma rede e o percentual 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 nesta página planejamento de rede e 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): Site Oficial do Speedtest ou consulte seu mecanismo de pesquisa favorito para o teste de velocidade da frase.

Ferramentas

• Ping
• PsPing
• Netmon
• Wireshark

O que procurar

Para controlar a latência em um rastreamento, você se beneficiará de ter gravado 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 DNS Office 365 para facilitar o trabalho.

Uma solicitação de ping enviada para outlook.office365.com informará o nome do datacenter que recebe a solicitação, mesmo que o ping não seja capaz de se conectar para enviar os pacotes ICMP consecutivos da marca. Se você usar o PsPing (uma ferramenta gratuita para download) e especificar a porta (443) e talvez usar o IPv4 (-4) você terá uma média de tempo de ida e volta para pacotes enviados. Isso funcionará para outras URLs nos serviços de Office 365, como psping -4 yourSite.sharepoint.com:443. Na verdade, você pode especificar uma série 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 pinga com pacotes TCP em uma porta específica, para que você possa usar qualquer um que você saiba estar aberto. Em Office 365, que usa SSL/TLS, tente anexar a porta :443 ao PsPing.

Se você carregou a página de Office 365 de desempenho lento 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 tomadas para filtrar seu Netmon para obter o endereço IP (e dar uma olhada na Latência DNS). Este exemplo usa outlook.office365.com, mas também pode usar a URL de um locatário do SharePoint (hithere.sharepoint.com por exemplo).

1. Faça 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 fazendo a ação que lhe dá o problema de desempenho ou, se você vir uma alta latência no ping, em si, rastreá-la na rede.
3. Abra o rastreamento no Netmon e filtre para DNS (esse filtro também funciona no Wireshark, mas é sensível ao caso -- dns). Como você sabe o nome do servidor DNS do seu ping, você também pode filtrar mais rapidamente no Netmon assim: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), que se parece com isso em dns wireshark e 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 DNS, você encontrará o endereço IP do servidor DNS ao qual a solicitação foi Office 365. Você precisará desse endereço IP para a próxima etapa (a ferramenta PsPing). Remova o filtro, clique com o botão direito do mouse na DNS Response in Netmon (DNS deLocalização> de Resumo > de Quadros) 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 DNS e a Resposta. Na próxima etapa, a ferramenta PsPing fácil de instalar e usar é muito útil, tanto porque o ICMP é frequentemente bloqueado em Firewalls, quanto porque o PsPing rastreia elegantemente a latência em milissegundos. O PsPing conclui uma conexão TCP com um endereço e uma porta (no caso, abra a porta 443).
5. Instalar o PsPing.
6. Abra um prompt de comando (cmd do tipo Iniciar > Execução > ou cmd do tipo Chave > do 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 o PsPing no endereço IP do servidor DNS Office 365 do rastreamento netmon anterior, incluindo o número da porta, como psping -n 20 132.245.24.82:445. Isso lhe dará uma amostragem de 20 pings e média da latência quando o PsPing for interrompido.

Se você for Office 365 por meio de um servidor proxy, as etapas serão um pouco diferentes. Primeiro, psPing no servidor proxy para obter um valor médio de latência em milissegundos para proxy/saída e voltar 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 no proxy, terá dois valores de milissegundos: computador cliente para servidor proxy ou ponto de saída e servidor proxy para Office 365. E você terminou! Bem, valores de gravação, 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, você 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 o ponto de saída do valor do computador cliente para 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 saída apontam para Office 365.

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

Latência, como visto em um rastreamento netmon, esses milissegundos extras podem somar, se houver o suficiente deles em qualquer sessão.

Observação

Seu endereço IP pode ser diferente dos IPs mostrados aqui, por exemplo, seu ping pode retornar algo mais como 157.56.0.0.0/16 ou um intervalo semelhante. Para uma lista de intervalos usados por Office 365, marcar 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 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, consistentemente. Você não deve ver um desempenho incorreto intermitente durante os períodos de pico de uso (por exemplo).

Se a autenticação proxy estiver ativada, sempre que você fizer uma nova conexão TCP com Office 365 para obter informações, você 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, 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 carga lentos sempre que alternar entre Calendário e sua caixa de correio ou cargas lentas de página no SharePoint. No entanto, há outros sintomas não listados aqui.

A autenticação de proxy é uma configuração no servidor proxy de saída. Se ele estiver causando um problema de desempenho com Office 365, você deve 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 ativada, geralmente 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 NTLMSSP' ao Netmon e filtre para .property.NTLMSSPSummary. Para ver quanto tempo a autenticação está levando, adicione a coluna Delta do 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 e o Delta do TempoNTLMSSP na lista e clique em Adicionar.
4. Mova as novas colunas para o lugar antes ou atrá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 que estágio de autenticação você está.

Ao procurar instâncias de Autenticação proxy, estude 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 no TCP Localizar Conversas > . Esteja ciente dos valores do Delta do Tempo nessas Conversas.

Um atraso de quatro segundos na autenticação de proxy, como visto no Wireshark. O delta do tempo da coluna de quadro exibido anterior foi feito clicando com o botão direito do mouse no campo do mesmo nome nos detalhes do quadro e selecionando Adicionar como Coluna.

Desempenho DNS

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

Se a resolução de nomes DNS estiver ocorrendo no exterior, ela poderá adicionar segundos às cargas de página. O ideal é que a resolução de nomes ocorra em menos de 100 ms. Se não, você deve fazer uma investigação mais aprofundada.

Dica

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

Ferramentas

• Netmon
• Wireshark
• PsPing

O que procurar

Analisar o desempenho de DNS normalmente é outro trabalho para um rastreamento de rede. No entanto, psPing também é útil na decisão dentro ou fora de uma possível causa.

O tráfego DNS é baseado em solicitações E respostas TCP e UDP 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 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, passa por UDP.

No Netmon e no Wireshark, o filtro mais básico que permitirá que você examine o tráfego DNS é simplesmente dns. Use o caso inferior ao especificar o filtro. Lembre-se de liberar o cache de resolver DNS antes de começar a reproduzir o problema no computador cliente. Por exemplo, se você tiver um carregamento lento de página do SharePoint para a página Inicial, deverá fechar todos os navegadores, abrir um novo navegador, iniciar o rastreamento, liberar seu cache de resolvedor DNS e navegar até seu site do SharePoint. Depois que a página inteira for resolvida, você deve parar e salvar o rastreamento.

Você quer ver o deslocamento de tempo aqui. E pode ser útil adicionar a coluna Time Delta 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 do Tempo na lista e clique em Adicionar.
4. Mova a nova coluna para o lugar antes ou atrás da coluna Descrição para que você possa lê-las lado a lado.
5. Clique em OK.

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

No Wireshark, você pode fazer uma coluna para o tempo DNS. Pegue o rastreamento (ou abra um rastreamento) em Wireshark e filtre por dns, ou, mais útil, dns.time. Clique em qualquer consulta DNS e, no painel que mostra 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 Time para classificação mais rápida de seu rastreamento. Clique na nova coluna para classificar decrescente valores para ver qual chamada DNS demorou mais tempo para resolve.

Uma navegação do SharePoint filtrada em Wireshark por (minúsculas) dns.time, com o tempo dos detalhes transformados em uma coluna e o crescente classificado.

Se você quiser fazer mais investigações sobre o tempo de resolução DNS, experimente um PsPing na 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, o problema é mais provável que 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 lhe dirá onde a resolução de nomes DNS para o Outlook Online está ocorrendo (por exemplo, outlook-namnorthwest.office365.com).

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

Escalabilidade do proxy

Serviços como o 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 útil mais longa.

Ferramentas

Matemática

O que procurar

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

Tamanho máximo do segmento TCP

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

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

Ferramentas

Netmon

O que procurar

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

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

Observação

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

Olhando para o rastreamento em 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.

Em Wireshark, use algo como frame contains "sphybridExample". Se você notar que encontrou o tráfego RWS (Remote Winsock) (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, soltar o filtro e 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, encontrar sua URL no rastreamento (parte de sphybridExample-my.sharepoint.com, por exemplo), fornecerá endereços IP para 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 TCP (em Netmon) ou Protocolo de Controle de Transmissão (em Wireshark) no painel Detalhes do Quadro. Expanda opções 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, uso a coluna interna no Netmon chamada Solução de problemas TCP.

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

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

Se você precisar marcar Reconhecimento Seletivo (próximo tópico nesta matriz), não feche o rastreamento!

Reconhecimento Seletivo

Encontrado no SYN – SYN/ACK. Deve ser relatado como Permitido no SYN e no SYN/ACK. O SACK (Reconhecimento Seletivo) permite uma retransmissão mais suave de dados quando um pacote ou pacotes desaparecem. Os dispositivos podem desabilitar esse recurso, o que pode levar a problemas de desempenho.

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

Ferramentas

Netmon

O que procurar

O SACK (Reconhecimento Seletivo) é outro parâmetro no aperto de mão 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 examinando 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 Protocolo de Controle de Transmissão em Wireshark na seção Detalhes do Quadro. Expanda opções 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 em Netmon e Wireshark.

Geolocalização DNS

Onde no mundo Office 365 tenta resolve sua chamada DNS afeta sua velocidade de conexão.

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

Ao acessar o SharePoint, um usuário que viaja para o exterior será direcionado para seu datacenter ativo - esse é o dC cujo local é baseado na base de base de seu locatário SPO (portanto, um dC nos EUA se o usuário for baseado 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, onde o Lync online está ativo.

Dica

Precisa saber mais sobre como os clientes se conectam a 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 no retorno do endereço IP do Microsoft DNS de um datacenter regional (dC). O que isso significa para você? Se sua sede estiver em Bengaluru, na Índia, mas você estiver viajando no Estados Unidos, quando seu navegador fizer uma solicitação para o Outlook Online, os servidores DNS da Microsoft devem entregar endereços IP para datacenters no Estados Unidos - um datacenter regional. Se o email for necessário do Outlook, esses dados viajarão pela rede de backbone rápida da Microsoft entre os datacenters.

O DNS funciona mais rápido quando a resolução de nomes é feita o mais próximo possível da localização do usuário. Se você estiver na Europa, deseja ir a um DNS da Microsoft na Europa e (idealmente) lidar com um datacenter na Europa. O desempenho de um cliente na Europa indo para 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, 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 iniciar > execução > ou cmd do tipo de chave > do Windows). Digite outlook.office365.com de ping e pressione ENTER. Lembre-se de especificar -4 se você quiser especificar o ping via IPv4. Você pode não obter uma resposta dos pacotes ICMP, mas deve ver o nome do DNS para o qual a solicitação foi roteada. Se você quiser ver os números de latência dessa conexão, tente PsPing para o endereço IP do servidor que é retornado por ping.

Solução de problemas do aplicativo Office 365

Ferramentas

• Netmon
• HTTPWatch
• Console F12 no navegador

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

Artigos relacionados

Gerenciar pontos de extremidade do Office 365

Perguntas frequentes sobre pontos de extremidade do Office 365