Office 365 otimização do desempenho com linhas de base e histórico de desempenho

Existem algumas formas simples de verificar o desempenho da ligação entre Office 365 e a sua empresa que lhe permitirão estabelecer uma linha de base aproximada da sua conectividade. Conhecer o histórico de desempenho das ligações do computador cliente pode ajudá-lo a detetar problemas emergentes mais cedo, identificar e prever problemas.

Se não estiver habituado a trabalhar em problemas de desempenho, este artigo foi concebido para o ajudar a considerar algumas perguntas comuns. Como sabe que o problema que está a ver é um problema de desempenho e não um incidente de serviço Office 365? Como pode planear um bom desempenho a longo prazo? Como pode controlar o desempenho? Se a sua equipa ou clientes estiverem a ver um desempenho lento ao utilizar Office 365 e se questionar sobre qualquer uma destas perguntas, continue a ler.

Importante

Tem um problema de desempenho entre o cliente e o Office 365 neste momento? Siga os passos descritos no plano de resolução de problemas de desempenho para Office 365.

Algo que deve saber sobre Office 365 desempenho

Office 365 está dentro de uma rede Microsoft dedicada de alta capacidade que é monitorizada pela automatização e por pessoas reais. Parte da manutenção do Office 365 cloud é a otimização do desempenho e a simplificação sempre que possível. Uma vez que os clientes da cloud Office 365 têm de se ligar através da Internet, há um esforço contínuo para otimizar o desempenho em todos os serviços Office 365 também.

As melhorias de desempenho nunca param realmente na cloud, pelo que também não tem experiência em manter a cloud em bom estado de funcionamento e rapidez. Se tiver um problema de desempenho ao ligar a partir da sua localização para Office 365, é melhor não começar ou esperar por um caso de Suporte. Em vez disso, deve começar a investigar o problema de dentro para fora. Ou seja, comece dentro da sua rede e faça a sua saída para Office 365. Antes de abrir um caso com o Suporte, pode recolher dados e efetuar ações que irão explorar e resolver o problema.

Importante

Tenha em atenção o planeamento da capacidade e os limites no Office 365. Essa informação coloca-o à frente da curva ao tentar resolver um problema de desempenho. Eis uma ligação para as descrições do serviço Microsoft 365 e Office 365. Este é um hub central e todos os serviços oferecidos pelo Office 365 têm uma ligação que vai para as suas próprias Descrições de Serviço a partir daqui. Isto significa que, se precisar de ver os limites padrão do SharePoint, por exemplo, clique em Descrição do Serviço SharePoint e localize a secção Limites do SharePoint.

Certifique-se de que entra na resolução de problemas com a compreensão de que o desempenho é uma escala deslizante. Não se trata de alcançar um valor idealizado e mantê-lo permanentemente. As tarefas ocasionais de largura de banda elevada, como a integração de um grande número de utilizadores ou a realização de migrações de dados de grandes dimensões, serão stressantes, por isso, planeie os impactos no desempenho. Deve ter uma ideia aproximada dos seus objetivos de desempenho, mas muitas variáveis são reproduzidas no desempenho, pelo que o desempenho varia.

A resolução de problemas de desempenho não tem a ver com cumprir objetivos específicos e manter esses números indefinidamente, trata-se de melhorar as atividades existentes, tendo em conta todas as variáveis.

Qual é o aspeto de um problema de desempenho?

Primeiro, tem de se certificar de que o que está a ter é, de facto, 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. Eis como distingui-los.

Os Incidentes de Serviço ocorrem quando o próprio serviço Office 365 está a ter problemas. Poderá ver ícones vermelhos ou amarelos em Estado de funcionamento atual no centro de administração do Microsoft 365. Poderá reparar que o desempenho nos computadores cliente que se ligam ao Office 365 está lento. Por exemplo, se o Estado de funcionamento atual apresentar um ícone vermelho e vir Investigar ao lado do Exchange, também poderá receber chamadas de pessoas na sua organização que se queixam de que as caixas de correio cliente que utilizam Exchange Online são lentas. Nesse caso, é razoável presumir que a sua Exchange Online desempenho foi vítima de problemas de Serviço.

Neste momento, o administrador do Office 365 deve verificar o Estado de funcionamento atual e, em seguida, Ver detalhes e histórico, muitas vezes, para se manter atualizado sobre a manutenção no sistema. O dashboard Estado de funcionamento atual foi feito para o atualizar sobre as alterações e problemas no serviço. As notas e explicações escritas no histórico de estado de funcionamento, administrador para administrador, estão lá para ajudá-lo a avaliar e mantê-lo informado sobre o trabalho em curso.

Um problema de desempenho não é um incidente de serviço, embora os incidentes possam causar um desempenho lento. Um problema de desempenho tem o seguinte aspeto:

• Ocorre um problema de desempenho independentemente do que o centro de administração Atual estado de funcionamento esteja a comunicar para o serviço.

• Um comportamento que costumava fluir demora muito tempo a ser concluído ou nunca é concluído.

• Também pode replicar o problema ou saber que acontece se efetuar a série de passos correta.

• Se o problema for intermitente, ainda pode existir um padrão. Por exemplo, sabe que até às 10:00 terá chamadas de utilizadores que nem sempre podem aceder a Office 365. As chamadas terminarão por volta do meio-dia.

Esta lista provavelmente parece familiar; talvez demasiado familiar. Assim que tiver conhecimento de que se trata de um problema de desempenho, a pergunta torna-se: "O que fazer a seguir?" O resto deste artigo ajuda-o a determinar exatamente isso.

Como definir e testar o problema de desempenho

Os problemas de desempenho surgem frequentemente ao longo do tempo, pelo que pode ser um desafio definir o problema real. Create uma boa declaração de problema com uma boa ideia do contexto do problema e, em seguida, tem de repetir os passos de teste. Eis alguns exemplos de declarações de problemas que não fornecem informações suficientes:

• Mudar da minha Caixa de Entrada para o meu Calendário costumava ser algo que não notei e agora é uma pausa para café. Podes fazê-lo agir como costumava fazer?

• Carregar os meus ficheiros para o SharePoint está a demorar muito tempo. Por que é lento à tarde, mas em qualquer outra hora, é rápido? Não pode ser rápido?

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

• Não é claro como alternar entre a Caixa de Entrada e o Calendário costumava funcionar no portátil.

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

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

O administrador e a resolução de problemas não podem estar cientes dos detalhes do problema em declarações gerais como estas. Por exemplo, não sabem quando o problema começou a ocorrer. A resolução de problemas pode não saber que o utilizador trabalha a partir de casa e só vê uma mudança lenta na rede doméstica. Ou que o utilizador executa outras aplicações de RAM intensivas no cliente local. Os administradores podem não saber que o utilizador está a executar um sistema operativo mais antigo ou não executou atualizações recentes.

Quando os utilizadores comunicam um problema de desempenho, há muitas informações a recolher. As informações de obtenção e gravação chamam-se âmbito do problema. Eis uma lista de âmbito básica que pode utilizar para recolher informações sobre problemas de desempenho. Esta lista não é exaustiva, mas é um local para começar:

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

• Que tipo de computador cliente estava a utilizar e como se liga à rede empresarial (VPN, Com Fios, Sem Fios)?

• Estava a trabalhar remotamente ou estava no escritório?

• Experimentou as mesmas ações noutro computador e viu o mesmo comportamento?

• Siga os passos que estão a dar-lhe problemas para que possa escrever as ações que realizar.

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

• Onde está localizado no mundo?

Algumas destas perguntas são mais óbvias do que outras. A maioria das pessoas compreenderá que uma resolução de problemas precisa dos passos exatos para reproduzir o problema. Afinal, de que outra forma pode registar o que está errado e de que outra forma pode testar se o problema foi corrigido? Menos óbvios são coisas como "Que data e hora viu o problema?" e "Onde está localizado?", informações que podem ser utilizadas em conjunto. Dependendo de quando o utilizador estava a trabalhar, algumas horas de diferença de tempo podem significar que a manutenção já está em curso em partes da rede da sua empresa. Por exemplo, a 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 numa instância do SharePoint Server 2013 no local, as atualizações podem estar em curso no farm no local. Se a sua empresa estiver na cloud, a manutenção do sistema poderá incluir adicionar ou remover hardware de rede, implementar atualizações que sejam de toda a empresa ou efetuar alterações ao DNS ou a outra infraestrutura principal.

Quando se está a resolver um problema de desempenho, é um pouco como uma cena de crime, é preciso ser preciso e observador para tirar conclusões das provas. Para tal, tem de obter uma boa declaração de problema ao reunir provas. Deve incluir o contexto do computador, o contexto do utilizador, quando o problema começou e os passos exatos que expuseram o problema de desempenho. Esta declaração de problema deve ser, e permanecer, a página superior nas suas notas. Ao percorrer novamente a declaração do problema depois de trabalhar na resolução, está a tomar as medidas para testar e provar se as ações que toma resolveram o problema. Isto é fundamental para saber quando o seu trabalho está concluído.

Sabe qual era o aspeto do desempenho quando era bom?

Se tiver azar, ninguém sabe. Ninguém tinha números. Isto significa que ninguém pode responder à simples pergunta "Sobre quantos segundos demorou a abrir uma Caixa de Entrada no Office 365?" ou "Quanto tempo demorou quando os Executivos tinham uma reunião do Lync Online?", que é um cenário comum para muitas empresas.

O que falta aqui é uma linha de base de desempenho.

As linhas de base dão-lhe um contexto para o seu desempenho. Deve utilizar uma linha de base ocasionalmente para frequentemente, consoante as necessidades da sua empresa. Se for uma empresa maior, a sua equipa de Operações poderá já ter linhas de base para o seu ambiente no local. Por exemplo, se corrigir todos os servidores exchange na primeira segunda-feira do mês e todos os servidores do SharePoint na terceira segunda-feira, a equipa de Operações provavelmente tem uma lista de tarefas e cenários que executa 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 certificar-se de que as pastas são atualizadas ou, no SharePoint, navegar na página principal do site, aceder à página Pesquisa da empresa e efetuar uma pesquisa que devolva resultados.

Se as suas aplicações estiverem em Office 365, algumas das linhas de base mais fundamentais podem medir o tempo (em milissegundos) de um computador cliente dentro da sua rede, até um ponto de saída ou o ponto em que sai da rede e sai para Office 365. Seguem-se algumas linhas de base úteis que pode investigar e registar:

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

  • Tem de conhecer os seus dispositivos para que tenha contexto (endereços IP, tipo de dispositivo, etc.) para problemas de desempenho que surjam.

  • Os servidores proxy são pontos de saída comuns, pelo que pode verificar o browser para ver que servidor proxy está definido para utilizar, se existir.

  • Existem ferramentas de terceiros que podem detetar e mapear a sua rede, mas a forma mais segura de conhecer os seus dispositivos é pedir a um membro da sua equipa de rede.

• Identifique o seu fornecedor de serviços Internet (ISP), anote as respetivas informações de contacto e pergunte quantos circuitos tem.

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

Seguem-se algumas linhas de base que os testes simples com ferramentas podem calcular para si:

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

• Tempo do ponto de saída para Office 365 em milissegundos

• Localização no mundo do servidor que resolve os URLS para Office 365 quando navega

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

Se não estiver familiarizado com a realização destes passos, iremos entrar em mais detalhes neste artigo.

O que é uma linha de base?

Saberá o impacto quando correr mal, mas se não souber os seus dados de desempenho históricos, não é possível ter um contexto sobre o quão mau pode ter ficado e quando. Por isso, sem uma linha de base, falta-lhe a pista-chave para resolver o puzzle: a imagem na caixa do puzzle. Na resolução de problemas de desempenho, precisa de um ponto de comparação. As linhas de base de desempenho simples não são difíceis de tomar. A sua equipa de Operações pode ter a tarefa de realizar estas tarefas com base numa agenda. Por exemplo, digamos que a ligação tem o seguinte aspeto:

Isto significa que verificou com a sua equipa de rede e descobriu que deixou a sua empresa para a Internet através de um servidor proxy e que esse proxy processa todos os pedidos que o computador cliente envia para a cloud. Neste caso, deve desenhar uma versão simplificada da sua ligação que lista todos os dispositivos intervenientes. Agora, insira ferramentas que pode utilizar para testar o desempenho entre o cliente, o ponto de saída (onde deixa a rede para a Internet) e o Office 365 cloud.

As opções estão listadas como Simples e Avançadas devido à quantidade de conhecimentos necessários para encontrar os dados de desempenho. Um rastreio de rede irá demorar muito tempo, em comparação com a execução de ferramentas de linha de comandos, como PsPing e TraceTCP. Estas duas ferramentas de linha de comandos foram escolhidas porque não utilizam pacotes ICMP, que serão bloqueados por Office 365 e porque dão tempo em milissegundos necessários para sair do computador cliente ou do servidor proxy (se tiver acesso) e chegar a Office 365. Cada salto individual de um computador para outro acabará com um valor de tempo, o que é ótimo para linhas de base! Igualmente importante, estas ferramentas de linha de comandos permitem-lhe adicionar um número de porta ao comando, o que é útil porque Office 365 comunica através da porta 443, que é a porta utilizada pelo Secure Sockets Layer e Transport Layer Security (SSL e TLS). No entanto, outras ferramentas de terceiros podem ser melhores soluções para a sua situação. A Microsoft não suporta todas estas ferramentas, por isso, se, por algum motivo, não conseguir psPing e TraceTCP funcionar, avance para um rastreio de rede com uma ferramenta como o Netmon.

Pode efetuar uma linha de base antes do horário comercial, novamente durante uma utilização intensiva e, em seguida, novamente fora do horário de expediente. Isto significa que pode ter uma estrutura de pastas com um aspeto semelhante ao seguinte no final:

Também deve escolher uma convenção de nomenclatura para os seus ficheiros. Eis 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

Existem várias formas diferentes de o fazer, mas utilizar o formato <dateTime><o que está a acontecer no teste> é um bom ponto de partida. Ser diligente em relação a isto ajudará muito quando estiver a tentar resolver problemas mais tarde. Mais tarde, poderá dizer "Fiz dois rastreios no dia 8 de fevereiro, um mostrou um bom desempenho e outro mostrou mau, para que possamos compará-los". Isto é útil para a resolução de problemas.

Precisa de ter uma forma organizada de manter as suas linhas de base históricas. Neste exemplo, os métodos simples produziram três saídas de linha de comandos e os resultados foram recolhidos como capturas de ecrã, mas poderá ter ficheiros de captura de rede. Utilize o método que funciona melhor para si. Armazene as suas linhas de base históricas e consulte-as em pontos onde nota alterações no comportamento das serviços online.

Porquê recolher dados de desempenho durante um piloto?

Não há melhor altura para começar a criar linhas de base do que durante um piloto do serviço Office 365. O seu escritório pode ter milhares de utilizadores, centenas de milhares ou pode ter cinco, mas mesmo com alguns utilizadores, pode realizar testes para medir as flutuações no desempenho. No caso de uma grande empresa, uma amostra representativa de várias centenas de utilizadores que pilotam Office 365 pode ser projetada para fora para vários milhares para saber onde podem surgir problemas antes de acontecerem.

No caso de uma pequena empresa, em que a integração significa que todos os utilizadores acedem ao serviço ao mesmo tempo e não existem pilotos, mantêm medidas de desempenho para que tenha dados para mostrar a qualquer pessoa que possa ter de resolver problemas de uma operação de mau desempenho. Por exemplo, se reparar que, de repente, pode andar pelo seu edifício no tempo que demora a carregar um gráfico de tamanho médio onde costumava acontecer rapidamente.

Como recolher linhas de base

Para todos os planos de resolução de problemas, tem de identificar estas coisas no mínimo:

• O computador cliente que está a utilizar (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 utilizador está numa VPN para a rede, a trabalhar remotamente ou na intranet da empresa)

• O ponto de saída que o computador cliente utiliza a partir da sua rede (o ponto em que o tráfego deixa a sua empresa para um ISP ou Internet)

Pode descobrir o esquema da sua rede através do administrador de rede. Se estiver numa rede pequena, consulte os dispositivos que o ligam à Internet e contacte o SEU ISP se tiver dúvidas sobre o esquema. Create um gráfico do esquema final da referência.

Esta secção está dividida em ferramentas e métodos de linha de comandos simples e em opções de ferramentas mais avançadas. Vamos abordar os métodos simples primeiro. No entanto, se tiver um problema de desempenho neste momento, deve avançar para métodos avançados e experimentar o plano de ação de resolução de problemas de desempenho de exemplo.

Métodos simples

O objetivo destes métodos simples é aprender a tomar, compreender e armazenar corretamente linhas de base de desempenho simples ao longo do tempo para que seja informado sobre Office 365 desempenho. Eis o diagrama simples para simples, como já viu anteriormente:

Nota

O TraceTCP está incluído nesta captura de ecrã porque é uma ferramenta útil para mostrar, em milissegundos, quanto tempo um pedido demora a processar e quantos saltos de rede, ou ligações de um computador para o seguinte, que o pedido demora a chegar a um destino. O TraceTCP também pode fornecer os nomes dos servidores utilizados durante os saltos, o que pode ser útil para uma resolução de problemas de 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 é uma transferência gratuita, mas depende do Wincap. O Wincap é uma ferramenta que também é utilizada e instalada pelo Netmon. Também utilizamos o Netmon na secção de métodos avançados.

Se tiver vários escritórios, também terá de manter um conjunto de dados de um cliente em cada uma dessas localizações. Este teste mede a latência, que, neste caso, é um valor numérico que descreve a quantidade de tempo entre um cliente que envia um pedido para Office 365 e Office 365 a responder ao pedido. O teste tem origem no seu domínio num computador cliente e procura medir um percurso de ida e volta a partir do interior da rede, através de um ponto de saída, através da Internet para Office 365 e para trás.

Existem algumas formas de lidar com o ponto de saída, neste caso, o servidor proxy. Pode rastrear de 1 a 2 e, em seguida, de 2 a 3 e, em seguida, adicionar os números em milissegundos para obter um total final à margem da sua rede. Em alternativa, pode configurar a ligação para ignorar o proxy para Office 365 endereços. Numa rede maior com uma firewall, proxy inverso ou alguma combinação dos dois, poderá ter de abrir exceções no servidor proxy que permitirão que o tráfego passe para muitos URLs. Para obter a lista de pontos finais utilizados pelo Office 365, veja Office 365 URLs e intervalos de endereços IP. Se tiver um proxy de autenticação, comece por testar as exceções para o seguinte:

• Portas 80 e 443

• TCP e HTTPs

• Connections que estão de saída para qualquer um destes URLs:

• *.microsoftonline.com

• *.microsoftonline-p.com

• *.sharepoint.com

• *.outlook.com

• *.lync.com

• osub.microsoft.com

Todos os utilizadores têm de ter permissão para aceder a estes endereços sem qualquer interferência ou autenticação de proxy. Numa rede mais pequena, deve adicioná-las à sua lista de ignorar proxy no browser.

Para adicioná-los à sua lista de ignorar proxy no Internet Explorer, aceda a Ferramentas>Opções> da Internet Connections>Definições de LAN Avançadas>. O separador avançado também é onde encontrará o servidor proxy e a porta do servidor proxy. Poderá ter de selecionar a caixa de verificação Utilizar um servidor proxy para a lan para aceder ao botão Avançadas . Deverá certificar-se de que a opção Ignorar servidor proxy para endereços locais está selecionada. Depois de selecionar Avançadas, verá uma caixa de texto onde pode introduzir exceções. Separe os URLs de carateres universais listados acima com ponto e vírgula, por exemplo:

*.microsoftonline.com; *.sharepoint.com

Depois de ignorar o proxy, deverá conseguir utilizar o ping ou o PsPing diretamente num URL de Office 365. O próximo passo será testar o ping outlook.office365.com. Em alternativa, se estiver a utilizar o PsPing ou outra ferramenta que lhe permita fornecer um número de porta ao comando, o PsPing contra 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 o tempo que demora a enviar um pedido HTTP para um servidor como outlook.office365.com e obter uma resposta que reconhece que o servidor sabe que o fez. Por vezes, verá isto abreviado como RTT. Este deve ser um período de tempo relativamente curto.

Tem de utilizar o PSPing ou outra ferramenta que não utilize pacotes ICMP bloqueados por Office 365 para fazer este teste.

Como utilizar o PsPing para obter um tempo geral de ida e volta em milissegundos diretamente a partir de um URL de Office 365

1. Execute uma linha de comandos elevada ao concluir estes passos:

2. Clique em Iniciar.

3. Na caixa Iniciar Pesquisa, escreva cmd e, em seguida, prima Ctrl+Shift+Enter.

4. Se for apresentada a caixa de diálogo Controlo de Conta de Utilizador , confirme que a ação apresentada é a que pretende e, em seguida, clique em Continuar.

5. Navegue para a pasta onde a ferramenta (neste caso, PsPing) está instalada e teste estes URLs de Office 365:

• psping admin.microsoft.com:443

• psping microsoft-my.sharepoint.com:443

• psping outlook.office365.com:443

• psping www.yammer.com:443

  

Certifique-se de que inclui o número de porta 443. Lembre-se de que Office 365 funciona num canal encriptado. Se psPing sem o número da porta, o pedido falhará. Depois de enviar um ping para a sua pequena lista, procure o Tempo médio em milissegundos (ms). É o que quer gravar!

Se não estiver familiarizado com o desativação do proxy e preferir efetuar ações passo a passo, primeiro tem de descobrir o nome do servidor proxy. No Internet Explorer, aceda a Ferramentas Opções>> daInternetConnections>DefiniçõesdeLANAvançadas>. O separador Avançadas é onde verá o servidor proxy listado. Faça ping a esse servidor proxy numa linha de comandos ao concluir esta tarefa:

Para fazer ping ao servidor proxy e obter um valor de ida e volta em milissegundos para a fase 1 a 2

1. Execute uma linha de comandos elevada ao concluir estes passos:

2. Clique em Iniciar.

3. Na caixa Iniciar Pesquisa, escreva cmd e, em seguida, prima Ctrl+Shift+Enter.

4. Se for apresentada a caixa de diálogo Controlo de Conta de Utilizador , confirme que a ação apresentada é a que pretende e, em seguida, clique em Continuar.

5. Escreva ping <no nome do servidor proxy que o browser utiliza ou o endereço IP do servidor> proxy e, em seguida, prima ENTER. Se tiver o PsPing ou outra ferramenta instalada, pode optar por utilizar essa ferramenta.

   O comando poderá ter um aspeto semelhante a 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 rastreio deixar de enviar pacotes de teste, obterá um pequeno resumo que lista uma média, em milissegundos, e esse é o valor que procura. Faça uma captura de ecrã da linha de comandos e guarde-a com a sua convenção de nomenclatura. Neste momento, também poderá ajudar a preencher o diagrama com o valor .

Talvez tenha feito um rastreio de manhã cedo e o cliente possa aceder rapidamente ao proxy (ou qualquer servidor de saída que saia da Internet). Neste caso, os seus números poderão ter o seguinte aspeto:

Se o computador cliente for um dos poucos selecionados com acesso ao servidor proxy (ou de saída), pode executar a etapa seguinte do teste ligando-se remotamente a esse computador, executando a linha de comandos para PsPing para um URL de Office 365 a partir daí. Se não tiver acesso a esse computador, pode contactar os recursos de rede para obter ajuda com a próxima etapa e obter números exatos dessa forma. Se isso não for possível, utilize um PsPing contra o URL de Office 365 em questão e compare-o com o tempo de PsPing ou Ping com o servidor proxy.

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

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

Métodos avançados

Se realmente quiser saber o que está a acontecer com os seus pedidos de Internet para Office 365, tem de se familiarizar com os rastreios de rede. Não importa as ferramentas que preferir para estes rastreios, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Ferramenta de Dashboard do Programador ou qualquer outra ferramenta, desde que essa ferramenta possa capturar e filtrar o tráfego de rede. Verá nesta secção que é vantajoso executar mais do que uma destas ferramentas para obter uma imagem mais completa do problema. Quando está a testar, algumas destas ferramentas também funcionam como proxies por si só. As ferramentas utilizadas no artigo complementar Plano de resolução de problemas de desempenho para Office 365 incluem o Netmon 3.4, o HTTPWatch ou o WireShark.

Efetuar uma linha de base de desempenho é a parte simples deste método e muitos dos passos são os mesmos que quando resolução de problemas de desempenho. Os métodos mais avançados de criação de linhas de base para o desempenho requerem a utilização e o armazenamento de rastreios de rede. A maioria dos exemplos neste artigo utiliza o SharePoint, mas deve desenvolver uma lista de ações comuns nos serviços Office 365 aos quais subscreve para testar e registar. Eis um exemplo de linha de base:

• Lista de linhas de base do SPO – ** Passo 1: ** Navegue na home page do site do SPO e faça um rastreio de rede. Guarde o rastreio.

• Lista de linhas de base do SPO – Passo 2: Pesquisa para um termo (como o nome da empresa) através do Enterprise Pesquisa e efetuar um rastreio de rede. Guarde o rastreio.

• Lista de linhas de base do SPO – Passo 3: Carregue um ficheiro grande para uma biblioteca de documentos do SharePoint e faça um rastreio de rede. Guarde o rastreio.

• Lista de linhas de base do SPO – Passo 4: navegue na home page do site do OneDrive e faça um rastreio de rede. Guarde o rastreio.

Esta lista deve incluir as ações comuns mais importantes que os utilizadores efetuam no SharePoint. Tenha em atenção que o último passo, para rastrear a ida ao OneDrive, cria uma comparação entre a carga da home page do SharePoint (que é muitas vezes personalizada por empresas) e a home page do OneDrive, que raramente é personalizada. Este é um teste básico quando se trata de um site do SharePoint de carregamento lento. Pode criar um registo desta diferença nos testes.

Se estiver a meio de um problema de desempenho, muitos dos passos são os mesmos que ao executar uma linha de base. Os rastreios de rede tornam-se críticos, pelo que iremos processar os rastreios importantes a seguir.

Para resolver um problema de desempenho, neste momento, tem de fazer um rastreio no momento em que está a ter o problema de desempenho. Precisa de ter as ferramentas adequadas disponíveis para recolher registos e precisa de um plano de ação, ou seja, uma lista de ações de resolução de problemas a tomar para recolher as melhores informações que puder. A primeira coisa a fazer é registar a data e a hora do teste para que os ficheiros possam ser guardados numa pasta que reflita a temporização. Em seguida, reduza os próprios passos do problema. Estes são os passos exatos que irá utilizar para testar. Não se esqueça das noções básicas: se o problema for apenas com o Outlook, certifique-se de que regista que o comportamento do problema ocorre apenas num serviço Office 365. Reduzir o âmbito deste problema irá ajudá-lo a concentrar-se em algo que pode resolver.

Consulte também

Gerir pontos finais do Office 365