Piano di risoluzione dei problemi di prestazioni per Office 365.

Importante :  Il presente articolo è stato tradotto automaticamente, vedere la dichiarazione di non responsabilità. Per visualizzare la versione inglese dell'articolo, fare clic qui.

È necessario conoscere i passaggi da seguire per individuare e risolvere ritardi, si blocca e rallentare le prestazioni tra SharePoint Online, OneDrive for Business, Exchange Online o Skype for Business Online e il computer client? Prima di chiamare il supporto, in questo articolo consentono di risolvere i problemi di prestazioni di Office 365 e risolvere alcuni dei problemi più comuni.

Questo articolo è un esempio di piano d'azione che si può seguire per acquisire dati preziosi sul problema di prestazioni nel momento in cui si verifica. Sono anche indicati alcuni dei problemi principali.

Se non si ha familiarità con le prestazioni di rete e si vuole creare un piano a lungo termine per il monitoraggio delle prestazioni tra il computer client e Office 365, vedere Ottimizzazione e risoluzione dei problemi di prestazioni di Office 365 - Amministratori e professionisti IT.

Esempio di piano d'azione per la risoluzione dei problemi di prestazioni

Questo piano d'azione contiene due parti, ossia una fase di preparazione e una fase di registrazione. Se è in corso un problema di prestazioni ed è necessario eseguire una raccolta dei dati, è possibile iniziare a usare il piano immediatamente.

Preparare il computer client

  • Individuare un computer client in cui sia possibile riprodurre il problema di prestazioni. Questo computer verrà usato durante la risoluzione dei problemi.

  • Prendere nota dei passaggi che causano il verificarsi del problema in modo da essere pronti al momento del test.

  • Installare gli strumenti per raccogliere e registrare le informazioni:

    • Installare Netmon 3.4 (o uno strumento equivalente per eseguire le tracce di rete).

    • Installare la versione gratuita Basic Edition di HTTPWatch oppure usare uno strumento equivalente per eseguire le tracce di rete.

    • Usare un registratore dello schermo oppure usare lo strumento Registrazione azioni utente (PSR.exe) fornito con Windows Vista e versioni successive per mantenere un record dei passaggi eseguiti durante i test.

Registrare il problema di prestazioni

  • Chiudere tutti i browser Internet estranei.

  • Avviare Registrazione azioni utente o un altro registratore dello schermo.

  • Iniziare l'acquisizione di Netmon o dell'altro strumento di esecuzione di tracce di rete.

  • Cancellare la cache DNS nel computer client digitando ipconfig /flushdns al prompt dei comandi.

  • Avviare una nuova sessione del browser e attivare HTTPWatch.

  • (Facoltativo) Se si testa Exchange Online, eseguire lo strumento Analizzatore prestazioni di Exchange Client dalla console di amministrazione di Office 365.

  • Riprodurre i passaggi esatti che causano problemi di prestazioni.

  • Interrompere la traccia di Netmon o dell'altro strumento.

  • Sulla riga di comando eseguire una route di traccia all'abbonamento a Office 365 digitando il comando seguente e quindi premendo INVIO:

    tracert <nomeabbonamento>.onmicrosoft.com

  • Interrompere Registrazione azioni utente e salvare il video. Assicurarsi di includere la data e l'ora dell'acquisizione, annotando se le prestazioni sono risultate buone o insufficienti.

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

Se non si ha familiarità con l'esecuzione degli strumenti citati in questo articolo, vedere più avanti i passaggi necessari. Se si è abituati a eseguire questo tipo di acquisizioni di rete, è possibile passare direttamente alla sezione Come leggere le tracce che descrive come filtrare e leggere i log.

Svuotare prima di tutto la cache DNS

Perché? Svuotando la cache DNS, è possibile iniziare i test da zero. Con la cancellazione della cache, il contenuto del risolutore DNS viene reimpostato sulle voci più aggiornate. Tenere presente che uno svuotamento non rimuove le voci del file HOST. Se si usano in modo intensivo le voci del file HOST, è necessario copiarle dal file in un'altra directory e quindi svuotare il file HOST.

Svuotare la cache del Risolutore DNS

  1. Aprire il prompt dei comandi, premendo il pulsante Start > Esegui > cmd oppure il tasto WINDOWS > cmd.

  2. Digitare il comando seguente e premere INVIO:

    ipconfig /flushdns

Netmon

Microsoft Network Monitoring (Netmon) analizza pacchetti di traffico che passa tra computer sulle reti. Utilizzando Netmon per tracciare il traffico con Office 365 è possibile acquisire, visualizzazione e leggere le intestazioni dei pacchetti, identificare i dispositivi di chiamata in corso, selezionare impostazioni importanti sull'hardware di rete, cercare pacchetti ignorati e seguire il flusso di traffico tra computer collegati alla rete aziendale e Office 365. Perché il corpo effettivo del traffico è crittografato, vale a dire che (viaggi nella porta 443 tramite SSL/TLS, è possibile leggere i file inviati. Si riceverà un'analisi non filtrata del percorso che assume il pacchetto che consentono di esaminare il comportamento del problema.

Assicurarsi di non applicare un filtro in questa fase. Completare invece i passaggi ed esporre il problema prima di interrompere la traccia e salvare.

Dopo aver installato Netmon 3.4, aprire lo strumento ed eseguire questa procedura:

Eseguire una traccia di Netmon e riprodurre il problema

  1. Avviare Netmon 3.4.

    Esistono tre riquadri nella pagina iniziale: Acquisisce recenti, Selezionare reti e Guida introduttiva a Microsoft Network Monitor 3.4. Avviso. Riquadro selezionare reti anche per ottenere un elenco delle reti predefinito da cui è possibile acquisire. Assicurarsi che le schede di rete siano selezionate qui.

  2. Fare clic su New Capture nella parte superiore della paginainiziale. Verrà aggiunta una nuova scheda accanto alla scheda della paginainiziale, denominata Capture 1.

    Interfaccia utente di Nemon con i pulsanti per il nuovo contenuto acquisito, Start e Stop evidenziati.

  3. Per eseguire una semplice acquisizione, fare clic su Start sulla barra degli strumenti.

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

  5. Fare clic su Stop > File > Salva con nome. Assicurarsi di specificare la data e l'ora con il fuso orario e di annotare se le prestazioni sono buone o insoddisfacenti.

HTTPWatch

HTTPWatch risulta addebitati e un'edizione gratuita. Gratuita Basic Edition illustra tutte le informazioni che necessarie per il test. HTTPWatch monitor fase di caricamento di pagina e il traffico di rete direttamente dalla finestra del browser. HTTPWatch è un plug-in Internet Explorer che graficamente descrive le prestazioni. L'analisi può essere salvata e visualizzata nel HTTPWatch Studio.

Note : 

  • Se si usa un altro browser, ad esempio Firefox o Google Chrome oppure se non è possibile installare HTTPWatch in Internet Explorer, aprire una nuova finestra del browser e premere F12. Nella parte inferiore del browser dovrebbe comparire lo strumento di sviluppo. Se si usa Opera, premere CTRL+MAIUSC+I per aprire Web Inspector, quindi fare clic sulla scheda Network e completare i test descritti di seguito. Le informazioni saranno leggermente diversi, ma i tempi di caricamento verranno comunque visualizzati in millisecondi.

  • HTTPWatch è molto utile anche per i problemi con i tempi di caricamento delle pagine di SharePoint Online.

Eseguire HTTPWatch e riprodurre il problema

  1. HTTPWatch è un plug-in del browser, quindi l'esposizione dello strumento nel browser è leggermente diversa per ogni versione di Internet Explorer. In genere, è possibile trovare HTTPWatch nella barra dei comandi nel browser Internet Explorer.

    Se il plug-in non viene visualizzato nella finestra del browser, controllare la versione del browser facendo clic su ? > Informazioni su oppure, nelle versioni più recenti di Internet Explorer, fare clic sul simbolo dell'ingranaggio e su Informazioni su Internet Explorer. Per avviare la barra dei comandi, fare clic con il pulsante destro del mouse sulla barra dei menu in Internet Explorer e scegliere Barra dei comandi. Nel passato, HTTPWatch è stato associato sia alla barra dei comandi che alla barra di Explorer, quindi una volta installato, se l'icona non è immediatamente visibile, neanche dopo il riavvio, verificare se si trova in Strumenti e nelle barre degli strumenti. Tenere presente che le barre degli strumenti possono essere personalizzate ed è possibile aggiungervi opzioni.

    Barra degli strumenti dei comandi di Internet Explorer con l'icona HTTPWatch visualizzata.

  2. Avviare HTTPWatch in una finestra del browser Internet Explorer. Verrà visualizzato ancorato nella parte inferiore della finestra. Fare clic su Registra.

  3. Riprodurre i passaggi esatti che causano il problema di prestazioni. Fare clic sul pulsante Interrompi in HTTPWatch.

  4. Salvare HTTPWatch o inviarlo tramite posta elettronica. Assegnare al file un nome che includa le informazioni su data e ora e l'indicazione se l'analisi contiene una dimostrazione di prestazioni buone o insoddisfacenti.

    HTTPWatch con la scheda Rete visualizzata per un caricamento della home page di Office 365.

    Questo screenshot riguarda la versione Professional di HTTPWatch. È possibile aprire e leggere le tracce acquisite nella versione Basic in un computer con la versione Professionale. Con questo metodo, dalla traccia saranno disponibili informazioni aggiuntive.

Registrazione azioni utente

Registrazione azione utente, o PSR.exe, consente di registrare i problemi mentre si verificano. Si tratta di uno strumento molto utile e molto semplice da eseguire.

Eseguire registrazione azioni utente (PSR.exe) per registrare il proprio lavoro

  1. Premere il pulsante Start > Esegui > digitare PSR.exe > OK oppure premere il tasto WINDOWS > digitare PSR.exe > premere INVIO.

  2. Quando viene visualizzata la piccola finestra di PSR.exe, fare clic su Inizia registrazione e riprodurre i passaggi che generano il problema di prestazioni.

    È possibile aggiungere commenti in base alle esigenze, facendo clic su Aggiungi commenti.

  3. Fare clic su Interrompi Record quando è stata completata la procedura. Se il problema di prestazioni non è un rendering della pagina, attendere che la pagina per il rendering prima di interrompere la registrazione.

  4. Fare clic su Salva.

Schermata di Registrazione azioni utente o PSR.exe.

La data e l'ora viene registrata automaticamente. I collegamenti al PSR a traccia Netmon e HTTPWatch nel tempo e agevola la risoluzione dei problemi di precisione. La data e l'ora del record PSR può mostrare che un minuto passato tra l'account di accesso e di esplorazione, ad esempio l'URL e il rendering parziale del sito amministrazione.

Leggere le tracce

Non è possibile condensare in un articolo tutte le informazioni necessarie per la risoluzione dei problemi di rete e di prestazioni. Sono infatti necessarie competenze e una buona conoscenza del funzionamento e delle prestazioni generali della rete. Ma è possibile raccogliere un elenco dei principali problemi e dimostrare come gli strumenti possano semplificare la risoluzione di quelli più comuni.

Se si desidera sollevare competenze leggere le tracce di rete per i siti di Office 365, non esiste alcun insegnante migliore della creazione di tracce di caricamento pagina regolarmente e ottenere l'esperienza leggerle. Ad esempio, quando si dispone di un contatto, caricare un servizio di Office 365 e il processo di analisi. Filtrare la traccia per il traffico DNS oppure cercare FrameData per il nome del servizio che è stata aperta. Esaminare la traccia per avere un'idea delle operazioni che si verificano quando viene caricato il servizio. Sarà quindi possibile scoprire quali normale caricamento della pagina dovrebbe essere simile e in caso di risoluzione dei problemi, in particolare per prestazioni ottimali, il confronto tracce utile errate possibile illustrano molte.

Netmon Usa Microsoft Intellisense nel campo filtro di visualizzazione. IntelliSense o il completamento del codice intelligente, è il trucco nel punto in cui si digita un periodo di durata e tutte le opzioni disponibili vengono visualizzate in una casella di riepilogo a discesa selezione. Se, ad esempio, si ritiene che la finestra TCP proporzioni dei caratteri, è possibile trovare il metodo per un filtro (ad esempio .protocol.tcp.window < 100) in questo modo.

Schermata di Netmon che mostra che il campo Display Filter usa Intellisense.

Traccia Netmon possono essere presenti molte il traffico in loro. Se non si è esperti leggerle, è probabile che si sovraccarico aprendo la traccia la prima volta. La prima cosa da fare è separare il segnale dal rumore nella traccia. Testati rispetto a Office 365, ovvero il traffico a cui che si desidera visualizzare. Se vengono utilizzati per esplorare le tracce, potrebbe non essere questo elenco.

Il traffico tra il client e Office 365 viaggia tramite TLS, il che significa che il corpo del traffico sarà crittografato e non sarà leggibile in una traccia generica di Netmon. Per l'analisi delle prestazioni, non è necessario conoscere le specifiche delle informazioni incluse nel pacchetto. È invece interessante esaminare le intestazioni dei pacchetti e le informazioni che contengono.

Suggerimenti per ottenere una buona traccia

  • Identificare il valore dell'indirizzo IPv4 o IPv6 del computer client. Per ottenere questa informazione, digitare IPConfig al prompt dei comandi e premere INVIO. Conoscendo questo indirizzo, sarà possibile capire immediatamente se il traffico nella traccia coinvolge direttamente il computer client. Se c'è un proxy noto, effettuare il ping per ottenere anche il suo indirizzo IP.

  • Svuotare la cache del risolutore DNS e, se possibile, chiudere tutti i browser tranne quello in cui si eseguono i test. Se non è possibile, ad esempio se il supporto usa uno strumento basato su browser per vedere il desktop del computer client in uso, prepararsi a filtrare la traccia.

  • In una traccia occupata, individuare il servizio di Office 365 in uso. Se si è mai o raramente visto il traffico prima, si tratta di un passaggio utile separare il problema di prestazioni da altro rumore di rete. Esistono alcuni modi per eseguire questa operazione. Immediatamente prima del test, è possibile utilizzare ping o PsPing all'URL del servizio specifico (ping outlook.office365.com e/o psping -4 microsoft-my.sharepoint.com:443per esempi relativi a). È possibile trovare facilmente tale PsPing in una traccia di Netmon (in base al nome di processo). In questo modo si una posizione in cui inizia la ricerca.

    È anche possibile usare solo le tracce di Netmon nel momento in cui si verifica il problema. Per orientarsi, usare un filtro come ContainsBin(FrameData, ASCII, "office") o ContainsBin(FrameData, ASCII, "outlook"). È possibile registrare il numero di frame dal file di traccia. È anche possibile scorrere il riquadro di riepilogo dei frame completamente a destra e cercare la colonna dell'ID conversazione. C'è un numero indicato per l'ID di questa specifica conversazione che è anche possibile registrare ed esaminare in isolamento più tardi. Ricordarsi di rimuovere questo filtro prima di applicarne altri.

    Suggerimento : Netmon include numerosi filtri predefiniti. IL pulsante "Load Filter" nella parte superiore del riquadro di filtro Display.

    Trovare l'indirizzo IP tramite PSPing dalla riga di comando nel computer client.

    Traccia Netmon del client che mostra lo stesso comando PSPing con il filtro TCP.Flags.Syn == 1.

    Acquisire familiarità con il traffico e scoprire come individuare le informazioni necessarie. Ad esempio, scoprire come determinare quale pacchetto nella traccia ha il primo riferimento al servizio di Office 365 in uso, come "Outlook".

Prendendo Office 365 Outlook Online come esempio, il traffico inizia in modo simile al seguente:

  • Query standard DNS e risposta DNS per outlook.office365.com con QueryID corrispondenti. È importante notare lo scostamento orario per questo turnaround, oltre all'area geografica in cui il DNS globale di Office 365 invia la richiesta per la risoluzione del nome. Idealmente, la destinazione dovrebbe essere quanto più possibile locale, invece che dall'altra parte del mondo. Queste informazioni potrebbero essere seguite da un certo traffico DNS nell'accesso online.

  • Una richiesta HTTP GET il cui stato è Spostato definitivamente (301)

  • Il traffico RWS, incluse le richieste e le risposte di connessione RWS. È Remote Winsock che esegue automaticamente una connessione.

  • Una conversazione TCP SYN e TCP SYN/ACK. Molte impostazioni in questa conversazione influire sulle prestazioni del.

  • Quindi una serie di traffico TLS:TLS, ossia dove si verificano l'handshake TLS e le conversazioni sui certificati TLS. Tenere presente che i dati sono crittografati tramite SSL/TLS.

Tutte le parti del traffico sono importanti e connesse, ma piccole sezioni della traccia contengono informazioni particolarmente importanti in termini di risoluzione dei problemi di prestazioni, quindi verranno esaminate queste aree. Inoltre, poiché in Microsoft abbiamo eseguito una quantità sufficiente di procedure di risoluzione dei problemi di prestazioni di Office 365 per compilare un elenco dei 10 problemi più comuni, ci concentreremo su questi problemi e su come usare gli strumenti disponibili per risolverli.

Se non è ancora stata eseguita l'installazione, la matrice seguente illustra gli usi di diversi strumenti. Vengono forniti i collegamenti ai punti di installazione. L'elenco include strumenti comuni per eseguire la traccia di rete, come Netmon e Wireshark, ma è possibile scegliere altri strumenti preferiti, già usati per filtrare il traffico di rete. Durante i test, tenere presente quanto segue:

  • Test con un solo browser in esecuzione e chiudere il browser - ciò riduce il traffico complessivo acquisiti. Rende per una traccia meno trafficata.

  • Svuotare la cache del risolutore DNS nel computer client. In questo modo si ottiene un ambiente pulito quando si iniziano le acquisizioni, per una traccia più pulita.

Alcuni problemi principali

Problemi comuni che possono verificarsi e come trovarli nella traccia di rete.

Problema principale

Strumento

Informazione da cercare

Ridimensionamento delle finestre TCP

  • In SYN - SYN/ACK.

  • L'hardware legacy o obsoleto potrebbe non trarre vantaggio dal ridimensionamento delle finestre TCP.

  • Senza impostazioni appropriate, il buffer di 16 bit predefinito nelle intestazioni TCP si riempie in pochi millisecondi.

  • Il traffico non può continuare a inviare finché il client non riceve una conferma di ricezione dei dati originali, causando ritardi.

Netmon

Wireshark

Cercare il traffico SYN - SYN/ACK nella traccia di rete.

In Netmon, usare un filtro come tcp.flags.syn == 1. Il filtro è lo stesso in Wireshark.

Filtro in Netmon o Wireshark per i pacchetti Syn per entrambi gli strumenti: TCP.Flags.Syn == 1.

Si noti che per ogni SYN c'è un numero di porta (SrcPort) corrispondente nella porta di destinazione (DstPort) della conferma correlata (SYN/ACK).

Per vedere il valore di ridimensionamento delle finestre usate dalla connessione di rete, espandere prima l'elemento SYN e quindi il SYN/ACK correlato.

Immagine che illustra come associare SrcPort a DstPort in una traccia, per ottenere il delta del tempo.

Impostazioni del tempo di inattività TCP

  • Storicamente, la maggior parte delle reti perimetrali sono configurate per connessioni temporanee, il che significa che le connessioni inattive vengono in genere terminate.

  • Le sessioni TCP inattive possono essere terminate da proxy e firewall dopo più di 100-300 secondi.

  • Si tratta di un problema 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 implica che il computer client tenterà ripetutamente di ristabilire la connessione prima di effettuarne una nuova.

  • Si possono riscontrare interruzioni nel prodotto, messaggi o prestazioni lente nel caricamento di pagine.

Netmon

Wireshark

In Netmon cercare un round trip nel campo Time Offset. Un round trip è il tempo che intercorre tra l'invio di una richiesta dal client al server e la ricezione di una risposta. Controllare tra il client e il punto di uscita, ad esempio client --> proxy, o tra il client e Office 365. Questa situazione si verifica in molti tipi di pacchetti.

Ad esempio, il filtro in Netmon potrebbe apparire come .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12o, in Wireshark ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Suggerimenti : 

  • Se non si sa se l'indirizzo IP nella traccia appartiene al server DNS, cercare questa informazioni tramite la riga di comando. Fare clic sul pulsante Start > Esegui > e digitare cmd oppure premere il tasto WINDOWS > e digitare cmd. Al prompt digitare nslookup <the IP address from the network trace>. Per verifica, usare nslookup con l'indirizzo IP del proprio computer.

  • Per visualizzare un elenco di indirizzi IP Microsoft, vedere URL e intervalli di indirizzi IP di Office 365.

Se si è verificato un problema, previsto lungo tempo agli offset viene visualizzato, in questo caso (Outlook Online), in particolare in pacchetti TLS:TLS che mostrano il passaggio dei dati dell'applicazione (ad esempio, in Netmon è possibile trovare i pacchetti di dati dell'applicazione tramite .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). Verrà visualizzata una progressione graduale nel tempo attraverso la sessione. Se viene visualizzato ritardi quando si aggiorna il Outlook Online, può trattarsi di un elevato Reimposta inviato.

Latenza/tempo di round trip

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

  • Nella pagina Pianificazione della rete e ottimizzazione delle prestazioni per Office 365 sono disponibili strumenti per calcolare la larghezza di banda per Office 365.

  • Se è necessario misurare la velocità della propria connessione o la larghezza di banda della connessione dell'ISP, provare a visitare questo sito (o siti simili): sito ufficiale Speedtest e Pingtest.

Ping

PsPing

Netmon

Wireshark

Per controllare la latenza in una traccia, la registrazione dell'indirizzo IP del computer client e dell'indirizzo IP del server DNS in Office 365 si rivelerà utile. Lo scopo è semplificare il filtro delle tracce. Se ci si connette tramite un proxy, è necessario conoscere l'indirizzo IP del computer client, l'indirizzo IP del proxy/punto di uscita e l'indirizzo IP del DNS di Office 365 per semplificare il lavoro.

Una richiesta ping inviata a outlook.office365.com indicherà il nome del data center che la riceve, anche se il ping potrebbe non essere in grado di connettersi per inviare i pacchetti ICMP consecutivi con marchio. Se si usa PsPing (uno strumento gratuito disponibile per il download) e si specifica la porta (443) e magari di usare IPv4 (-4), si ottiene un tempo medio di round trip per i pacchetti inviati. Si può ottenere lo stesso risultato per altri URL dei servizi di Office 365, ad esempio psping -4 yourSite.sharepoint.com:443. Infatti, è possibile specificare un numero di ping per ottenere un campione più ampio per la media, ad esempio provando con qualcosa di tipo psping -4 -n 20 yourSite-my.sharepoint.com:443.

Nota : PsPing non invia pacchetti ICMP. Effettua il ping con i pacchetti TCP su una specifica porta, quindi è possibile usarne una qualsiasi aperta. In Office 365, che usa SSL/TLS, provare a collegare la porta 443 a PsPing.

Schermata che illustra un ping che risolve outlook.office365.com e un PSPing con il 443 che esegue le stesse operazioni ma che riporta anche un RTT medio di 6,5 ms.

Se la pagina di Office 365 con prestazioni lente è stata caricata durante l'esecuzione di una traccia di rete, è consigliabile filtrare una traccia di Netmon o Wireshark per ottenere il DNS. Questo è uno degli indirizzi IP da cercare.

Ecco i passaggi da seguire per filtrare Netmon in modo da ottenere l'indirizzo IP ed esaminare la latenza del DNS. Questo esempio usa outlook.office365.com, ma potrebbe anche usare l'URL di un tenant di SharePoint Online, ad esempio hithere.sharepoint.com.

  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 di ping.

    Richiesta di Ping ad outlook.office365.com che mostra il DNS e l'indirizzo IP di namnorthwest.

  2. Rete monitorare l'apertura della pagina o eseguire l'azione che fornisce il problema di prestazioni, oppure, se si registra una latenza elevata del ping stesso, rete.

  3. Aprire la traccia in Netmon e filtrare per ottenere il DNS (questo filtro funziona anche in Wireshark, ma con distinzione tra maiuscole e minuscole, dns). Poiché il nome del server DNS ottenuto dal ping è noto, è anche possibile filtrare più velocemente in Netmon in questo modo: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"), che è simile in Wireshark dns and frame contains "namnorthwest".

    Aprire il pacchetto della risposta e, nella finestra Frame Details di Netmon, fare clic su DNS per espanderlo e visualizzare altre informazioni. Nelle informazioni sul DNS si troverà l'indirizzo IP del server DNS a cui è stata inviata la richiesta in Office 365. Questo indirizzo IP sarà necessario nel passaggio successivo (strumento PsPing). Rimuovere il filtro, fare clic con il pulsante destro del mouse su DNS Response in Frame Summary > Find Conversations > DNS per vedere la query e la risposta sul DNS affiancate.

    Traccia filtrata per Trova conversazioni quindi per DNS.

  4. In Netmon osservare anche la colonna Time Offset tra la richiesta e la risposta sul DNS.

    Altri risultati di Netmon filtrati con DNS AND CONTAINSBIN(Framedata, ASCII, "namnorthwest") che mostrano una differenza di orario molto ridotta tra richiesta e risposta.

Nel passaggio successivo per installare e usare PsPing strumento risulta molto utile, poiché ICMP spesso è bloccato su firewall e poiché PsPing tiene traccia in modo ottimale latenza in millisecondi. PsPing completa una connessione TCP alla porta (nel nostro caso aperta la porta 443) e indirizzo.

  1. Installare PsPing.

  2. Fare clic sul pulsante Start > Esegui > digitare cmd oppure premere il tasto WINDOWS > digitare cmd per aprire un prompt dei comandi e passare alla directory in cui è installato PsPing per eseguire il comando PsPing. In questi esempi è stata creata una cartella 'Perf' nella radice di C. È possibile fare lo stesso per un accesso rapido.

  3. Digitare il comando in modo da eseguire PsPing con l'indirizzo IP del server DNS di Office 365 dalla traccia Netmon precedente, ricordandosi di aggiungere il numero di porta, ossia psping -n 20 132.245.24.82:445. Si otterrà un campione di 20 ping e una media della latenza quando PsPing si interrompe.

    Comando psping -n 20 132.245.24.82:443 di PSPing che restituisce una latenza media di 25,51 millisecondi.

Se si accede a Office 365 tramite un server proxy, i passaggi sono leggermente diversi. È necessario prima di tutto eseguire PsPing per sul server proxy e ottenere un valore medio della latenza in millisecondi verso il proxy/punto di uscita e viceversa e quindi eseguire PsPing dal proxy o da un computer con una connessione Internet diretta per ottenere il valore mancante, quello relativo al percorso verso Office 365 e ritorno.

Se si sceglie di eseguire PsPing dal proxy, si avranno due valori in millisecondi, ossia il tempo dal computer client al server proxy o punto di uscita e dal server proxy a Office 365. E la procedura è completata, se non altro quella di registrazione dei valori.

Se si esegue PsPing in un altro computer client che è connesso direttamente a Internet, vale a dire senza un proxy, sarà necessario due valori millisecondi: il computer Client al server proxy o punto di uscita e computer client di Office 365. In questo caso, sottrarre il valore di computer client al punto di uscita o server proxy rispetto al valore del computer client di Office 365 e si avranno i numeri RTT dal computer client per il server proxy o un punto di uscita e dal punto di uscita o server proxy in Office 365.

Tuttavia, se è possibile trovare un computer client nella posizione interessata che è connesso direttamente o che ignora il proxy, è possibile scegliere di verificare prima di tutto se il problema si riproduce in questo punto e quindi di testarlo.

Latenza, come visto in una traccia di Netmon, questi millisecondi aggiuntivi possono aggiungere verso l'alto, se sono sufficienti in una specifica sessione.

Latenza generale in Netmon, con la colonna predefinita di Netmon del delta del tempo aggiunta al riepilogo dei frame.

Nota : L'indirizzo IP può essere diverso da quelli illustrati qui. Ad esempio, il ping può restituire qualcosa di tipo 157.56.0.0/16 o un intervallo simile. Per l'elenco degli indirizzi usati di Office 365, vedere URL e intervalli di indirizzi IP per Office 365. Ricordarsi di espandere tutti i nodi, usando il pulsante nella parte superiore, se si vuole cercare, ad esempio 132.245.

Autenticazione del proxy

  • Questi passaggi si applicano solo se si usa un server proxy, in caso contrario è possibile ignorarli.

  • Se funziona correttamente, l'autenticazione proxy dovrebbe richiedere sempre pochi millisecondi. Durante i periodi di picco dell'utilizzo, ad esempio, non dovrebbero registrarsi prestazioni lente intermittenti.

  • Se l'autenticazione proxy è attivata, ogni volta che si esegue una nuova connessione TCP a Office 365 per ottenere informazioni, è necessario completare un processo di autenticazione dietro le quinte. Quindi, ad esempio, quando si passa dal Calendario a Posta in Outlook Online, verrà eseguita l'autenticazione. E in SharePoint Online, se una pagina visualizza contenuti multimediali o dati di più siti o posizioni, verrà eseguita l'autenticazione per ogni connessione TCP diversa necessaria per il rendering dei dati.

  • In Outlook Online si possono riscontrare tempi di caricamento lenti ogni volta che si passa tra Calendario e la propria cassetta postale. La stessa lentezza si può registrare anche in SharePoint Online. Tuttavia, ci sono altri sintomi non elencati qui.

    Autenticazione del proxy è un'impostazione sul server proxy in uscita. Se causa problemi di prestazioni con Office 365, è necessario consultare il team di rete.

Netmon

Wireshark

Proxy autenticazione viene eseguita ogni volta che deve caricare una nuova sessione TCP verso l'alto, in genere per richiedere file o informazioni dal server o per fornire informazioni. Ad esempio, potrebbe apparire autenticazione del proxy intorno a richieste HTTP GET o HTTP POST. Se si desidera visualizzare le cornici in cui per l'autenticazione richieste nella traccia, aggiungere la colonna 'Riepilogo NTLMSSP' Netmon e il filtro per .property.NTLMSSPSummary. Per visualizzare il periodo di tempo sta impiegando l'autenticazione, aggiungere la colonna Time Delta. Per aggiungere una colonna a Netmon:

  1. Fare clic con il pulsante destro del mouse su una colonna, ad esempio Description.

  2. Scegliere Choose Columns. Individuare le colonne NTLMSSP Summary e Time Delta nell'elenco e fare clic su Add.

  3. Spostare le nuove colonne prima o dopo la colonna Description in modo da poterle vedere affiancate. Fare clic su OK.

Anche se non si aggiunge la colonna, il filtro di Netmon funzionerà. Ma la risoluzione dei problemi sarà più semplice se viene visualizzata la fase di autenticazione si sta usando. Quando è presente cercare le istanze di autenticazione del Proxy, assicurarsi che per lo Studio su campioni tutti i fotogrammi dove non c'è una richiesta di NTLM oppure un messaggio di eseguire l'autenticazione. Se necessario, rapida parte specifica del traffico e trovare le conversazioni > TCP. Prestare particolare attenzione dei valori Delta del tempo nelle conversazioni.

Traccia Netmon che illustra l'autenticazione proxy, filtrata per conversazione.

Un ritardo di quattro secondi per l'autenticazione proxy registrato in Wireshark. La colonna Time delta from previous displayed frame è stata creata facendo clic con il pulsante destro del mouse sul campo con lo stesso nome nei dettagli del frame e scegliendo Add as Column.

In Wireshark la colonna "Time delta from previous displayed frame" è stata creata facendo clic con il pulsante destro del mouse sul campo con lo stesso nome nei dettagli del frame e scegliendo Add as Column.

Prestazioni del DNS

  • La risoluzione dei nomi funziona meglio e più rapidamente se viene eseguita quanto più vicino possibile al paese del client.

  • Se viene eseguita all'estero, il caricamento delle pagine può richiedere più tempo.

  • Idealmente, la risoluzione dei nomi avviene in meno di 100 ms. In caso contrario, è necessario investigare il problema.

Suggerimento : Se non si è sicuri di come funziona la connettività dei client in Office 365, vedere il documento di riferimento qui.

Netmon

Wireshark

PsPing

L'analisi delle prestazioni del DNS è in genere un altro motivo per cui eseguire una traccia di rete. Tuttavia, PsPing è utile anche per identificare o escludere una possibile causa.

Il traffico DNS è basato su richieste TCP e UDP e le risposte sono chiaramente contrassegnate con un ID che consente di abbinare una specifica richiesta alla relativa risposta. Il traffico DNS si può vedere 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, tranne per il trasferimento di zone, viene eseguito su UDP.

In Netmon e Wireshark, il filtro di base che consentirà di esaminare il traffico DNS è semplicemente dns. Assicurarsi di usare lettere minuscole quando si specifica il filtro. È necessario ricordare di svuotare la cache del Risolutore DNS prima di iniziare a riprodurre il problema nel computer client. Ad esempio, se si dispone di un lento caricamento della pagina SharePoint Online per la Home page, è necessario chiudere tutti i browser, aprire un nuovo browser, avviare l'analisi, svuotare la cache del Risolutore DNS e passare al sito di SharePoint Online. Dopo l'intera pagina viene risolto, è necessario arrestare e salvare la traccia.

Il filtro di base per DNS in Netmon è DNS.

Si desidera esaminare il tempo offset qui. E può essere utile aggiungere la colonna Time Delta Netmon che è possibile eseguire queste operazioni:

  1. Fare clic con il pulsante destro del mouse su una colonna, ad esempio Description.

  2. Scegliere Choose Columns.

  3. Individuare la colonna Time Delta nell'elenco e fare clic su Add.

  4. Spostare la nuova colonne prima o dopo la colonna Description in modo da poterle vedere affiancate. Fare clic su OK.

Se si trova una query di interesse, valutare la possibilità di isolamento facendo clic su tale query nel riquadro dei dettagli cornice, scegliere Trova conversazioni > DNS. Si noti che il pannello di rete conversazioni rimanda destra alla conversazione specifica nel registro del traffico UDP.

Traccia Netmon del carico di Outlook Online filtrata da DNS. Viene usato il comando per trovare le conversazioni e quindi il DNS per limitare i risultati.

Wireshark consente di selezionare una colonna per volta DNS. Eseguire la traccia (o aprire una traccia) in Wireshark e filtro in base a dnso più ha dns.time. Fare clic su tutte le query DNS e, nel riquadro che mostra i dettagli, espandere i dettagli Domain Name System (response) . Verrà visualizzato un campo per volta (ad esempio [Time: 0.001111100 seconds]. Pulsante destro del mouse questa volta e selezionare Applica come colonna. Questo consentirà una colonna di ora per l'ordinamento rapido della traccia. Fare clic su nuova colonna effettuare l'ordinamento decrescente valori per verificare che la chiamata DNS ha un tempo di risolvere.

Immagine di SharePoint Online filtrato in Wireshark da (minuscole) dns.time, con il tempo dei dettagli in una colonna comoda e ordinata.

Se si desidera eseguire ulteriori analisi del tempo di risoluzione DNS, provare a eseguire PsPing contro la porta DNS utilizzato da TCP (ad esempio psping <IP address of DNS server>:53). È visualizzato un problema di prestazioni? In tal caso, il problema è generalmente una rete più ampia emettere rispetto a un problema specifico dell'applicazione DNS è raggiungere per eseguire la risoluzione. È inoltre opportuno menzionare nuovamente, che un ping a Office365 che indica dove la risoluzione dei nomi DNS per Outlook Online è stata effettuata (ad esempio, outlook namnorthwest.office365.com).

Se il problema sembra specifico del DNS, può essere necessario contattare il reparto IT per esaminare le configurazioni e i server d'inoltro del DNS ed eseguire ulteriori analisi.

Scalabilità del proxy

  • Servizi come Outlook Online in Office 365 concedono ai client molteplici connessioni a lungo termine.

  • Pertanto, ogni utente può usare più connessioni che richiedono una durata più lunga.

Suggerimento : Se è necessario pianificare l'uso della larghezza di banda in previsione dell'aggiunta di molti utenti a Office 365, vedere Pianificare l'utilizzo della larghezza di banda Internet per Office 365. In questa pagina sono disponibili strumenti per calcolare la larghezza di banda.

Math

Non esiste una traccia di rete o uno strumento di risoluzione dei problemi specifico per questo aspetto. Si basa invece su calcoli della larghezza di banda considerando le limitazioni e altre variabili.

Max Segment Size (MSS) TCP

  • In SYN - SYN/ACK.

  • Eseguire questo controllo in qualsiasi traccia di rete delle prestazioni acquisita per verificare che i pacchetti TCP siano configurati per trasferire la maggior quantità di dati possibile.

  • L'obiettivo è riscontrare un valore MSS di 1460 byte per la trasmissione dei dati.

  • Se si usa un proxy o NAT, ricordarsi di eseguire il test dal client al proxy/punto di uscita/NAT e dal proxy/punto di uscita/NAT a Office 365 per risultati ottimali. Si tratta di sessioni TCP diverse.

Netmon

TCP Max Segment Size (MSS) è un altro parametro di sincronizzazione tre elementi nella traccia di rete, che indica che sono disponibili i dati che necessari in SYN - pacchetto SYN/ACK. MSS è molto semplice visualizzare.

Aprire una qualsiasi traccia di rete delle prestazioni acquisita e trovare la connessione desiderata o che dimostra il problema di prestazioni.

Note : 

  • Se si esamina una traccia ed è necessario trovare il traffico appropriato per la conversazione, filtrare in base all'indirizzo IP del client o all'indirizzo IP del server proxy o punto di ingresso oppure in base a entrambi. Per un approccio diretto, è necessario effettuare il ping all'URL da testare per ottenere l'indirizzo IP di Office 365 nella traccia e filtrare in base a esso.

  • Guardando la traccia usata? Provare a utilizzare i filtri per orientare se stessi. In Netmon, eseguire una ricerca in base all'URL, ad esempio Containsbin(framedata, ascii, "sphybridExample"), prendere nota del numero di frame. In Wireshark usare simile al frame contains "sphybridExample". Se si nota che è stato trovato il traffico remoto Winsock (RW) (risultare come [PSH, ACK] in Wireshark), tenere presente che si connette RW può essere visualizzato subito prima pertinenti SYN - SYN/ACK, come descritto in precedenza. A questo punto è possibile registrare il numero di frame, eliminare il filtro, fare clic su tutto il traffico nella finestra di conversazione di rete in Netmon per esaminare lo SYN più vicino.

  • È importante tenere presente che, se non si ricevono informazioni su nessuno degli indirizzi IP al momento della traccia, trovando l'URL nella traccia, ad esempio come parte di sphybridExample-my.sharepoint.com, si otterranno gli indirizzi IP in base a cui filtrare.

  1. Individuare nella traccia la connessione a cui si è interessati. A questo scopo, è possibile analizzare la traccia, filtrare per indirizzi IP o selezionare specifici ID di conversazione usando la finestra Network Conversations in Netmon.

    Filtro per conversazione. Fare clic con il pulsante destro del mouse sul frame SYN e fare clic su Trova conversazioni, TCP.

  2. Dopo aver trovato il pacchetto SYN, espandere TCP (in Netmon) o Transmission Control Protocol (in Wireshark) nel riquadro Frame Details.

  3. Espandere TCP Options e MaxSegementSize.

  4. Individuare il frame SYN-ACK correlato ed espandere TCP Options e MaxSegmentSize.

  5. Il valore minore dei due corrisponderà a MSS.

Nell'immagine seguente assicurarsi di usare la colonna predefinita di Netmon, TCP Troubleshoot.

Traccia di rete filtrata in Netmon tramite le colonne incorporate.

La colonna predefinita si trova nella parte superiore del riquadro Frame Details. Per tornare nella visualizzazione normale, scegliere di nuovo Columns e quindi Time Zone.

Dove trovare l'elenco a discesa Colonne per l'opzione di risoluzione dei problemi TCP Troubleshoot (sopra al riepilogo dei frame).

Ecco una traccia filtrata in Wireshark. Esiste un filtro specifiche per il valore MSS (tcp.options.mss). I frame di SYN, SYN/ACK, handshake ACK sono collegati nella parte inferiore della Wireshark equivalente a Frame Details (cornice in modo ACK 47, collegamenti a 46 SYN/ACK, collegamenti a SYN 43) per rendere più semplice questo tipo di lavoro.

Traccia filtrata in Wireshark da tcp.options.mss per Max Segment Size (MSS).

Se è necessario controllare il parametro Selective Acknowledgment, descritto nell'argomento seguente, non chiudere la traccia.

Selective Acknowledgment

  • In SYN - SYN/ACK.

  • Deve essere segnalato come consentito sia in SYN che in SYN/ACK.

  • Selective Acknowledgment (SACK) consente una trasmissione dei dati più fluida quando uno o più pacchetti vanno persi.

  • I dispositivi possono disabilitare questa caratteristica, generando possibili problemi di prestazioni.

  • Se si usa un proxy o NAT, ricordarsi di eseguire il test dal client al proxy/punto di uscita/NAT e dal proxy/punto di uscita/NAT a Office 365 per risultati ottimali. Si tratta di sessioni TCP diverse.

Netmon

Selective Acknowledgment è un altro parametro dell'handshake SYN-SYN/ACK. È possibile filtrare la traccia per ottenere SYN - SYN/ACK in molti modi.

  1. Individuare nella traccia la connessione a cui si è interessati. A questo scopo è possibile analizzare la traccia, filtrare per indirizzi IP o fare clic su un ID di conversazione usando la finestra Network Conversations in Netmon.

  2. Dopo aver trovato il pacchetto SYN, espandere TCP in Netmon o Transmission Control Protocol in Wireshark nella sezione dei dettagli dei Frame.

  3. Espandere TCP Options e quindi SACK.

  4. Individuare il frame SYN-ACK correlato ed espandere TCP Options e il relativo campo SACK.

  5. Assicurarsi che SACK sia consentito sia in SYN che in SYN/ACK.

Ecco i valori SACK in Netmon e Wireshark.

Conferma selettiva (SACK) in Netmon come risultato di tcp.flags.syn == 1.

SACK visto in Wireshark con il filtro tcp.flags.syn == 1.

Georilevazione DNS

  • L'area geografica in cui Office 365 prova a risolvere la chiamata DNS ha effetto sulla velocità di connessione.

  • In Outlook Online, dopo il completamento della prima ricerca di DNS, la posizione di questo DNS verrà usata per connettersi al data center più vicino. Si verrà connessi a un server CAS di Outlook Online, che userà la dorsale di rete per connettersi al data center in cui sono archiviati i dati. Questa operazione è più veloce.

  • Quando accede a SharePoint Online, un utente che viaggia all'estero verrà indirizzato al relativo data center attivo, ossia il data center la cui posizione si basa sulla sede centrale del tenant di SPO (quindi un data center negli USA se l'utente si trova negli USA).

  • Lync online ha nodi attivi in più data center alla volta. Quando vengono inviate richieste per istanze di Lync online, il DNS Microsoft determina da quale area geografica proviene la richiesta e restituisce gli indirizzi IP del data center locale più vicino in cui Lync online è attivo.

Suggerimento : Per altre informazioni su come i client si connettono a Office 365, vedere l'articolo di riferimento Connettività dei client e le utili immagini associate.

Ping

PsPing

Le richieste di risoluzione dei nomi di server DNS del client per i server DNS Microsoft devono nelle verranno posizionate la maggior parte dei casi in Microsoft DNS restituendo l'indirizzo IP di un data center locale (CD). Cosa sono le implicazioni dell'utente? Se il headquarters Bangalore, India, ma si è in viaggio negli Stati Uniti, quando il browser effettua una richiesta per Outlook Online, i server DNS Microsoft affidare si indirizzi IP al Data Center negli Stati Uniti, ossia un data center locale. Eventualmente posta elettronica da Outlook, i dati verranno viaggio di lavoro rete dorsale rapido Microsoft tra i Data Center.

DNS funziona più velocemente quando la risoluzione dei nomi viene eseguita quanto più vicino possibile alla posizione dell'utente. Se ci si trova in Europa, si vorrà accedere a un DNS MIcrosoft in Europa e, idealmente, avere a che fare con un data center in Europa. Le prestazioni di un client in Europa che accede a un DNS e a un data center in America saranno più lente.

Eseguire lo strumento Ping su outlook.office365.com per determinare in quale area geografica verrà instradata la propria richiesta DNS. Se ci si trova in Europa, la risposta dovrebbe provenire da qualcosa di simile a outlook-emeawest.office365.com. In America ci si può aspettare qualcosa di simile a outlook-namnorthwest.office365.com.

  1. Fare clic sul pulsante Start > Esegui > cmd oppure premere il tasto WINDOWS > digitare cmd per aprire un prompt dei comandi.

  2. Digitare ping outlook.office365.com e quindi premere INVIO.

    È necessario specificare -4 , se si desidera specificare per effettuare il ping mediante IPv4. Si potrebbe non riuscire ottenere una risposta dai pacchetti ICMP, ma verrà visualizzato il nome del DNS a cui è stata instradata la richiesta.

Se si vogliono vedere i numeri sulla latenza per questa connessione, provare a eseguire PsPing sull'indirizzo IP del server restituito tramite ping.

Ping di outlook.office365.com con la risoluzione in outlook-namnorthwest.

PSPing all'indirizzo IP restituito dal ping a outlook.office365.com con una latenza media di 28 millisecondi.

Risoluzione dei problemi delle applicazioni di Office 365

Netmon

HTTPWatch

Console F12 nel browser

Questo articolo è dedicato alla rete e non tratta gli strumenti per la risoluzione dei problemi specifici delle applicazioni. Per accedere a risorse che è possibile usare, vedere questa pagina.

Argomenti correlati

Gestione di Office 365 endpoint
la connettività di risoluzione dei problemi di Office 365

Nota : Dichiarazione di non responsabilità per la traduzione automatica: Il presente articolo è stato tradotto tramite un software di traduzione automatica e non da una persona. Microsoft offre le traduzioni automatiche per consentire a coloro che non conoscono la lingua inglese di leggere gli articoli sui prodotti, sui servizi e sulle tecnologie Microsoft. Dal momento che l'articolo è stato tradotto automaticamente, potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli.

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa al programma Office Insider

Queste informazioni sono risultate utili?

Grazie per i tuoi commenti e suggerimenti

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×