Piano di risoluzione dei problemi relativi alle prestazioni per Office 365

È necessario conoscere i passaggi da eseguire per identificare e correggere ritardi, blocchi e prestazioni lente tra SharePoint, OneDrive, Exchange Online o Skype for Business Online e il computer client? Prima di chiamare il supporto tecnico, questo articolo consente di risolvere i problemi di prestazioni Office 365 e persino di risolvere alcuni dei problemi più comuni.

Questo articolo è in realtà un piano d'azione di esempio che è possibile usare per acquisire dati preziosi sul problema di prestazioni durante il processo. In questo articolo sono inclusi anche alcuni problemi principali.

Se non si ha familiarità con le prestazioni di rete e si vuole creare un piano a lungo termine per monitorare le prestazioni tra i computer client e Office 365, esaminare Office 365 ottimizzazione delle prestazioni e risoluzione dei problemi: Amministrazione e PROFESSIONISTI IT.

Piano d'azione per la risoluzione dei problemi delle prestazioni di esempio

Questo piano d'azione contiene due parti; una fase di preparazione e una fase di registrazione. Se al momento si verifica un problema di prestazioni ed è necessario eseguire la raccolta dei dati, è possibile iniziare subito a usare questo piano.

Preparare il computer client

• Trovare un computer client in grado di riprodurre il problema di prestazioni. Questo computer verrà usato durante la risoluzione dei problemi.
• Annotare i passaggi che causano il problema di prestazioni in modo da essere pronti al momento del test.
• Installare gli strumenti per la raccolta e la registrazione di informazioni:
  • Installare Netmon 3.4 (o usare uno strumento di traccia di rete equivalente).
  • Installare l'edizione Basic gratuita di HTTPWatch (o usare uno strumento di traccia di rete equivalente).
  • Usare una registrazione dello schermo o eseguire la registrazione passaggi (PSR.exe) fornita con Windows Vista e versioni successive, per tenere traccia dei passaggi eseguiti durante il test.

Registrare il problema di prestazioni

• Chiudere tutti i browser Internet estranei.

• Avviare Registrazione passaggi o un altro registratore dello schermo.

• Avviare l'acquisizione di Netmon (o lo strumento di traccia di rete).

• Cancellare la cache DNS nel computer client dalla riga di comando digitando ipconfig /flushdns.

• Avviare una nuova sessione del browser e attivare HTTPWatch.

• Facoltativo: se si sta testando Exchange Online, eseguire lo strumento exchange client analizzatore prestazioni dalla console di amministrazione di Office 365.

• Riprodurre i passaggi esatti che causano il problema di prestazioni.

• Arrestare la traccia di Netmon o di altri strumenti.

• Nella riga di comando eseguire una route di traccia alla sottoscrizione Office 365 digitando il comando seguente e quindi premendo INVIO:

  tracert <subscriptionname>.onmicrosoft.com
  

• Arrestare Registrazione passaggi e salvare il video. Assicurarsi di includere la data e l'ora dell'acquisizione e verificare se le prestazioni sono buone o negative.

• Salvare i file di traccia. Anche in questo caso, assicurarsi di includere la data e l'ora dell'acquisizione e se le prestazioni sono buone o negative.

Se non si ha familiarità con l'esecuzione degli strumenti indicati in questo articolo, non preoccuparsi perché vengono forniti i passaggi successivi. Se si è abituati a eseguire questo tipo di acquisizione di rete, è possibile passare a Come raccogliere le baseline, che descrive il filtro e la lettura dei log.

Scaricare prima la cache DNS

Perché? Scaricando la cache DNS, si avviano i test con uno slate pulito. Cancellando la cache, si reimposta il contenuto del resolver DNS sulle voci più aggiornate. Tenere presente che uno scaricamento non rimuove le voci del file HOST. Se si usano ampiamente le voci del file HOST, è necessario copiare tali voci in un file in un'altra directory e quindi svuotare il file HOST.

Scaricare la cache del resolver DNS

1. Aprire il prompt dei comandi( Start>Run>cmd o Windows key>cmd).

2. Digitare il comando seguente e premere INVIO:

   ipconfig /flushdns
   

Netmon

Lo strumento di monitoraggio della rete (Netmon) di Microsoft analizza i pacchetti (traffico di rete) che passano tra i computer nelle reti. Usando Netmon per tracciare il traffico con Office 365 è possibile acquisire, visualizzare e leggere intestazioni di pacchetti, identificare i dispositivi intermedi, controllare le impostazioni importanti nell'hardware di rete, cercare i pacchetti eliminati e seguire il flusso del traffico tra i computer nella rete aziendale e Office 365. Poiché il corpo effettivo del traffico è crittografato, ovvero viaggia sulla porta 443 tramite SSL/TLS, non è possibile leggere i file inviati. Si ottiene invece una traccia non filtrata del percorso gestito dal pacchetto, che consente di individuare il comportamento del problema.

Assicurarsi di non applicare un filtro in questo momento. Eseguire invece i passaggi e dimostrare il problema prima di arrestare la traccia e salvare.

Dopo aver installato Netmon 3.4, aprire lo strumento e seguire questa procedura:

Eseguire una traccia netmon e riprodurre il problema

1. Avviare Netmon 3.4. Nella pagina Iniziale sono presenti tre riquadri: Acquisizioni recenti, Selezione reti e Introduzione con Microsoft Network Monitor 3.4. Nota. Il pannello Seleziona reti fornirà anche un elenco delle reti predefinite da cui è possibile acquisire. Assicurarsi che le schede di rete siano selezionate qui.

2. Fare clic su Nuova acquisizione nella parte superiore della pagina Start . Verrà aggiunta una nuova scheda accanto alla scheda Pagina iniziale denominata Capture 1.

3. Per eseguire un'acquisizione semplice, fare clic su Avvia sulla barra degli strumenti.

4. Riprodurre i passaggi che presentano un problema di prestazioni.

5. Fare clic su Interrompi>salvataggio file>con nome. Ricordarsi di assegnare la data e l'ora con il fuso orario e di indicare se le prestazioni sono negative o buone.

HTTPWatch

HTTPWatch include addebiti e un'edizione gratuita. L'edizione Basic gratuita illustra tutto il necessario per questo test. HTTPWatch monitora il traffico di rete e l'ora di caricamento della pagina direttamente dalla finestra del browser. HTTPWatch è un plug-in di Microsoft Edge che descrive graficamente le prestazioni. L'analisi può essere salvata e visualizzata in HTTPWatch Studio.

Nota

Se si usa un altro browser, ad esempio Firefox, Google Chrome o se non è possibile installare HTTPWatch in Edge, aprire una nuova finestra del browser e premere F12 sulla tastiera. Dovrebbe essere visualizzato il popup Strumento di sviluppo nella parte inferiore del browser. Se si usa Opera, premere CTRL+MAIUSC+I per Controllo Web, quindi fare clic sulla scheda Rete e completare i test descritti di seguito. Le informazioni saranno leggermente diverse, ma i tempi di caricamento verranno comunque visualizzati in millisecondi. > HTTPWatch è anche molto utile per i problemi relativi ai tempi di caricamento delle pagine di SharePoint.

Eseguire HTTPWatch e riprodurre il problema

HTTPWatch è un plug-in del browser, quindi esporre lo strumento nel browser è leggermente diverso per ogni versione di Microsoft Edge. In genere, è possibile trovare HTTPWatch nella barra Comandi nel browser Microsoft Edge. Se il plug-in HTTPWatch non viene visualizzato nella finestra del browser, controllare la versione del browser facendo clic su Informazioni>su oppure, nelle versioni successive di Microsoft Edge, fare clic sul simbolo dell'ingranaggio e su Informazioni su Edge. Per avviare la barra Comandi , fare clic con il pulsante destro del mouse sulla barra dei menu in Microsoft Edge e scegliere Barra comandi.

In passato, HTTPWatch è stato associato alle barre Comandi e Esplora risorse, quindi dopo l'installazione, se l'icona (anche dopo il riavvio) non viene visualizzata immediatamente, selezionare Strumenti e le barre degli strumenti per l'icona. Tenere presente che le barre degli strumenti possono essere personalizzate e che è possibile aggiungervi opzioni.

1. Avviare HTTPWatch in una finestra del browser Microsoft Edge. Viene visualizzato ancorato al browser nella parte inferiore di tale finestra. Fare clic su Record.

2. Riprodurre i passaggi esatti coinvolti nel problema di prestazioni. Fare clic sul pulsante Arresta in HTTPWatch.

3. Salvare HTTPWatch o Send by Email. Ricordarsi di denominare il file in modo che includa informazioni su data e ora e un'indicazione del fatto che l'orologio contiene una dimostrazione di prestazioni buone o negative.

Questo screenshot è tratto dalla versione Professional di HTTPWatch. È possibile aprire le tracce acquisite nella versione Basic in un computer con una versione Professional e leggerle lì. Potrebbero essere disponibili informazioni aggiuntive dalla traccia tramite tale metodo.

Registrazione dei passaggi del problema

Registrazione passaggi, o PSR.exe, consente di registrare i problemi man mano che si verificano. È uno strumento molto utile e semplice da eseguire.

Eseguire registrazione dei passaggi dei problemi (PSR.exe) per registrare il lavoro

1. Usare Start>Run> type PSR.exe>OK oppure fare clic sul tipo di tasto> Windows PSR.exe> e quindi premere INVIO.

2. Quando viene visualizzata la finestra di PSR.exe piccola, fare clic su Avvia record e riprodurre i passaggi che riproducono il problema di prestazioni. È possibile aggiungere commenti in base alle esigenze facendo clic su Aggiungi commenti.

3. Dopo aver completato i passaggi, fare clic su Interrompi record . Se il problema di prestazioni è un rendering della pagina, attendere il rendering della pagina prima di arrestare la registrazione.

4. Fare clic su Salva.

La data e l'ora vengono registrate per te. In questo modo, il PSR viene collegato alla traccia Netmon e a HTTPWatch nel tempo e consente di risolvere i problemi con precisione. La data e l'ora nel record PSR possono indicare, ad esempio, che è passato un minuto tra l'accesso e l'esplorazione dell'URL e il rendering parziale del sito di amministrazione.

Leggere le tracce

Non è possibile insegnare tutto sulla risoluzione dei problemi di rete e prestazioni che qualcuno dovrebbe conoscere tramite un articolo. Ottenere prestazioni ottimali richiede esperienza e conoscenza del funzionamento e delle prestazioni della rete. Ma è possibile arrotondare un elenco di problemi principali e mostrare come gli strumenti possono semplificare l'eliminazione dei problemi più comuni.

Se vuoi acquisire competenze di lettura delle tracce di rete per i tuoi siti di Office 365, non c'è insegnante migliore della creazione di tracce di caricamenti di pagine regolarmente e acquisire esperienza di lettura. Ad esempio, quando si ha una possibilità, caricare un servizio Office 365 e tracciare il processo. Filtrare la traccia per il traffico DNS o cercare il nome del servizio visualizzato in FrameData. Analizzare la traccia per avere un'idea dei passaggi che si verificano quando il servizio viene caricato. Ciò consente di apprendere l'aspetto del normale caricamento delle pagine e, nel caso della risoluzione dei problemi, in particolare per quanto riguarda le prestazioni, il confronto tra tracce buone e non valide può insegnare molto.

Netmon usa Microsoft Intellisense nel campo Filtro di visualizzazione. Intellisense, o completamento intelligente del codice, è il trucco in cui si digita un periodo e tutte le opzioni disponibili vengono visualizzate in una casella di selezione a discesa. Ad esempio, si è preoccupati per il ridimensionamento delle finestre TCP, è possibile trovare la strada per un filtro (ad .protocol.tcp.window < 100esempio ) in questo modo.

Le tracce di Netmon possono contenere molto traffico. Se non si ha esperienza con la lettura, è probabile che si sarà sopraffatti aprendo la traccia la prima volta. La prima cosa da fare è separare il segnale dal rumore di fondo nella traccia. È stato eseguito il test rispetto a Office 365, ovvero il traffico che si vuole visualizzare. Se si è abituati a spostarsi tra le tracce, potrebbe non essere necessario questo elenco.

Il traffico tra il client e Office 365 viaggia tramite TLS, il che significa che il corpo del traffico verrà crittografato e non leggibile in una traccia Netmon generica. L'analisi delle prestazioni non deve conoscere le specifiche delle informazioni nel pacchetto. È tuttavia molto interessato alle intestazioni dei pacchetti e alle informazioni che contengono.

Suggerimenti per ottenere una buona traccia

• Conoscere il valore dell'indirizzo IPv4 o IPv6 del computer client. È possibile ottenerlo dal prompt dei comandi digitando IPConfig e quindi premendo INVIO. Conoscere questo indirizzo consente di indicare a colpo d'occhio se il traffico nella traccia coinvolge direttamente il computer client. Se è presente un proxy noto, eseguire il ping e ottenere anche il relativo indirizzo IP.

• Scaricare la cache del resolver DNS e, se possibile, chiudere tutti i browser tranne quello in cui si eseguono i test. Se non si è in grado di eseguire questa operazione, ad esempio se il supporto usa uno strumento basato su browser per visualizzare il desktop del computer client, prepararsi a filtrare la traccia.

• In una traccia occupata individuare il servizio Office 365 in uso. Se non si è mai visto o raramente il traffico in precedenza, questo è un passaggio utile per separare il problema di prestazioni da altri disturbi di rete. Esistono alcuni modi per eseguire questa operazione. Direttamente prima del test, è possibile usare ping o PsPing sull'URL del servizio specifico (ping outlook.office365.com o psping -4 microsoft-my.sharepoint.com:443, ad esempio). È anche possibile trovare facilmente il ping o PsPing in una traccia netmon (con il nome del processo). Questo ti darà un posto dove iniziare a cercare.

Se si usa la traccia netmon solo al momento del problema, va bene anche questo. Per orientarsi, usare un filtro come ContainsBin(FrameData, ASCII, "office") o ContainsBin(FrameData, ASCII, "outlook"). È possibile registrare il numero di fotogrammi dal file di traccia. È anche possibile scorrere il riquadro Riepilogo frame fino a destra e cercare la colonna ID conversazione. È presente un numero indicato per l'ID di questa conversazione specifica che è anche possibile registrare e esaminare in isolamento in un secondo momento. Ricordarsi di rimuovere questo filtro prima di applicare qualsiasi altro filtro.

Consiglio

Netmon ha molti filtri predefiniti utili. Provare il pulsante Filtro di carico nella parte superiore del riquadro Filtro di visualizzazione .

Acquisire familiarità con il traffico e imparare a individuare le informazioni necessarie. Ad esempio, informazioni su come determinare quale pacchetto nella traccia contiene il primo riferimento al servizio Office 365 in uso ,ad esempio "Outlook".

Prendendo Office 365 Outlook Online come esempio, il traffico inizia in questo modo:

• Query standard DNS e risposta DNS per outlook.office365.com con id query corrispondenti. È importante notare l'offset temporale per questo turn-around e dove nel mondo il DNS globale Office 365 invia la richiesta di risoluzione dei nomi. Idealmente, il più localmente possibile, piuttosto che a metà del mondo.

• Richiesta HTTP GET il cui rapporto di stato è stato spostato in modo permanente (301)

• Traffico RWS, incluse le richieste RWS Connect e le risposte connect. Si tratta di Winsock remoto che effettua automaticamente una connessione.

• Conversazione TCP SYN e TCP SYN/ACK. Molte impostazioni in questa conversazione influiscono sulle prestazioni.

• Viene quindi eseguita una serie di traffico TLS:TLS, in cui si svolgono le conversazioni dell'handshake TLS e del certificato TLS. Tenere presente che i dati vengono crittografati tramite SSL/TLS.

Tutte le parti del traffico sono importanti e connesse, ma piccole parti della traccia contengono informazioni importanti in termini di risoluzione dei problemi di prestazioni, quindi ci concentreremo su tali aree. Inoltre, poiché in Microsoft sono stati eseguiti sufficienti Office 365 risoluzione dei problemi relativi alle prestazioni per compilare un elenco dei primi 10 problemi comuni, ci concentreremo su questi problemi e su come usare gli strumenti necessari per eseguirne il root.

Se non sono già stati installati, la matrice seguente usa diversi strumenti dove possibile. Vengono forniti collegamenti ai punti di installazione. L'elenco include strumenti di traccia di rete comuni, ad esempio Netmon e Wireshark, ma usa qualsiasi strumento di traccia con cui si ha familiarità e in cui si è abituati a filtrare il traffico di rete. Quando si esegue il test, ricordare:

• Chiudere i browser e testare con un solo browser in esecuzione : in questo modo si ridurrà il traffico complessivo acquisito. Consente di eseguire una traccia meno occupata.
• Scaricare la cache del resolver DNS nel computer client . In questo modo, quando si inizia a eseguire l'acquisizione, verrà visualizzata una lista pulita per una traccia più pulita.

Problemi comuni

Alcuni problemi comuni che potrebbero verificarsi e come trovarli nella traccia di rete.

Scalabilità tcp-windows

Disponibile in SYN - SYN/ACK. L'hardware legacy o obsoleto potrebbe non sfruttare il ridimensionamento delle finestre TCP. Senza le impostazioni di ridimensionamento delle finestre TCP appropriate, il buffer a 16 bit predefinito nelle intestazioni TCP viene compilato in millisecondi. Il traffico non può continuare a essere inviato fino a quando il client non riceve una conferma che i dati originali sono stati ricevuti, causando ritardi.

Strumenti

• Netmon
• Wireshark

Cosa cercare

Cercare il traffico SYN - SYN/ACK nella traccia di rete. In Netmon usare un filtro come tcp.flags.syn == 1. Questo filtro è lo stesso in Wireshark.

Si noti che per ogni SYN è presente un numero di porta di origine (SrcPort) corrispondente nella porta di destinazione (DstPort) del riconoscimento correlato (SYN/ACK).

Per visualizzare il valore di ridimensionamento di Windows usato dalla connessione di rete, espandere prima il SYN e quindi il syn/ACK correlato.

Impostazioni del tempo di inattività TCP

In passato, la maggior parte delle reti perimetrali è configurata per le connessioni temporanee, ovvero le connessioni inattive vengono in genere terminate. Le sessioni TCP inattive possono essere terminate da proxy e firewall con valori superiori a 100-300 secondi. Questo problema è problematico per Outlook Online perché crea e usa connessioni a lungo termine, indipendentemente dal fatto che siano inattive o meno.

Quando le connessioni vengono terminate da dispositivi proxy o firewall, il client non viene informato e un tentativo di usare Outlook Online significa che un computer client tenterà, ripetutamente, di ripristinare la connessione prima di crearne una nuova. È possibile che si verifichino blocchi nel prodotto, richieste o prestazioni lente al caricamento della pagina.

Strumenti

• Netmon
• Wireshark

Cosa cercare

In Netmon esaminare il campo Offset ora per un round trip. Un round trip è il tempo tra l'invio di una richiesta al server da parte del client e la ricezione di una risposta. Controllare tra il client e il punto di uscita (ad esempio Client --> Proxy) o il client da Office 365 (Client --> Office 365). È possibile visualizzarlo in molti tipi di pacchetti.

Ad esempio, il filtro in Netmon può essere simile .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12a o, in Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Consiglio

Non si sa se l'indirizzo IP nella traccia appartiene al server DNS? Provare a cercarlo nella riga di comando. Fare clic su Avvia>Esegui> e digitare cmd oppure premere Tasto> Windows e digitare cmd. Al prompt digitare nslookup <the IP address from the network trace>. Per eseguire il test, usare nslookup sull'indirizzo IP del proprio computer. >Per visualizzare un elenco degli intervalli IP di Microsoft, vedere Office 365 URL e intervalli di indirizzi IP.

Se si verifica un problema, si prevede che vengano visualizzati offset di tempo lunghi, in questo caso (Outlook Online), in particolare nei pacchetti TLS:TLS che mostrano il passaggio dei dati dell'applicazione (ad esempio, in Netmon è possibile trovare pacchetti di dati dell'applicazione tramite .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Dovrebbe essere visualizzata una progressione uniforme nel tempo durante la sessione. Se si verificano lunghi ritardi durante l'aggiornamento di Outlook Online, questo potrebbe essere causato da un alto livello di reimpostazioni inviate.

Latenza/round trip time

La latenza è una misura che può cambiare molto a seconda di molte variabili, ad esempio l'aggiornamento dei dispositivi obsoleti, l'aggiunta di un numero elevato di utenti a una rete e la percentuale di larghezza di banda complessiva utilizzata da altre attività in una connessione di rete.

In questa pagina Pianificazione della rete e ottimizzazione delle prestazioni per Office 365 sono disponibili calcolatrici della larghezza di banda per Office 365.

È necessario misurare la velocità della connessione o la larghezza di banda della connessione ISP? Provare questo sito (o siti come questo): Sito ufficiale speedtest o eseguire una query sul motore di ricerca preferito per il test di velocità delle frasi.

Strumenti

• Ping
• PsPing
• Netmon
• Wireshark

Cosa cercare

Per tenere traccia della latenza in una traccia, si trarrà vantaggio dalla registrazione dell'indirizzo IP del computer client e dell'indirizzo IP del server DNS in Office 365. Questo è per un filtro di traccia più semplice. Se ci si connette tramite un proxy, sono necessari l'indirizzo IP del computer client, l'indirizzo IP proxy/in uscita e l'indirizzo IP DNS Office 365, per semplificare il lavoro.

Una richiesta ping inviata a outlook.office365.com indicherà il nome del data center che riceve la richiesta, anche se ping potrebbe non essere in grado di connettersi per inviare i pacchetti ICMP consecutivi del marchio. Se si usa PsPing (uno strumento gratuito per il download) e si specifica la porta (443) e forse per usare IPv4 (-4) si otterrà un tempo medio di round trip per i pacchetti inviati. Questa operazione funzionerà per altri URL nei servizi di Office 365, ad esempio psping -4 yourSite.sharepoint.com:443. In effetti, è possibile specificare un numero di ping per ottenere un campione più grande per la media, provare qualcosa come psping -4 -n 20 yourSite-my.sharepoint.com:443.

Nota

PsPing non invia pacchetti ICMP. Esegue il ping con pacchetti TCP su una porta specifica, in modo da poter usare uno qualsiasi che si conosce per essere aperto. In Office 365, che usa SSL/TLS, provare a collegare la porta :443 a PsPing.

Se è stata caricata la pagina di Office 365 con prestazioni lente durante l'esecuzione di una traccia di rete, è necessario filtrare una traccia Netmon o Wireshark per DNS. Questo è uno degli INDIRIZZI IP che stiamo cercando.

Ecco i passaggi da eseguire per filtrare Netmon per ottenere l'indirizzo IP (e esaminare la latenza DNS). Questo esempio usa outlook.office365.com, ma può anche usare l'URL di un tenant di SharePoint (hithere.sharepoint.com ad esempio).

1. Effettuare il ping dell'URL ping outlook.office365.com e, nei risultati, registrare il nome e l'indirizzo IP del server DNS a cui è stata inviata la richiesta ping.
2. Traccia di rete che apre la pagina o esegue l'azione che causa il problema di prestazioni oppure, se viene visualizzata una latenza elevata sul ping stesso, la traccia di rete.
3. Aprire la traccia in Netmon e filtrare per DNS (questo filtro funziona anche in Wireshark, ma fa distinzione tra maiuscole e minuscole -- dns). Poiché si conosce il nome del server DNS dal ping, è anche possibile filtrare più rapidamente in Netmon come questo: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), simile al seguente in Wireshark dns e frame contiene "namnorthwest".
   Aprire il pacchetto di risposta e, nella finestra Netmon Frame Details (Dettagli fotogrammi Netmon) fare clic su DNS per espandere per altre informazioni. Nelle informazioni DNS è disponibile l'indirizzo IP del server DNS a cui è stata inviata la richiesta in Office 365. Questo indirizzo IP sarà necessario per il passaggio successivo (lo strumento PsPing). Rimuovere il filtro, fare clic con il pulsante destro del mouse sulla risposta DNS in Netmon (DNSRicerca conversazioni>riepiloga frame>) per visualizzare la query e la risposta DNS affiancate.
4. In Netmon si noti anche la colonna Offset ora tra la richiesta DNS e la risposta. Nel passaggio successivo, lo strumento PsPing facile da installare e usare è molto utile, sia perché ICMP è spesso bloccato nei firewall, sia perché PsPing tiene traccia elegantemente della latenza in millisecondi. PsPing completa una connessione TCP a un indirizzo e una porta (nel nostro caso aprire la porta 443).
5. Installare PsPing.
6. Aprire un prompt dei comandi (Start > Run > type cmd o Windows Key > type cmd) e passare alla directory in cui è stato installato PsPing per eseguire il comando PsPing. Nei miei esempi è possibile vedere che ho creato una cartella "Perf" nella radice di C. È possibile eseguire la stessa operazione per l'accesso rapido.
7. Digitare il comando in modo che si stia eseguendo psping in base all'indirizzo IP del server DNS Office 365 dalla traccia di Netmon precedente, incluso il numero di porta, ad esempio psping -n 20 132.245.24.82:445. In questo modo si otterrà un campionamento di 20 ping e la latenza media quando PsPing si arresta.

Se si intende Office 365 tramite un server proxy, i passaggi sono leggermente diversi. Prima di tutto, eseguire PsPing nel server proxy per ottenere un valore medio di latenza in millisecondi per proxy/uscita e ritorno, quindi eseguire PsPing nel proxy o in un computer con una connessione Internet diretta per ottenere il valore mancante (quello da Office 365 e indietro).

Se si sceglie di eseguire PsPing dal proxy, si avranno due valori di millisecondi: computer client al server proxy o punto di uscita e server proxy da Office 365. E hai finito! Beh, registrare i valori, comunque.

Se si esegue PsPing in un altro computer client con una connessione diretta a Internet, ovvero senza un proxy, si avranno due valori di millisecondi: computer client al server proxy o punto di uscita e computer client da Office 365. In questo caso, sottrarre il valore del computer client al server proxy o al punto di uscita dal valore del computer client a Office 365 e si avranno i numeri RTT dal computer client al server proxy o al punto di uscita e dal server proxy o dal punto di uscita a Office 365.

Tuttavia, se è possibile trovare un computer client nella posizione interessata direttamente connessa o ignorare il proxy, è possibile scegliere se il problema viene riprodotto per iniziare e quindi testarne l'uso.

La latenza, come illustrato in una traccia di Netmon, può essere sommata a un numero sufficiente di millisecondi in una determinata sessione.

Nota

L'indirizzo IP può essere diverso dagli INDIRIZZI IP indicati qui, ad esempio il ping può restituire un valore simile a 157.56.0.0/16 o un intervallo simile. Per un elenco degli intervalli usati da Office 365, vedere Office 365 URL e intervalli di indirizzi IP.

Ricordarsi di espandere tutti i nodi (c'è un pulsante nella parte superiore per questo) se si vuole cercare, ad esempio, 132.245.

Autenticazione proxy

Questo vale solo se si sta passando attraverso un server proxy. In caso contrario, è possibile ignorare questi passaggi. Quando funziona correttamente, l'autenticazione proxy deve avvenire in millisecondi, in modo coerente. Non dovrebbero essere visualizzate prestazioni non ottimali intermittenti durante i periodi di utilizzo di picco,ad esempio.

Se l'autenticazione proxy è attivata, ogni volta che si crea una nuova connessione TCP per Office 365 per ottenere informazioni, è necessario passare un processo di autenticazione dietro le quinte. Ad esempio, quando si passa da Calendario a Posta elettronica in Outlook Online, si esegue l'autenticazione. In SharePoint, se in una pagina vengono visualizzati supporti o dati da più siti o posizioni, si eseguirà l'autenticazione per ogni connessione TCP diversa necessaria per eseguire il rendering dei dati.

In Outlook Online, è possibile che si verifichino tempi di caricamento lenti ogni volta che si passa da Calendario a una cassetta postale o a caricamenti di pagine lente in SharePoint. Tuttavia, ci sono altri sintomi non elencati qui.

L'autenticazione proxy è un'impostazione nel server proxy in uscita. Se causa un problema di prestazioni con Office 365, è necessario consultare il team di rete.

Strumenti

• Netmon
• Wireshark

Cosa cercare

L'autenticazione proxy viene eseguita ogni volta che deve essere avviata una nuova sessione TCP, in genere per richiedere file o informazioni dal server o per fornire informazioni. Ad esempio, è possibile che venga visualizzata l'autenticazione proxy per le richieste HTTP GET o HTTP POST. Per visualizzare i frame in cui si autenticano le richieste nella traccia, aggiungere la colonna 'NTLMSSP Summary' a Netmon e filtrare per .property.NTLMSSPSummary. Per vedere quanto tempo richiede l'autenticazione, aggiungere la colonna Delta ora.

Per aggiungere una colonna a Netmon:

1. Fare clic con il pulsante destro del mouse su una colonna, ad esempio Descrizione.
2. Fare clic su Scegli colonne.
3. Individuare Riepilogo NTLMSSP e Delta ora nell'elenco e fare clic su Aggiungi.
4. Spostare le nuove colonne sul posto prima o dietro la colonna Descrizione in modo da poterle leggere affiancate.
5. Fare clic su OK.

Anche se non si aggiunge la colonna, il filtro Netmon funzionerà. Tuttavia, la risoluzione dei problemi sarà molto più semplice se si può vedere in quale fase dell'autenticazione ci si sta.

Quando si cercano istanze di Autenticazione proxy, assicurarsi di studiare tutti i frame in cui è presente una richiesta NTLM o è presente un messaggio di autenticazione. Se necessario, fare clic con il pulsante destro del mouse sulla parte specifica del traffico e su Trova conversazioni > TCP. Tenere presente i valori delta del tempo in queste conversazioni.

Ritardo di quattro secondi nell'autenticazione proxy, come illustrato in Wireshark. Il delta dell'ora della colonna cornice visualizzata precedente è stato creato facendo clic con il pulsante destro del mouse sul campo con lo stesso nome nei dettagli del frame e selezionando Aggiungi come colonna.

Prestazioni DNS

La risoluzione dei nomi funziona al meglio e più rapidamente quando si verifica il più vicino possibile al paese/area geografica del client.

Se la risoluzione dei nomi DNS viene eseguita all'estero, può aggiungere secondi al caricamento della pagina. Idealmente, la risoluzione dei nomi avviene in meno di 100 ms. In caso contrario, è consigliabile eseguire ulteriori indagini.

Consiglio

Non si è certi del funzionamento della connettività client in Office 365? Vedere il documento Riferimento alla connettività client qui.

Strumenti

• Netmon
• Wireshark
• PsPing

Cosa cercare

L'analisi delle prestazioni DNS è in genere un altro processo per una traccia di rete. Tuttavia, PsPing è anche utile per decidere o escludere una possibile causa.

Il traffico DNS si basa sulle richieste TCP e UDP e le risposte sono chiaramente contrassegnate con un ID che consentirà di associare una richiesta specifica alla risposta specifica. Verrà visualizzato il traffico DNS quando, ad esempio, SharePoint usa un nome di rete o un URL in una pagina Web. Come regola generale, la maggior parte di questo traffico, ad eccezione del trasferimento delle zone, viene eseguito su UDP.

Sia in Netmon che in Wireshark, il filtro più semplice che consente di esaminare il traffico DNS è semplicemente dns. Assicurarsi di usare lettere minuscole quando si specifica il filtro. Ricordarsi di scaricare la cache del resolver DNS prima di iniziare a riprodurre il problema nel computer client. Ad esempio, se il caricamento della pagina di SharePoint per la home page è lento, è necessario chiudere tutti i browser, aprire un nuovo browser, avviare la traccia, scaricare la cache del resolver DNS e passare al sito di SharePoint. Dopo aver risolto l'intera pagina, è necessario arrestare e salvare la traccia.

Si vuole esaminare l'offset dell'ora qui. E potrebbe essere utile aggiungere la colonna Time Delta a Netmon che è possibile eseguire completando questi passaggi:

1. Fare clic con il pulsante destro del mouse su una colonna, ad esempio Descrizione.
2. Fare clic su Scegli colonne.
3. Individuare Time Delta nell'elenco e fare clic su Aggiungi.
4. Spostare la nuova colonna in posizione prima o dietro la colonna Descrizione in modo da poterle leggere affiancate.
5. Fare clic su OK.

Se si trova una query di interesse, è consigliabile isolarla facendo clic con il pulsante destro del mouse sulla query nel pannello dei dettagli del frame, scegliendo Trova DNS conversazioni>. Si noti che il pannello Conversazioni di rete passa direttamente alla conversazione specifica nel log del traffico UDP.

In Wireshark è possibile creare una colonna per l'ora DNS. Eseguire la traccia (o aprire una traccia) in Wireshark e filtrare in base dnsa o, più utile, dns.time. Fare clic su qualsiasi query DNS e, nel pannello con i dettagli, espandere i Domain Name System (response) dettagli. Verrà visualizzato un campo per il tempo, [Time: 0.001111100 seconds]ad esempio . Fare clic con il pulsante destro del mouse questa volta e scegliere Applica come colonna. In questo modo verrà visualizzata una colonna Ora per un ordinamento più rapido della traccia. Fare clic sulla nuova colonna per ordinare in base ai valori decrescenti per vedere quale chiamata DNS ha impiegato più tempo per la risoluzione.

Esplorazione di SharePoint filtrata in Wireshark in base a dns.time (minuscolo), con l'ora dei dettagli inseriti in una colonna e ordinati in ordine crescente.

Se si vuole eseguire un'analisi più approfondita del tempo di risoluzione DNS, provare un psping sulla porta DNS usata da TCP , psping <IP address of DNS server>:53ad esempio . Viene ancora visualizzato un problema di prestazioni? In tal caso, è più probabile che il problema sia un problema di rete più ampio rispetto a un problema di applicazione DNS specifica che si sta verificando per la risoluzione. Vale anche la pena ricordare, ancora una volta, che un ping a outlook.office365.com vi dirà dove la risoluzione dei nomi DNS per Outlook Online è in corso (ad esempio, outlook-namnorthwest.office365.com).

Se il problema sembra essere specifico di DNS, potrebbe essere necessario contattare il reparto IT per esaminare le configurazioni DNS e i server d'inoltro DNS per analizzare ulteriormente il problema.

Scalabilità proxy

Servizi come Outlook Online in Office 365 concedere ai client più connessioni a lungo termine. Pertanto, ogni utente potrebbe usare più connessioni che richiedono una durata più lunga.

Strumenti

Matematica

Cosa cercare

Non è disponibile alcun strumento di traccia di rete o di risoluzione dei problemi specifico. Al contrario, si basa sui calcoli della larghezza di banda dati limitazioni e altre variabili.

Dimensioni massime segmento TCP

Disponibile in SYN - SYN/ACK. Eseguire questo controllo in qualsiasi traccia di rete delle prestazioni eseguita per assicurarsi che i pacchetti TCP siano configurati per trasportare la quantità massima di dati possibile.

L'obiettivo è visualizzare un mss di 1.460 byte per la trasmissione dei dati. Se si è dietro un proxy o si usa un NAT, ricordarsi di eseguire questo test dal client al proxy/egress/NAT e da proxy/egress/NAT a Office 365 per ottenere risultati ottimali. Si tratta di sessioni TCP diverse.

Strumenti

Netmon

Cosa cercare

TCP Max Segment Size (MSS) è un altro parametro dell'handshake a tre vie nella traccia di rete che indica che i dati necessari sono disponibili nel pacchetto SYN - SYN/ACK. MSS è piuttosto semplice da vedere.

Aprire qualsiasi traccia di rete delle prestazioni disponibile e individuare la connessione di cui si è curiosi o che dimostra il problema di prestazioni.

Nota

Se si sta esaminando una traccia ed è necessario trovare il traffico rilevante per la conversazione, filtrare in base all'IP del client o all'INDIRIZZO IP del server proxy o del punto di uscita o entrambi. Andando direttamente, sarà necessario effettuare il ping dell'URL che si sta testando per l'indirizzo IP di Office 365 nella traccia e filtrare in base a esso.

Guardando la traccia di seconda mano? Provare a usare i filtri per orientarsi. In Netmon eseguire una ricerca in base all'URL, ad Containsbin(framedata, ascii, "sphybridExample")esempio , prendere nota del numero di fotogrammi.

In Wireshark usare qualcosa di simile frame contains "sphybridExample"a . Se si nota che è stato rilevato traffico Winsock remoto (RWS) (che potrebbe apparire come [PSH, ACK] in Wireshark), tenere presente che la connessione RWS può essere visualizzata poco prima dei SYN - SYN/ACK rilevanti, come illustrato in precedenza.

A questo punto, è possibile registrare il numero di fotogramma, eliminare il filtro e fare clic su Tutto il traffico nella finestra Conversazioni di rete in Netmon per esaminare il SYN più vicino.

È importante notare che, se non sono state ricevute informazioni sull'indirizzo IP al momento della traccia, la ricerca dell'URL nella traccia (parte di sphybridExample-my.sharepoint.com, ad esempio), fornirà gli indirizzi IP in base ai quali filtrare.

Individuare la connessione nella traccia a cui si è interessati. A tale scopo, è possibile analizzare la traccia, filtrare in base agli indirizzi IP o selezionare ID di conversazione specifici usando la finestra Conversazioni di rete in Netmon. Dopo aver trovato il pacchetto SYN, espandere TCP (in Netmon) o Transmission Control Protocol (in Wireshark) nel pannello Dettagli frame. Espandere Opzioni TCP e MaxSegmentSize. Individuare il frame SYN-ACK correlato ed espandere Opzioni TCP e MaxSegmentSize. Il valore più piccolo dei due valori sarà la dimensione massima del segmento. In questa immagine viene usata la colonna predefinita in Netmon denominata risoluzione dei problemi TCP.

La colonna predefinita si trova nella parte superiore del pannello Dettagli frame . Per tornare alla visualizzazione normale, fare di nuovo clic su Colonne e quindi scegliere Fuso orario.

Ecco una traccia filtrata in Wireshark. È disponibile un filtro specifico per il valore MSS (tcp.options.mss). I fotogrammi di un handshake SYN, SYN/ACK, ACK sono collegati nella parte inferiore di Wireshark equivalente a Dettagli frame (quindi il fotogramma 47 ACK, i collegamenti a 46 SYN/ACK, i collegamenti a 43 SYN) per semplificare questo tipo di lavoro.

Se è necessario controllare il riconoscimento selettivo (argomento successivo in questa matrice), non chiudere la traccia.

Riconoscimento selettivo

Disponibile in SYN - SYN/ACK. Deve essere segnalato come Consentito sia in SYN che in SYN/ACK. Il riconoscimento selettivo (SACK) consente una ritrasmissione più uniforme dei dati quando manca un pacchetto o un pacchetto. I dispositivi possono disabilitare questa funzionalità, che può causare problemi di prestazioni.

Se si è dietro un proxy o si usa un NAT, ricordarsi di eseguire questo test dal client al proxy/egress/NAT e da proxy/egress/NAT a Office 365 per ottenere risultati ottimali. Si tratta di sessioni TCP diverse.

Strumenti

Netmon

Cosa cercare

Il riconoscimento selettivo (SACK) è un altro parametro nell'handshake SYN-SYN/ACK. È possibile filtrare la traccia per SYN - SYN/ACK in molti modi.

Individuare la connessione nella traccia a cui si è interessati analizzando la traccia, filtrando in base agli indirizzi IP o facendo clic su un ID conversazione usando la finestra Conversazioni di rete in Netmon. Dopo aver trovato il pacchetto SYN, espandere TCP in Netmon o Transmission Control Protocol in Wireshark nella sezione Dettagli frame. Espandere Opzioni TCP e quindi SACK. Individuare il frame SYN-ACK correlato ed espandere Opzioni TCP e il relativo campo SACK. Assicurarsi che SACK sia consentito sia in SYN che in SYN/ACK. Di seguito sono riportati i valori SACK visualizzati sia in Netmon che in Wireshark.

Georilevazione DNS

Dove nel mondo Office 365 tenta di risolvere la chiamata DNS influisce sulla velocità di connessione.

In Outlook Online, dopo aver completato la prima ricerca DNS, verrà usata la posizione di tale DNS per connettersi al data center più vicino. Si sarà connessi a un server CAS di Outlook Online, che userà la rete backbone per connettersi al data center (dC) in cui sono archiviati i dati. Questo è più veloce.

Quando si accede a SharePoint, un utente che viaggia all'estero verrà indirizzato al data center attivo, ovvero il data center la cui posizione è basata sulla home base del tenant spo (quindi, un dC negli Stati Uniti se l'utente ha sede negli Stati Uniti).

Lync Online dispone di nodi attivi in più di un DC alla volta. Quando le richieste vengono inviate per le istanze di Lync Online, il DNS di Microsoft determinerà da dove proviene la richiesta e restituirà gli indirizzi IP dal DC regionale più vicino in cui è attivo Lync Online.

Consiglio

Per altre informazioni sul modo in cui i client si connettono a Office 365, Esaminare l'articolo di riferimento sulla connettività client e la relativa grafica utile.

Strumenti

• Ping
• PsPing

Cosa cercare

Le richieste di risoluzione dei nomi dai server DNS del client ai server DNS microsoft devono nella maggior parte dei casi comportare la restituzione da parte di DNS Microsoft dell'indirizzo IP di un data center (dC) a livello di area. Cosa significa questo per te? Se la sede centrale si trovano a Bengaluru, in India, ma si sta viaggiando nel Stati Uniti, quando il browser effettua una richiesta per Outlook Online, i server DNS di Microsoft devono consegnare gli indirizzi IP ai data center nel Stati Uniti, un data center a livello di area. Se è necessario inviare messaggi di posta elettronica da Outlook, questi dati verranno trasferiti attraverso la rete backbone veloce di Microsoft tra i data center.

DNS funziona più velocemente quando la risoluzione dei nomi viene eseguita il più vicino possibile alla posizione dell'utente. Se ci si trova in Europa, si vuole passare a un DNS Microsoft in Europa e (idealmente) gestire un data center in Europa. Le prestazioni di un client in Europa che accede a DNS e a un data center in America saranno più lente.

Eseguire lo strumento Ping su outlook.office365.com per determinare dove nel mondo viene instradata la richiesta DNS. Se siete in Europa, dovrebbe vedere una risposta da qualcosa come outlook-emeawest.office365.com. Nelle Americhe, aspettatevi qualcosa come outlook-namnorthwest.office365.com.

Aprire il prompt dei comandi nel computer client (tramite Start > Run > cmd o Windows key > type cmd). Digitare ping outlook.office365.com e premere INVIO. Ricordare di specificare -4 se si vuole specificare il ping tramite IPv4. Potrebbe non essere possibile ottenere una risposta dai pacchetti ICMP, ma dovrebbe essere visualizzato il nome del DNS a cui è stata instradata la richiesta. Se si vogliono visualizzare i numeri di latenza per questa connessione, provare PsPing all'indirizzo IP del server restituito dal ping.

risoluzione dei problemi delle applicazioni di Office 365

Strumenti

• Netmon
• HTTPWatch
• Console F12 nel browser

In questo articolo specifico della rete non vengono illustrati gli strumenti usati per la risoluzione dei problemi specifici dell'applicazione. Tuttavia, in questa pagina sono disponibili risorse che è possibile usare.

Articoli correlati

Gestione degli endpoint di Office 365

Domande frequenti sugli endpoint di Office 365