Ottimizzazione delle prestazioni di Office 365 con le linee di base e la cronologia delle prestazioni
Esistono alcuni modi semplici per controllare le prestazioni di connessione tra Office 365 e l'azienda che consentono di stabilire una linea di base approssimativa della connettività. Conoscere la cronologia delle prestazioni delle connessioni del computer client può aiutare a rilevare i problemi emergenti in anticipo, identificare e prevedere i problemi.
Se non si è abituati a lavorare su problemi di prestazioni, questo articolo è progettato per aiutare a prendere in considerazione alcune domande comuni. Come si sa che il problema riscontrato è un problema di prestazioni e non un evento imprevisto del servizio Office 365? Come è possibile pianificare buone prestazioni, a lungo termine? Come si può tenere d'occhio le prestazioni? Se il team o i client riscontrano prestazioni lente durante l'uso di Office 365 e ci si interroga su una di queste domande, leggere.
Importante
Si è verificato un problema di prestazioni tra il client e Office 365 in questo momento? Seguire i passaggi descritti nel piano di risoluzione dei problemi delle prestazioni per Office 365.
Informazioni sulle prestazioni Office 365
Office 365 vive all'interno di una rete Microsoft dedicata e ad alta capacità monitorata dall'automazione e da persone reali. Parte della gestione del cloud Office 365 è l'ottimizzazione delle prestazioni e la semplificazione, dove possibile. Poiché i client del cloud Office 365 devono connettersi attraverso Internet, è necessario ottimizzare le prestazioni anche tra i servizi Office 365.
I miglioramenti delle prestazioni non si arrestano mai nel cloud, quindi non è necessario mantenere il cloud integro e rapido. Se si verifica un problema di prestazioni durante la connessione dalla posizione a Office 365, è consigliabile non iniziare o attendere un caso di supporto. Al contrario, è consigliabile iniziare a analizzare il problema dall'interno all'esterno. Ovvero, iniziare all'interno della rete e trovare una via d'uscita per Office 365. Prima di aprire un caso con il supporto, è possibile raccogliere dati ed eseguire azioni che esploreranno e potrebbero risolvere il problema.
Importante
Tenere presente la pianificazione della capacità e i limiti in Office 365. Tali informazioni consentono di anticipare la curva quando si tenta di risolvere un problema di prestazioni. Ecco un collegamento alle descrizioni del servizio Microsoft 365 e Office 365. Si tratta di un hub centrale e tutti i servizi offerti da Office 365 hanno un collegamento che passa alle proprie descrizioni del servizio da qui. Ciò significa che, se è necessario visualizzare i limiti standard per SharePoint, ad esempio, fare clic su Descrizione servizio SharePoint e individuare la relativa sezione Limiti di SharePoint.
Assicurarsi di passare alla risoluzione dei problemi tenendo presente che le prestazioni sono una scala mobile. Non si tratta di ottenere un valore idealizzato e mantenerlo permanentemente. Le attività occasionali con larghezza di banda elevata, ad esempio l'onboarding di un numero elevato di utenti o l'esecuzione di migrazioni di dati di grandi dimensioni, saranno stressanti, quindi pianificare l'impatto sulle prestazioni. Si dovrebbe avere un'idea approssimativa degli obiettivi di prestazioni, ma molte variabili giocano nelle prestazioni, quindi le prestazioni variano.
La risoluzione dei problemi delle prestazioni non riguarda il raggiungimento di obiettivi specifici e la gestione di tali numeri a tempo indeterminato, ma il miglioramento delle attività esistenti, date tutte le variabili.
Ok, che aspetto ha un problema di prestazioni?
Prima di tutto, è necessario assicurarsi che ciò che si sta verificando sia effettivamente un problema di prestazioni e non un evento imprevisto del servizio. Un problema di prestazioni è diverso da un evento imprevisto del servizio in Office 365. Ecco come distinguerli.
Gli eventi imprevisti del servizio si verificano quando il servizio Office 365 stesso presenta problemi. Nelle interfaccia di amministrazione di Microsoft 365 potrebbero essere visualizzate icone rosse o gialle in Integrità corrente. Si potrebbe notare che le prestazioni nei computer client che si connettono a Office 365 sono lente. Ad esempio, se Integrità corrente segnala un'icona rossa e viene visualizzata l'analisi accanto a Exchange, è anche possibile ricevere chiamate da persone dell'organizzazione che lamentano che le cassette postali client che usano Exchange Online sono lente. In tal caso, è ragionevole presupporre che le prestazioni Exchange Online siano state vittime di problemi di servizio.
A questo punto, l'amministratore Office 365 deve controllare l'integrità corrente e quindi visualizzare i dettagli e la cronologia, spesso, per rimanere aggiornati sulla manutenzione nel sistema. Il dashboard integrità corrente è stato creato per aggiornare l'utente in merito alle modifiche e ai problemi del servizio. Le note e le spiegazioni scritte nella cronologia dell'integrità, dall'amministratore all'amministratore, sono disponibili per aiutarti a misurare e a tenerti aggiornato sul lavoro in corso.
Un problema di prestazioni non è un evento imprevisto del servizio, anche se gli eventi imprevisti possono causare prestazioni lente. Un problema di prestazioni è simile al seguente:
Si verifica un problema di prestazioni indipendentemente dall'interfaccia di amministrazione Che cosa segnala l'integrità corrente per il servizio.
Il completamento di un comportamento usato per il flusso richiede molto tempo o non viene mai completato.
È anche possibile replicare il problema o sapere che si verifica se si esegue la serie corretta di passaggi.
Se il problema è intermittente, può comunque esistere un modello. Ad esempio, si sa che entro le 10:00 si avranno chiamate da utenti che non sempre possono accedere a Office 365. Le chiamate termineranno verso mezzogiorno.
Questo elenco probabilmente suona familiare; forse troppo familiare. Una volta che si è consapevoli che si tratta di un problema di prestazioni, la domanda diventa: "Cosa fare dopo?" Il resto di questo articolo consente di determinare esattamente questo.
Come definire e testare il problema di prestazioni
I problemi di prestazioni spesso emergono nel tempo, quindi può essere difficile definire il problema effettivo. Create un'istruzione di problema valida con una buona idea del contesto del problema e quindi è necessario eseguire passaggi di test ripetibili. Di seguito sono riportati alcuni esempi di istruzioni sui problemi che non forniscono informazioni sufficienti:
Il passaggio dalla posta in arrivo al calendario era qualcosa che non avevo notato, e ora è una pausa caffè. Si può fare in modo che si comporti come una volta?
Il caricamento dei file in SharePoint richiede per sempre. Perché è lento nel pomeriggio, ma in qualsiasi altro momento, è veloce? Non può essere solo veloce?
Le affermazioni sui problemi sopra riportate pongono diverse sfide di grandi dimensioni. In particolare, troppe ambiguità da gestire. Ad esempio:
Non è chiaro come il passaggio tra Posta in arrivo e Calendario usato per agire sul portatile.
Quando l'utente dice: "Non può essere solo veloce", che cos'è "veloce"?
Per quanto tempo è "per sempre"? Sono alcuni secondi? O molti minuti? Oppure l'utente potrebbe pranzare e l'azione finirebbe 10 minuti dopo il ritorno?
L'amministratore e lo strumento di risoluzione dei problemi non possono essere a conoscenza dei dettagli del problema da istruzioni generali come queste. Ad esempio, non sanno quando si è verificato il problema. Lo strumento di risoluzione dei problemi potrebbe non sapere che l'utente lavora da casa e vede solo un cambio lento nella rete domestica. In alternativa, l'utente esegue altre applicazioni a elevato utilizzo di RAM nel client locale. Gli amministratori potrebbero non sapere che l'utente esegue un sistema operativo precedente o che non ha eseguito gli aggiornamenti recenti.
Quando gli utenti segnalano un problema di prestazioni, è necessario raccogliere molte informazioni. Il recupero e la registrazione delle informazioni si chiamano definizione dell'ambito del problema. Ecco un elenco di ambito di base che è possibile usare per raccogliere informazioni sui problemi di prestazioni. Questo elenco non è esaustivo, ma è un punto di partenza:
In quale data si è verificato il problema e in quale ora del giorno o della notte?
Che tipo di computer client si usava e come si connette alla rete aziendale (VPN, cablata, wireless)?
Lavoravi da remoto o eri in ufficio?
Hai provato le stesse azioni in un altro computer e hai visto lo stesso comportamento?
Seguire i passaggi che stanno dando il problema in modo da poter scrivere le azioni che si eseguono.
Quanto sono lente in secondi o minuti le prestazioni?
Dove ti trovi al mondo?
Alcune di queste domande sono più ovvie di altre. La maggior parte di tutti comprenderà che uno strumento di risoluzione dei problemi richiede i passaggi esatti per riprodurre il problema. Dopo tutto, in che altro modo è possibile registrare gli errori e in che altro modo è possibile testare se il problema è stato risolto? Meno ovvi sono cose come "Quale data e ora hai visto il problema?", e "Dove ti trovi?", informazioni che possono essere usate in tandem. A seconda di quando l'utente stava lavorando, alcune ore di differenza di tempo potrebbero significare che la manutenzione è già in corso in alcune parti della rete aziendale. Ad esempio, l'azienda ha un'implementazione ibrida, ad esempio un Search di SharePoint ibrido, che può eseguire query sugli indici di ricerca sia in SharePoint in Microsoft 365 che in un'istanza di SharePoint Server 2013 locale, gli aggiornamenti potrebbero essere in corso nella farm locale. Se l'azienda si trova nel cloud, la manutenzione del sistema potrebbe includere l'aggiunta o la rimozione dell'hardware di rete, l'implementazione di aggiornamenti a livello aziendale o l'applicazione di modifiche al DNS o a un'altra infrastruttura di base.
Quando si sta risolvendo un problema di prestazioni, è un po' come una scena del crimine, è necessario essere precisi e osservanti per trarre conclusioni dalle prove. A tale scopo, è necessario ottenere una buona dichiarazione di problema raccogliendo prove. Deve includere il contesto del computer, il contesto dell'utente, l'inizio del problema e i passaggi esatti che hanno esposto il problema di prestazioni. Questa istruzione del problema deve essere, e rimanere, la pagina più in alto nelle note. Esaminando di nuovo l'istruzione del problema dopo aver eseguito la risoluzione, si stanno eseguendo i passaggi per testare e dimostrare se le azioni eseguite hanno risolto il problema. Questo è fondamentale per sapere quando il vostro lavoro, là, è fatto.
Sai come apparivano le prestazioni quando era buono?
Se sei sfortunato, nessuno lo sa. Nessuno aveva numeri. Ciò significa che nessuno può rispondere alla semplice domanda "Quanti secondi sono stati necessari per visualizzare una posta in arrivo in Office 365?", o "Quanto tempo ci è voluto quando i dirigenti hanno avuto una riunione Lync Online?", che è uno scenario comune per molte aziende.
Ciò che manca qui è una baseline delle prestazioni.
Le baseline offrono un contesto per le prestazioni. A seconda delle esigenze dell'azienda, è consigliabile usare occasionalmente una linea di base. Se si è una società di dimensioni maggiori, il team operativo potrebbe adottare già linee di base per l'ambiente locale. Ad esempio, se si applica una patch a tutti i server Exchange il primo lunedì del mese e a tutti i server SharePoint il terzo lunedì, il team operativo probabilmente dispone di un elenco di attività e scenari eseguiti dopo l'applicazione di patch, per dimostrare che le funzioni critiche sono operative. Ad esempio, aprendo la cartella Posta in arrivo, facendo clic su Invia/Ricevi e assicurandosi che le cartelle vengano aggiornate oppure, in SharePoint, esplorando la pagina principale del sito, accedendo alla pagina Search aziendale ed eseguendo una ricerca che restituisce risultati.
Se le applicazioni si trovano in Office 365, alcune delle baseline più fondamentali è possibile misurare il tempo (in millisecondi) da un computer client all'interno della rete, a un punto di uscita o al punto in cui si esce dalla rete e si passa a Office 365. Ecco alcune linee di base utili che è possibile analizzare e registrare:
Identificare i dispositivi tra il computer client e il punto di uscita, ad esempio il server proxy.
È necessario conoscere i dispositivi in modo da avere un contesto (indirizzi IP, tipo di dispositivo, eccetera) per i problemi di prestazioni che si verificano.
I server proxy sono punti di uscita comuni, quindi è possibile controllare il Web browser per vedere quale server proxy è impostato per l'uso, se presente.
Esistono strumenti di terze parti in grado di individuare e mappare la rete, ma il modo più sicuro per conoscere i dispositivi consiste nel chiedere a un membro del team di rete.
Identificare il provider di servizi Internet (ISP), annotare le informazioni di contatto e chiedere il numero di circuiti in base alla larghezza di banda disponibile.
All'interno dell'azienda, identificare le risorse per i dispositivi tra il client e il punto di uscita o identificare un contatto di emergenza per parlare dei problemi di rete.
Di seguito sono riportate alcune linee di base che possono essere calcolate automaticamente da semplici test con strumenti:
Tempo dal computer client al punto di uscita in millisecondi
Tempo dal punto di uscita a Office 365 in millisecondi
Posizione nel mondo del server che risolve gli URL per Office 365 durante l'esplorazione
Velocità della risoluzione DNS dell'ISP in millisecondi, incoerenze nell'arrivo dei pacchetti (instabilità di rete), caricamento e download in millisecondi
Se non si ha familiarità con come eseguire questi passaggi, in questo articolo verranno illustrati più dettagliatamente.
Che cos'è una linea di base?
Si conoscerà l'impatto quando si verifica un problema, ma se non si conoscono i dati cronologici sulle prestazioni, non è possibile avere un contesto per quanto possa essere diventato negativo e quando. Quindi, senza una linea di base, ti manca l'indizio chiave per risolvere il puzzle: l'immagine sulla scatola del puzzle. Nella risoluzione dei problemi di prestazioni è necessario un punto di confronto. Le linee di base delle prestazioni semplici non sono difficili da accettare. Il team operativo può essere incaricato di eseguirli in base a una pianificazione. Si supponga, ad esempio, che la connessione sia simile alla seguente:
Ciò significa che è stato eseguito il controllo con il team di rete e si è scoperto che si lascia l'azienda per Internet tramite un server proxy e che il proxy gestisce tutte le richieste inviate dal computer client al cloud. In questo caso, è consigliabile disegnare una versione semplificata della connessione che elenca tutti i dispositivi intermedi. Inserire ora gli strumenti che è possibile usare per testare le prestazioni tra il client, il punto di uscita (in cui si lascia la rete per Internet) e il cloud Office 365.
Le opzioni sono elencate come Semplici e Avanzate a causa della quantità di competenze necessarie per trovare i dati sulle prestazioni. Una traccia di rete richiederà molto tempo, rispetto all'esecuzione di strumenti da riga di comando come PsPing e TraceTCP. Questi due strumenti da riga di comando sono stati scelti perché non usano pacchetti ICMP, che verranno bloccati da Office 365, e perché danno il tempo in millisecondi necessario per lasciare il computer client o il server proxy (se si ha accesso) e arrivare a Office 365. Ogni singolo hop da un computer a un altro finirà con un valore di tempo, e questo è ottimo per le linee di base! Altrettanto importante, questi strumenti da riga di comando consentono di aggiungere un numero di porta al comando, questo è utile perché Office 365 comunica sulla porta 443, che è la porta usata da Secure Sockets Layer e Transport Layer Security (SSL e TLS). Tuttavia, altri strumenti di terze parti potrebbero essere soluzioni migliori per la tua situazione. Microsoft non supporta tutti questi strumenti, quindi se, per qualche motivo, non è possibile far funzionare PsPing e TraceTCP, passare a una traccia di rete con uno strumento come Netmon.
È possibile prendere una linea di base prima dell'orario di ufficio, di nuovo durante l'uso intensivo e quindi di nuovo dopo ore. Ciò significa che alla fine si potrebbe avere una struttura di cartelle simile alla seguente:
È anche consigliabile selezionare una convenzione di denominazione per i file. Ecco alcuni esempi:
Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal
Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW
Feb_08_2015_2pmEST_PerfBaseline_BADPerf
Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf
Esistono molti modi diversi per eseguire questa operazione, ma l'uso del formato< dateTime><ciò che accade nel test> è un buon punto di partenza. Essere diligenti su questo sarà molto utile quando si sta cercando di risolvere i problemi in un secondo momento. Più tardi, si sarà in grado di dire "Ho preso due tracce l'8 febbraio, uno ha mostrato buone prestazioni e uno ha mostrato male, in modo da poterli confrontare". Questa operazione è utile per la risoluzione dei problemi.
È necessario disporre di un modo organizzato per mantenere le linee di base cronologiche. In questo esempio, i metodi semplici hanno prodotto tre output della riga di comando e i risultati sono stati raccolti come screenshot, ma è possibile che siano presenti file di acquisizione di rete. Usare il metodo più adatto all'utente. Archiviare le baseline cronologiche e farvi riferimento nei punti in cui si notano modifiche nel comportamento di Servizi online.
Perché raccogliere dati sulle prestazioni durante un progetto pilota?
Non c'è tempo migliore per iniziare a creare linee di base che durante un progetto pilota del servizio Office 365. L'ufficio potrebbe avere migliaia di utenti, centinaia di migliaia o cinque, ma anche con alcuni utenti, è possibile eseguire test per misurare le fluttuazioni delle prestazioni. Nel caso di una grande azienda, un campione rappresentativo di diverse centinaia di utenti che pilotano Office 365 può essere proiettato verso l'esterno a diverse migliaia in modo da sapere dove potrebbero verificarsi problemi prima che si verifichino.
Nel caso di una piccola azienda, in cui l'onboarding significa che tutti gli utenti vanno al servizio contemporaneamente e non c'è alcun progetto pilota, mantenere le misure delle prestazioni in modo da avere dati da mostrare a chiunque potrebbe dover risolvere un'operazione con prestazioni non ottimali. Ad esempio, se si nota che all'improvviso è possibile spostarsi all'interno dell'edificio nel tempo necessario per caricare un elemento grafico di medie dimensioni in cui si verificava rapidamente.
Come raccogliere le baseline
Per tutti i piani di risoluzione dei problemi è necessario identificare almeno questi elementi:
Il computer client in uso (il tipo di computer o dispositivo, un indirizzo IP e le azioni che hanno causato il problema)
Dove si trova il computer client nel mondo (ad esempio, se l'utente su una VPN per la rete, che lavora in remoto o nella intranet aziendale)
Punto di uscita usato dal computer client dalla rete (il punto in cui il traffico lascia l'azienda per un ISP o Internet)
È possibile trovare il layout della rete dall'amministratore di rete. Se si usa una rete di piccole dimensioni, esaminare i dispositivi che si connettono a Internet e chiamare l'ISP se si hanno domande sul layout. Create un grafico del layout finale per il riferimento.
Questa sezione è suddivisa in semplici strumenti e metodi da riga di comando e opzioni di strumenti più avanzate. Verranno illustrati prima i metodi semplici. Tuttavia, se al momento si verifica un problema di prestazioni, è consigliabile passare a metodi avanzati e provare il piano d'azione di esempio per la risoluzione dei problemi delle prestazioni.
Metodi semplici
L'obiettivo di questi semplici metodi consiste nell'apprendere a acquisire, comprendere e archiviare correttamente le semplici baseline delle prestazioni nel tempo, in modo da essere informati sulle prestazioni Office 365. Ecco il semplice diagramma per semplificare, come si è visto in precedenza:
Nota
TraceTCP è incluso in questa schermata perché è uno strumento utile per mostrare, in millisecondi, quanto tempo richiede una richiesta per l'elaborazione e quanti hop di rete o connessioni da un computer all'altro richiedono per raggiungere una destinazione. TraceTCP può anche fornire i nomi dei server usati durante gli hop, che possono essere utili per uno strumento di risoluzione dei problemi di Microsoft Office 365 in Supporto. > I comandi TraceTCP possono essere molto semplici, ad esempio: >tracetcp.exe outlook.office365.com:443> Ricordarsi di includere il numero di porta nel comando. >TraceTCP è un download gratuito, ma si basa su Wincap. Wincap è uno strumento usato e installato anche da Netmon. Viene anche usato Netmon nella sezione Metodi avanzati.
Se si dispone di più uffici, è necessario mantenere un set di dati da un client anche in ognuna di queste posizioni. Questo test misura la latenza, che, in questo caso, è un valore numerico che descrive la quantità di tempo tra un client che invia una richiesta a Office 365 e Office 365 rispondere alla richiesta. Il test ha origine all'interno del dominio in un computer client e cerca di misurare un round trip dall'interno della rete, da un punto di uscita, da Internet a Office 365 e viceversa.
Esistono alcuni modi per gestire il punto di uscita, in questo caso il server proxy. È possibile tracciare da 1 a 2 e quindi da 2 a 3 e quindi aggiungere i numeri in millisecondi per ottenere un totale finale al bordo della rete. In alternativa, è possibile configurare la connessione per ignorare il proxy per gli indirizzi Office 365. In una rete più grande con un firewall, un proxy inverso o una combinazione dei due, potrebbe essere necessario creare eccezioni nel server proxy che consentiranno il passaggio del traffico per molti URL. Per l'elenco degli endpoint usati da Office 365, vedere OFFICE 365 URL e intervalli di indirizzi IP. Se si dispone di un proxy di autenticazione, iniziare testando le eccezioni per quanto segue:
Porte 80 e 443
TCP e HTTPs
Connections in uscita a uno di questi URL:
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
È necessario consentire a tutti gli utenti di accedere a questi indirizzi senza interferenze proxy o autenticazione. In una rete più piccola è necessario aggiungerli all'elenco di bypass proxy nel Web browser.
Per aggiungerli all'elenco di bypass proxy in Internet Explorer, passare a Strumenti>Opzioni> Internet Connections>Impostazioni> DI RETEavanzate. La scheda Avanzate è anche la posizione in cui si trovano il server proxy e la porta del server proxy. Potrebbe essere necessario selezionare la casella di controllo Usa un server proxy per la rete LAN per accedere al pulsante Avanzate . Assicurarsi che il server proxy Bypass per gli indirizzi locali sia selezionato. Dopo aver selezionato Avanzate, verrà visualizzata una casella di testo in cui è possibile immettere le eccezioni. Separare gli URL con caratteri jolly elencati in precedenza con punti e virgola, ad esempio:
*.microsoftonline.com; *.sharepoint.com
Dopo aver ignorato il proxy, dovrebbe essere possibile usare ping o PsPing direttamente su un URL di Office 365. Il passaggio successivo sarà testare il ping outlook.office365.com. In alternativa, se si usa PsPing o un altro strumento che consente di fornire un numero di porta al comando, PsPing rispetto a portal.microsoftonline.com:443 per visualizzare il tempo medio di round trip in millisecondi.
Il tempo di round trip, o RTT, è un valore numerico che misura il tempo necessario per inviare una richiesta HTTP a un server come outlook.office365.com e ottenere una risposta che riconosce che il server è a conoscenza dell'operazione eseguita. A volte questa operazione viene abbreviata come RTT. Questo dovrebbe essere un periodo di tempo relativamente breve.
Per eseguire questo test, è necessario usare PSPing o un altro strumento che non usa pacchetti ICMP bloccati da Office 365.
Come usare PsPing per ottenere un tempo di round trip complessivo in millisecondi direttamente da un URL di Office 365
Eseguire un prompt dei comandi con privilegi elevati completando questi passaggi:
Fare clic su Avvia.
Nella casella Start Search digitare cmd e quindi premere CTRL+MAIUSC+INVIO.
Se viene visualizzata la finestra di dialogo Controllo account utente, confermare che l'azione visualizzata è quella desiderata e scegliere Continua.
Passare alla cartella in cui è installato lo strumento (in questo caso PsPing) e testare questi URL Office 365:
psping admin.microsoft.com:443
psping microsoft-my.sharepoint.com:443
psping outlook.office365.com:443
psping www.yammer.com:443
Assicurarsi di includere il numero di porta 443. Tenere presente che Office 365 funziona su un canale crittografato. Se si esegue PsPing senza il numero di porta, la richiesta avrà esito negativo. Dopo aver eseguito il ping dell'elenco breve, cercare il tempo medio in millisecondi (ms). Questo è ciò che si vuole registrare!
Se non si ha familiarità con il bypass del proxy e si preferisce procedere passo dopo passo, è necessario innanzitutto individuare il nome del server proxy. In Internet Explorer passare a Strumenti>Opzioni> Internet Connections>ImpostazioniLAN>Avanzate. Nella scheda Avanzate verrà visualizzato il server proxy elencato. Eseguire il ping del server proxy al prompt dei comandi completando questa attività:
Per effettuare il ping del server proxy e ottenere un valore di round trip in millisecondi per la fase da 1 a 2
Eseguire un prompt dei comandi con privilegi elevati completando questi passaggi:
Fare clic su Avvia.
Nella casella Start Search digitare cmd e quindi premere CTRL+MAIUSC+INVIO.
Se viene visualizzata la finestra di dialogo Controllo account utente, confermare che l'azione visualizzata è quella desiderata e scegliere Continua.
Digitare ping <il nome del server proxy usato dal browser o l'indirizzo IP del server> proxy e quindi premere INVIO. Se è installato PsPing o un altro strumento, è possibile scegliere di usare tale strumento.
Il comando potrebbe essere simile a uno di questi esempi:
ping ourproxy.ourdomain.industry.business.com
ping 155.55.121.55
ping ourproxy
psping ourproxy.ourdomain.industry.business.com:80
psping 155.55.121.55:80
psping ourproxy:80
- Quando la traccia smette di inviare pacchetti di test, si otterrà un piccolo riepilogo che elenca una media, in millisecondi, e questo è il valore che si sta cercando. Acquisire uno screenshot del prompt e salvarlo usando la convenzione di denominazione. A questo punto potrebbe anche essere utile compilare il diagramma con il valore .
Forse hai preso una traccia al mattino presto e il tuo client può accedere al proxy (o qualsiasi server in uscita esce da Internet) rapidamente. In questo caso, i numeri potrebbero essere simili ai seguenti:
Se il computer client è uno dei pochi selezionati con accesso al server proxy (o in uscita), è possibile eseguire la parte successiva del test connettendosi in remoto a tale computer, eseguendo il prompt dei comandi a PsPing a un URL Office 365 da questa parte. Se non si ha accesso a tale computer, è possibile contattare le risorse di rete per assistenza con la prossima tappa e ottenere numeri esatti in questo modo. Se ciò non è possibile, eseguire un psping sull'URL di Office 365 in questione e confrontarlo con il tempo PsPing o Ping rispetto al server proxy.
Ad esempio, se si dispone di 51,84 millisecondi dal client all'URL Office 365 e si dispone di 2,8 millisecondi dal client al proxy (o punto di uscita), si hanno 49,04 millisecondi dall'uscita al Office 365. Analogamente, se si dispone di un PsPing di 12,25 millisecondi dal client al proxy durante l'altezza del giorno e di 62,01 millisecondi dal client all'URL Office 365, il valore medio per l'uscita del proxy all'URL Office 365 è di 49,76 millisecondi.
In termini di risoluzione dei problemi, è possibile trovare qualcosa di interessante solo dal mantenere queste linee di base. Ad esempio, se si rileva che in genere si dispone di circa 40 millisecondi a 59 millisecondi di latenza dal proxy o dal punto di uscita all'URL Office 365 e si dispone di un client per il proxy o la latenza del punto di uscita di circa 3 millisecondi a 7 millisecondi (a seconda della quantità di traffico di rete visualizzato durante quel periodo del giorno), si saprà sicuramente qualcosa di problematico se gli ultimi tre client per proxy o baseline in uscita mostrano un latenza di 45 millisecondi.
Metodi avanzati
Se si vuole davvero sapere cosa accade con le richieste Internet per Office 365, è necessario acquisire familiarità con le tracce di rete. Non importa quali strumenti si preferisce per queste tracce, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard strumento o qualsiasi altro farà fino a quando tale strumento può acquisire e filtrare il traffico di rete. In questa sezione si noterà che è utile eseguire più di uno di questi strumenti per ottenere un quadro più completo del problema. Durante i test, alcuni di questi strumenti fungono anche da proxy a sé stante. Gli strumenti usati nell'articolo complementare Piano di risoluzione dei problemi delle prestazioni per Office 365 includono Netmon 3.4, HTTPWatch o WireShark.
L'assunzione di una baseline delle prestazioni è la parte semplice di questo metodo e molti dei passaggi sono gli stessi di quando si risolve un problema di prestazioni. I metodi più avanzati per la creazione di baseline per le prestazioni richiedono l'esecuzione e l'archiviazione delle tracce di rete. La maggior parte degli esempi in questo articolo usa SharePoint, ma è consigliabile sviluppare un elenco di azioni comuni nei servizi di Office 365 a cui si sottoscrive il test e il record. Ecco un esempio di base:
Elenco di base per SPO - ** Passaggio 1: ** Esplorare la home page del sito Web SPO ed eseguire una traccia di rete. Salvare la traccia.
Elenco di base per SPO- Passaggio 2: Search per un termine (ad esempio il nome della società) tramite Enterprise Search ed eseguire una traccia di rete. Salvare la traccia.
Elenco di base per SPO - Passaggio 3: Caricare un file di grandi dimensioni in una raccolta documenti di SharePoint ed eseguire una traccia di rete. Salvare la traccia.
Elenco di baseline per SPO - Passaggio 4: esplorare la home page del sito Web di OneDrive ed eseguire una traccia di rete. Salvare la traccia.
Questo elenco deve includere le azioni comuni più importanti eseguite dagli utenti su SharePoint. Si noti che l'ultimo passaggio, per tracciare l'accesso a OneDrive, crea un confronto tra il carico della home page di SharePoint (che viene spesso personalizzato dalle aziende) e la home page di OneDrive, che viene raramente personalizzata. Si tratta di un test di base quando si tratta di un sito di SharePoint a caricamento lento. È possibile creare un record di questa differenza nei test.
Se si è nel bel mezzo di un problema di prestazioni, molti dei passaggi sono gli stessi di quando si prende una linea di base. Le tracce di rete diventano critiche, quindi verrà gestito come acquisire le tracce importanti successivamente.
Per risolvere un problema di prestazioni, in questo momento è necessario eseguire una traccia nel momento in cui si verifica il problema di prestazioni. È necessario disporre degli strumenti appropriati per raccogliere i log ed è necessario un piano d'azione, ovvero un elenco di azioni di risoluzione dei problemi da eseguire per raccogliere le informazioni migliori che è possibile. La prima cosa da fare è registrare la data e l'ora del test in modo che i file possano essere salvati in una cartella che rifletta la tempistica. Quindi, limitare i passaggi del problema stessi. Questi sono i passaggi esatti che verranno usati per il test. Non dimenticare le nozioni di base: se il problema riguarda solo Outlook, assicurarsi di registrare che il comportamento del problema si verifica in un solo servizio Office 365. Restringere l'ambito di questo problema consente di concentrarsi su qualcosa che è possibile risolvere.