Ottimizzazione delle prestazioni di Office 365 con la cronologia delle previsioni e delle prestazioni

È possibile controllare le prestazioni della connessione tra Office 365 e l'organizzazione in vari modi, che consentono di definire una base di riferimento per la connettività. Avendo a disposizione la cronologia delle prestazioni delle connessioni del computer client, è possibile rilevare in anticipo i problemi emergenti, identificarli e prevederli prima che si verifichino.

Se non si è esperti di problemi di prestazioni, questo articolo è stato pensato per aiutare a trovare una risposta a domande comuni, ad esempio come è possibile verificare se il problema riscontrato riguarda le prestazioni o non è invece un evento imprevisto del servizio Office 365? Come è possibile pianificare prestazioni elevate a lungo termine? Come è possibile monitorare le prestazioni? Se il proprio team o i client riscontrano una lentezza nelle prestazioni durante l'uso di Office 365 e ci si pone una di queste domande, leggere questo articolo.

Importante : Esiste al momento un problema di prestazioni tra il client e Office 365? Seguire i passaggi descritti in Pianificare la risoluzione dei problemi di prestazioni per Office 365.

Alcune informazioni che è necessario conoscere sulle prestazioni di Office 365

Office 365 risiede in una rete Microsoft dedicata, ad alta capacità, costantemente monitorata non tramite automazione ma da persone reali. Il ruolo di manutenzione del cloud di Office 365 prevede, tra l'altro, l'integrazione, laddove possibile, di procedure di semplificazione e ottimizzazione delle prestazioni. Dato che i client del cloud di Office 365 devono connettersi tramite Internet, ci si impegna continuamente a ottimizzare le prestazioni anche dei servizi di Office 365. I miglioramenti delle prestazioni non si fermano mai nel cloud, in realtà, e si continua ad accumulare esperienza per preservarne l'integrità e la rapidità. Se si verifica un problema di prestazioni con la connessione a Office 365, è preferibile non iniziare con un caso di supporto tecnico, che comporta comunque delle attese. È invece consigliabile iniziare a investigare il problema "dall'interno verso l'esterno", ossia dall'interno della propria rete e nei vari passaggi verso Office 365. Prima di aprire un caso di supporto tecnico con Office 365, è possibile raccogliere dati ed eseguire procedure per esaminare, e magari risolvere, il problema.

Importante : Tenere presenti i limiti e la pianificazione della capacità in Office 365. Queste informazioni sono importanti per ottenere risultati nel tentativo di risolvere un problema di prestazioni. Vedere Descrizione dei servizi della piattaforma di Office 365. Si tratta di un hub centrale da cui tutti i servizi offerti da Office 365 includono un collegamento alla rispettiva descrizione. Questo significa che nel caso sia necessario verificare i limiti standard per SharePoint Online, ad esempio, basterebbe fare clic sul collegamento Descrizione del servizio SharePoint Online per individuare la sezione Limiti di SharePoint Online.

Assicurarsi di iniziare le procedure di risoluzione dei problemi con la consapevolezza che le prestazioni sono variabili in base a diversi fattori, e che quindi non è possibile raggiungere un valore ideale e mantenerlo stabilmente. Se si pensa di poter raggiungere questo obiettivo, attività occasionali ad ampia larghezza di banda, come l'onboarding di un numero elevato di utenti o le migrazioni dei dati su vasta scala, possono diventare molto stressanti, quindi pianificare l'impatto sulle prestazioni in questi casi. È possibile, e consigliabile, avere una vaga idea degli obiettivi di prestazioni, ma le variabili in gioco sono numerose e pertanto i risultati sono variabili. Si tratta di un aspetto intrinseco delle prestazioni.

Lo scopo della risoluzione dei problemi di prestazioni non è raggiungere specifici obiettivi e mantenere questi numeri a tempo indefinito, quanto piuttosto migliorare le attuali attività, considerando tutte le variabili.

Come si presentano i problemi di prestazioni?

Prima di tutto, è necessario assicurarsi che il problema riscontrato riguardi effettivamente le prestazioni e non sia invece un evento imprevisto del servizio. Un problema di prestazioni è diverso da un evento imprevisto del servizio in Office 365. Ecco come distinguerli.

Se il servizio di Office 365 presenta problemi, si tratta di un evento imprevisto del servizio. Verranno visualizzate icone rosse o gialle nella sezione Stato integrità corrente dell'interfaccia di amministrazione di Office 365 e si possono anche riscontrare prestazioni lente nei computer client che si connettono a Office 365. Se ad esempio in Stato integrità corrente viene visualizzata un'icona rossa e accanto a Exchange compare il messaggio Analisi in corso è possibile che si ricevano chiamate dalle persone dell'organizzazione per segnalare prestazioni insoddisfacenti delle cassette postali client che usano Exchange Online. In questo caso, è ragionevole presupporre che le prestazioni di Exchange Online siano state interessate da problemi del servizio.

Dashboard di integrità di Office 365 con tutti i carichi di lavoro in verde, fatta eccezione per Exchange, per cui risulta Servizio ripristinato.

A questo punto, l'amministratore di Office 365 dovrebbe controllare spesso le sezioni Stato integrità corrente e Visualizza dettagli e cronologia per mantenersi aggiornato sugli interventi di manutenzione eseguiti da Microsoft sul sistema. Il dashboard Stato integrità corrente è stato creato proprio per fornire aggiornamenti sulle modifiche e sui problemi del servizio. Le note e le spiegazioni riportate nella cronologia dell'integrità del servizio, da amministratore ad amministratore, consentono di valutare l'impatto e di rimanere informati sugli interventi in atto.

Immagine del dashboard di integrità di Office 365 che indica che il servizio Exchange Online è stato ripristinato e perché.

I problemi di prestazioni sono diversi dagli eventi imprevisti del servizio, anche se questi ultimi possono rallentare le prestazioni. I problemi di prestazioni si definiscono come segue:

  • I problemi di prestazioni si verificano indipendentemente da quanto segnalato per il servizio nella sezione Stato di integrità corrente dell'interfaccia di amministrazione di Office 365.

  • Un'operazione che in passato veniva eseguita senza interruzioni richiede tempi lunghi o non viene mai completata.

  • Il problema può anche essere replicato o almeno si conoscono i passaggi appropriati per replicarlo.

  • Se il problema è intermittente, segue comunque un modello. Ad esempio si sa che entro le 10:00 si riceveranno chiamate dagli utenti che non riescono ad accedere in modo affidabile a Office 365 e che queste chiamate termineranno intorno a mezzogiorno.

Questa situazione suona probabilmente familiare, magari anche troppo. Dopo aver stabilito che si tratta di un problema di prestazioni, la domanda diventa "Cosa fare dopo?" Il resto dell'articolo aiuta di scoprire esattamente questo.

Come si definisce e si verifica il problema di prestazioni

I problemi di prestazioni spesso emergono nel corso del tempo, quindi può essere difficile definirli esattamente. È necessario creare una descrizione accurata del problema, avere una buona idea del contesto e quindi generare passaggi di test ripetibili per cercare di risolverlo. In caso contrario, anche se non per propria colpa, ci si potrebbe perdere. Perché? Ecco alcuni esempi di descrizioni del problema che non forniscono informazioni sufficienti:

  • Il passaggio dalla posta in arrivo al calendario, che prima avveniva in modo impercettibile, ora richiede tempi lunghi. È possibile tornare a come era prima?

  • Il caricamento dei file in SharePoint Online richiede tempi lunghissimi. Perché è lento nel pomeriggio mentre è veloce in altri orari? Non può essere sempre veloce?

Queste descrizioni dei problemi pongono diverse sfide significative. In particolare, è necessario risolvere varie ambiguità, ad esempio:

  • Non è chiaro come avveniva il passaggio tra la posta in arrivo e il calendario sul portatile.

  • Quando l'utente dice "Non può essere sempre veloce", cosa intende per "veloce"?

  • Come si possono quantificare i "tempi lunghissimi"? Si tratta di diversi secondi o minuti oppure del tempo necessario all'utente per andare a pranzo e per altri dieci minuti al ritorno?

Tutto questo senza considerare che con descrizioni come queste l'amministratore e l'addetto alla risoluzione dei problemi non possono essere informati di molti dettagli necessari, ad esempio quando ha iniziato a manifestarsi il problema, se l'utente lavora da casa e riscontra prestazioni lente mentre è collegato alla rete domestica, se l'utente deve eseguire diverse altre applicazioni a uso intensivo di RAM nel client locale o se l'utente esegue un sistema operativo meno recente o non ha installato gli ultimi aggiornamenti.

Quando gli utenti segnalano un problema di prestazioni, è necessario raccogliere numerose informazioni. La raccolta di queste informazioni fa parte del cosiddetto processo di definizione dell'ambito o di analisi del problema. Di seguito è riportato un elenco di base per la definizione dell'ambito che è possibile consultare per raccogliere informazioni sul problema di prestazioni. L'elenco non è esaustivo, ma rappresenta un buon punto di partenza per crearne uno personalizzato:

  • In quale data si è verificato il problema e in quale momento del giorno o della notte?

  • Quale tipo di computer client era in uso e come si connette alla rete aziendale (VPN, rete cablata, wireless)?

  • L'utente lavorava in remoto o in ufficio?

  • L'utente ha provato a eseguire le stesse operazioni in un altro computer riscontrando lo stesso comportamento?

  • Ripetere i passaggi che hanno generato il problema, in modo da poter annotare le azioni intraprese.

  • Come si quantifica, in secondi o minuti, la lentezza delle prestazioni?

  • In quale area geografica si trova l'utente?

Alcune di queste domande sono più ovvie di altre. È risaputo che per risolvere un problema è necessario conoscere i passaggi esatti per riprodurlo. Dopo tutto, in quale altro modo è possibile registrare cosa c'è che non va e verificare se il problema è risolto? Meno ovvie sono domande come "In quale data e ora si è verificato il problema?" e "In quale area geografica si trova l'utente?", e si tratta di informazioni che possono essere usate insieme. A seconda di quando l'utente stava lavorando, una differenza di poche ore può significare che in alcune parti della rete aziendale sono già in corso interventi di manutenzione. Se ad esempio l'organizzazione ha un'implementazione ibrida, ad esempio un ambiente ibrido di ricerca SharePoint, che consente di eseguire query sugli indici di ricerca sia in SharePoint Online che in un'istanza locale di SharePoint Server 2013, è possibile che siano in corso aggiornamenti nella farm locale. Se l'organizzazione opera interamente nel cloud, la manutenzione di sistema può includere l'aggiunta o la rimozione di hardware di rete, l'implementazione di aggiornamenti a livello aziendale o l'esecuzione di modifiche al DNS o ad altri componenti di base dell'infrastruttura.

La risoluzione dei problemi di prestazioni è paragonabile a una scena del crimine, in cui è necessario essere precisi e osservatori per trarre conclusioni dalle prove. A questo scopo, è necessario acquisire una descrizione del problema valida raccogliendo le prove. La descrizione deve includere il contesto del computer e dell'utente, la data e l'ora in cui il problema ha iniziato a manifestarsi e i passaggi esatti che lo hanno generato. Questa descrizione del problema devo trovarsi nella prima pagina dei propri appunti. Esaminandola di nuovo dopo aver lavorato alla risoluzione, sarà possibile eseguire i passaggi per testare e verificare se le azioni intraprese hanno risolto il problema. Solo a quel punto si potrà determinare se il proprio intervento è terminato.

Come sono le prestazioni in assenza di problemi?

Nella peggiore delle ipotesi, non lo sa nessuno. Nessuno ha le cifre. Questo significa che nessuno è in grado di rispondere alla semplice domanda "Quanti secondi erano necessari per aprire la posta in arrivo in Office 365?" oppure "Quanto tempo ci voleva mentre i dirigenti partecipavano a una riunione di Lync Online?", che è uno scenario consueto in molte aziende.

Quello che manca è una base di riferimento delle prestazioni.

Le basi di riferimento forniscono un contesto per le prestazioni. La frequenza in cui è necessario definire una base di riferimento varia in base alle esigenze dell'organizzazione. Nelle aziende più grandi, è possibile che il team delle operazioni abbia già definito una base di riferimento per l'ambiente locale. Se ad esempio vengono distribuite patch in tutti i server Exchange il primo lunedì del mese e in tutti i server SharePoint il terzo lunedì, è probabile che il team delle operazioni abbia un elenco di attività o di scenari da eseguire dopo le patch, per verificare se le funzioni cruciali sono operative. Funzioni di questo tipo sono l'apertura della posta in arrivo, la selezione di Invia/Ricevi, la verifica che le cartelle siano aggiornate o, in SharePoint, l'esplorazione della pagina principale del sito, l'accesso alla pagina Ricerca contenuti organizzazione e l'esecuzione di una ricerca che restituisce risultati.

Se le applicazioni si trovano in Office 365, alcune delle basi di riferimento più importanti da definire sono quelle per misurare il tempo (in millisecondi) che intercorre da un computer client interno alla rete a un punto di uscita, ovvero il punto in cui si lascia la rete e si esce da Office 365. Ecco alcune basi di riferimento utili da esaminare e registrare:

  • Identificare i dispositivi tra il computer client e il punto di uscita, ad esempio il server proxy.

    • È necessario conoscere i propri dispositivi in modo da avere un contesto (indirizzi IP, tipo di dispositivo, eccetera) per eventuali problemi di prestazioni che si verificano.

    • I server proxy sono i comuni punti in uscita, quindi è possibile controllare il Web browser per verificare quale server proxy è eventualmente impostato per usare.

    • Sono disponibili strumenti di terze parti che consentono di individuare e mappare la rete, ma il modo più sicuro consiste nel chiedere queste informazioni a un membro del team di rete.

  • Identificare il provider di servizi Internet (ISP), annotare le informazioni di contatto e chiedere quanta larghezza di banda si ha a disposizione.

  • All'interno dell'azienda, identificare le risorse per i dispositivi situati tra il client e il punto di uscita oppure identificare un contatto di emergenza a cui rivolgersi in caso di problemi di rete.

Ecco alcune basi di riferimento che possono essere calcolate con semplici test e strumenti:

  • Il tempo in millisecondi dal computer client al punto di uscita

  • Il tempo in millisecondi dal punto di uscita a Office 365

  • La posizione nel mondo del server che risolve gli URL per Office 365 quando si naviga

  • La velocità in millisecondi della risoluzione del DNS dell'ISP, le incoerenze nell'arrivo dei pacchetti (instabilità di rete), i tempi di caricamento e download

Se non si ha familiarità con queste procedure, verranno forniti altri dettagli in questo articolo.

Cos'è una base di riferimento?

Quando si verifica un problema, è facile recepirne l'impatto, ma se non si conoscono i dati cronologici delle prestazioni, non è possibile avere un contesto per capirne l'entità e i tempi. Quindi senza una base di riferimento, manca la chiave per risolvere il puzzle, ossia l'immagine sulla scatola. Nella risoluzione dei problemi di prestazioni, è necessario un punto di confronto. Non è difficile definire semplici basi di riferimento per le prestazioni. È possibile affidare questo incarico al team delle operazioni, da svolgere periodicamente. Si supponga ad esempio che la connessione sia configurata come segue:

Rete di base con client, proxy e cloud di Office 365.

In questa configurazione l'accesso aziendale a Internet avviene tramite un server proxy, che gestisce tutte le richieste inviate dal computer client al cloud. In questo caso, è consigliabile tracciare una versione semplificata della connessione che elenchi tutti i dispositivi coinvolti. A questo punto, inserire gli strumenti che è possibile usare per testare le prestazioni tra il client, il punto di uscita (ossia quello in cui si lascia la rete interna e si passa a Internet) e il cloud di Office 365.

Rete di base con client, proxy, cloud, suggerimenti degli strumenti, PSPing, TraceTCP e tracce di rete.

Le opzioni sono elencate come Semplice e Avanzata a seconda del livello di competenze necessario per trovare i dati sulle prestazioni. Una traccia di rete richiede molto tempo, rispetto all'esecuzione di strumenti da riga di comando come PsPing e TraceTCP. Sono stati scelti questi due strumenti perché non usano pacchetti ICMP, che verranno bloccati da Office 365, e perché forniscono il tempo in millisecondi richiesto per lasciare il computer client, o il proxy server (se si ha accesso) e arrivare a Office 365. Ogni singolo passaggio da un computer a un altro fornisce termina con un valore temporale, un dato molto utile per le basi di riferimento. Altrettanto importante è che questi strumenti da riga di comando consentono di aggiungere un numero di porta nel comando, una funzionalità utile perché Office 365 comunica tramite la porta 443, che è quella usata dai protocolli SSL (Secure Sockets Layer) e TLS (Transport Layer Security). Tuttavia, altri strumenti di terze parti potrebbero essere soluzioni più efficaci in specifiche situazioni. Microsoft non supporta tutti questi strumenti, quindi se, per qualsiasi motivo, non si riesce a usare PsPing e TraceTCP, procedere a una traccia della rete con strumenti come Netmon.

È possibile definire una base di riferimento prima degli orari di ufficio, di nuovo durante l'utilizzo intensivo e un'altra volta dopo gli orari di uffici. Alla fine, si potrebbe avere una struttura della cartella simile alla seguente:

Esempio di organizzazione dei dati delle prestazioni in cartelle.

È anche consigliabile scegliere una convenzione di denominazione per i file. Ecco alcuni esempi:

  • 09_feb_2015_9PST_BaseRifPrest_Netmon_Client-Uscita_Normale

  • 10_gen_2015_15CST_BaseRifPrest_PsPing_Client-O365_bypassProxy_LENTE

  • 08_feb_2015_14EST_BaseRifPrest_PrestBASSE

  • 08_feb_2015_14EST_BaseRifPrest_PrestBuone

Esistono vari modi diversi per eseguire questa operazione, ma l'uso del formato <dateTime><what's happening in the test> rappresenta un buon punto di inizio. Se si procede in modo scrupoloso, si otterranno vantaggi significativi quando in seguito si proverà a risolvere i problemi. Sarà infatti possibile concludere che l'8 febbraio sono state acquisite due tracce, di cui una ha indicato prestazioni buone e l'altra bassa, quindi è possibile confrontarle. Questo dato è estremamente utile per la risoluzione dei problemi.

È necessario conservare le basi di riferimento cronologiche in modo organizzato. In questo esempio i metodi semplici hanno prodotto tre output della riga di comando e i risultati sono stati raccolti come screenshot, ma è possibile avere invece file di acquisizione di rete. Usare il metodo più adatto alle proprie esigenze. Archiviare le basi di riferimento cronologiche e consultarle quando si notano cambiamenti nel comportamento dei servizi online.

Perché raccogliere dati sulle prestazioni durante un progetto pilota?

Il momento migliore per iniziare a definire le basi di riferimento è durante un progetto pilota del servizio Office 365. L'organizzazione può avere migliaia di utenti, centinaia di migliaia, o magari solo cinque, ma anche con un numero ridotto di utenti è possibile eseguire test per misurare le fluttuazioni nelle prestazioni. Nel caso di grandi aziende, un campione rappresentativo di diverse centinaia di utenti che partecipano al progetto pilota di Office 365 può essere proiettato fino a diverse migliaia in modo da capire dove potrebbero manifestarsi i problemi prima che si verifichino.

Nel caso di piccole imprese, in cui l'onboarding implica che tutti gli utenti accedono al servizio contemporaneamente, senza progetto pilota, conservare le misure delle prestazioni in modo da avere i dati da mostrare a chiunque debba risolvere i problemi di prestazioni insoddisfacenti di un'operazione. Si supponga ad esempio che all'improvviso il caricamento di un elemento grafico di medie dimensioni richiede tempi lunghissimi mentre prima avveniva molto rapidamente.

Come raccogliere basi di riferimento

Per tutti i piani di risoluzione dei problemi, è necessario identificare almeno questi aspetti:

  • I computer client in uso (il tipo di computer o dispositivo, un indirizzo IP e le azioni che generano il problema)

  • La posizione del computer client nel mondo, ad esempio se l'utente è collegato tramite VPN alla rete, lavorando in remoto, oppure alla Intranet aziendale

  • Il punto di uscita dalla rete usato dal computer client, ossia il punto in cui il traffico lascia l'organizzazione per passare a un ISP o a Internet

Il layout della rete può essere fornito dall'amministratore di rete. Per le piccole reti, esaminare i dispositivi che si connettono a Internet e rivolgersi all'ISP in caso di domande sul layout. Creare un elemento grafico del layout finale per riferimento.

Questa sezione è suddivisa tra semplici strumenti e metodi da riga di comando e opzioni di strumenti più avanzati. Verranno trattati per primi i metodi semplici. Ma se è in corso un problema di prestazioni, passare ai metodi avanzati e provare a usare il piano d'azione per la risoluzione dei problemi di prestazioni.

Metodi semplici

L'obiettivo di questi metodi semplici è definire, comprendere e conservare correttamente semplici basi di riferimento delle prestazioni in modo da essere informati sulle prestazioni di Office 365. Ecco un diagramma molto semplice, come illustrato prima:

Rete di base con client, proxy, cloud, suggerimenti degli strumenti, PSPing, TraceTCP e tracce di rete.

Note : 

  • TraceTCP è incluso in questo screenshot perché si tratta di uno strumento utile per mostrare il tempo richiesto, in millisecondi, per l'elaborazione di una richiesta e il numero di passaggi di rete, o connessioni, da un computer a quello successivo, che la richiesta esegue per raggiungere la destinazione. TraceTCP può anche fornire i nomi dei server usati durante i passaggi, un'informazione che può risultare utile all'addetto del supporto che si occupa della risoluzione dei problemi di Microsoft Office 365.

  • I comandi di TraceTCP possono essere molto semplici, ad esempio:

  • tracetcp.exe outlook.office365.com:443

  • Assicurarsi di includere il numero di porta nel comando.

  • TraceTCP è disponibile gratuitamente per il download, ma si basa su Wincap. Wincap è uno strumento usato e installato anche da Netmon. L'uso di Netmon è illustrato anche nella sezione sui metodi avanzati.

Se l'organizzazione ha molti uffici, è anche necessario mantenere un set di dati di un client in ognuna di queste sedi. Questo test misura la latenza che, in questo caso, è un valore numerico che descrive la quantità di tempo che intercorre tra l'invio di una richiesta del client a Office 365 e la risposta di Office 365 alla richiesta. Il test inizia all'interno del domini su un computer client e punta a misurare un round trip dall'interno della rete, o attraverso un punto di uscita, tramite Internet fino a Office 365 e viceversa.

È possibile gestire il punto di uscita in vari modi, in questo caso si tratta del server proxy. È possibile eseguire una traccia da 1 a 2 e quindi da 2 a 3 e quindi aggiungere il numero di millisecondi necessario per ottenere un totale finale al perimetro della rete. Oppure è possibile configurare la connessione in modo da ignorare il proxy per gli indirizzi di Office 365. Nelle reti più grandi con un firewall, un proxy inverso o una combinazione dei due, può essere necessario creare eccezioni nel server proxy che consentano il passaggio del traffico per numerosi URL. Per l'elenco degli endpoint usati da Office 365, vedere URL e intervalli di indirizzi IP per Office 365. Se si ha un proxy di autenticazione, iniziare a testare le eccezioni per quanto segue:

  • Porte 80 e 443

  • TCP e HTTP

  • Connessioni in uscita a uno di questi URL:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Tutti gli utenti devono essere autorizzati ad accedere a questi indirizzi senza interferenze o autenticazione del proxy. Nelle reti più piccole è consigliabile aggiungere questi indirizzi all'elenco dei proxy da ignorare nel Web browser.

Per eseguire questa operazione in Internet Explorer, aprire Strumenti > Opzioni Internet > Connessioni > Impostazioni LAN > Avanzate. La scheda Avanzate contiene anche le impostazioni sul server proxy e sulla relativa porta. Può essere necessario fare clic sulla casella di controllo Utilizza un server proxy per le connessioni LAN per accedere al pulsante Avanzate. Assicurarsi che l'opzione Ignora server proxy per indirizzi locali sia selezionata. Dopo aver fatto clic su Avanzate verrà visualizzata una casella di testo in cui è possibile immettere le eccezioni. Separare gli URL con caratteri jolly elencati sopra con un punto e virgola, ad esempio:

*.microsoftonline.com; *.sharepoint.com

Dopo aver ignorato il proxy, dovrebbe essere possibile usare ping o PsPing direttamente in un URL di Office 365. Il passaggio successivo consiste nell'effettuare il ping di test a outlook.office365.com. Oppure, se si usa PsPing o un altro strumento che consente di specificare un numero di porta nel comando, eseguire PsPing su portal.microsoftonline.com:443 per verificare il tempo 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 conferma che il server riconosce l'operazione. Questo valore viene a volte abbreviato in RTT. La quantità di tempo dovrebbe essere relativamente breve.

Per eseguire questo test, è necessario usare PsPing o un altro strumento che non usa pacchetti ICMP, che vengono bloccati da Office 365.

Come usare PsPing per ottenere il tempo di round trip complessivo, in millisecondi, direttamente da un URL di Office 365

  1. Eseguire un prompt dei comandi con privilegi elevati completando questi passaggi:

    1. Fare clic su Start.

    2. Nella casella Inizia ricerca digitare cmd e quindi premere CTRL+MAIUSC+INVIO.

    3. Se viene visualizzata la finestra di dialogo Controllo dell'account utente, confermare che si vuole eseguire l'azione indicata e quindi fare clic su Continua.

  2. Passare alla cartella in cui è installato lo strumento, in questo caso PsPing, e testare questi URL di Office 365:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      Comando PSPing inviato alla porta 443 di microsoft-my.sharepoint.com.

Assicurarsi di includere il numero di porta 443. Tenere presente che Office 365 opera su un canale crittografato. Se si usa PsPing senza il numero di porta, la richiesta non riesce. Dopo aver effettuato il ping dell'elenco breve, cercare il valore del tempo medio in millisecondi (ms). Questo è il dato da registrare.

Immagine che illustra PSPing da client a proxy con un tempo di andata e ritorno di 2,8 millisecondi.

Se non si ha familiarità con la procedura per ignorare il proxy e si preferisce eseguire un passaggio dopo l'altro, è necessario prima di tutto trovare il nome del server proxy. In Internet Explorer aprire Strumenti > Opzioni Internet > Connessioni > Impostazioni LAN > Avanzate. La scheda Avanzate contiene il nome del server proxy. Effettuare il ping a questo server proxy da un prompt dei comandi completando questa attività:

Per effettuare il ping al server proxy e ottenere un valore di round trip in millisecondi per la fase 1 - 2

  1. Eseguire un prompt dei comandi con privilegi elevati completando questi passaggi:

    1. Fare clic su Start.

    2. Nella casella Inizia ricerca digitare cmd e quindi premere CTRL+MAIUSC+INVIO.

    3. Se viene visualizzata la finestra di dialogo Controllo dell'account utente, confermare che si vuole eseguire l'azione indicata e quindi fare clic su Continua.

  2. Digitare ping <nome o indirizzo IP del server proxy usato dal browser> e quindi premere INVIO. Se è installato PsPing o un altro strumento, è possibile usarlo in alternativa.

    Il comando sarà simile a uno degli esempi seguenti:

    • ping ourproxy.ourdomain.industry.business.com

    • ping 155.55.121.55

    • ping ourproxy

    • psping ourproxy.ourdomain.industry.business.com:80

    • psping 155.55.121.55:80

    • psping ourproxy:80

  3. Quando la traccia interrompe l'invio di pacchetti di test, si ottiene un breve riepilogo che indica una media, in millisecondi, ossia il valore da trovare. Acquisire uno screenshot del prompt e salvarlo con la propria convenzione di denominazione. A questo punto può anche risultare utile inserire il valore nel diagramma.

È probabile che sia stata acquisita una traccia la mattina presto e che il client possa accedere rapidamente al proxy (o a qualsiasi server in uscita verso Internet). In questo caso, i numeri saranno simili ai seguenti:

Immagine che illustra il tempo di andata e ritorno da un client a un proxy di 2,8 millisecondi.

Se il computer client è uno dei pochi selezionati con accesso al server proxy (o al punto di uscita), è possibile eseguire il passaggio successivo del test connettendosi in remoto a tale computer, eseguendo il prompt dei comandi per PsPing a un URL di Office 365 da qui. Se non si ha accesso a questo computer, è possibile contattare le risorse di rete per chiedere assistenza con il passaggio successivo e ottenere i numeri in questo modo. Se non è possibile, eseguire PsPing sull'URL di Office 365 in questione confrontarlo con il tempo di PsPing o di ping sul server proxy.

Se ad esempio il tempo dal client all'URL di Office 365 è di 51,84 millisecondi e il tempo dal client al proxy (o punto di uscita) è di 2,8 millisecondi, il tempo dal punto di uscita a Office 365 sarà di 49,04 millisecondi. Analogamente, se il tempo di PsPing dal client al proxy nel periodo di picco della giornata è di 12,25 millisecondi e il tempo dal client all'URL di Office 365 è di 62,01 millisecondi, il valore medio per il punto di uscita del proxy all'URL di Office 365 sarà di 49,76 millisecondi.

Immagine aggiuntiva che mostra il ping in millisecondi dal client al proxy accanto al client per Office 365, per poter sottrarre i valori.

Ai fini della risoluzione dei problemi, si può ottenere qualcosa di interessante da queste basi di riferimento. Se ad esempio si riscontra in genere una latenza di circa 40-59 millisecondi dal proxy o dal punto di uscita all'URL di Office 365 e una latenza di circa 3-7 millisecondi (a seconda della quantità di traffico registrata in quel momento della giornata) dal client al proxy o al punto di uscita, si può ricavare che esiste qualcosa di problematico se le ultime tre basi di riferimento dal client al proxy o al punto di uscita indicano una latenza di 45 millisecondi.

Metodi avanzati

Se si vuole sapere cosa stia realmente accadendo con le richieste Internet a Office 365, è necessario acquisire familiarità con le tracce di rete. Non importa quale strumento si preferisce usare per queste tracce, ossia HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard o qualsiasi altro, purché sia in grado di acquisire e filtrare il traffico di rete. In questa sezione si scoprirà che è utile eseguire più strumenti per ottenere un quadro più completo del problema. Durante i test, alcuni di questi strumenti possono anche agire da proxy. Gli strumenti usati nell'articolo associato, Piano di risoluzione dei problemi di prestazioni per Office 365, includono Netmon 3.4, HTTPWatch o Wireshark.

La definizione di una base di riferimento delle prestazioni è la parte semplice di questo metodo, mentre molti dei passaggi sono gli stessi di quelli eseguiti quando si risolvono i problemi delle prestazioni. I metodi più avanzati per la creazione di basi di riferimento per le prestazioni richiedono l'acquisizione e l'archiviazione di tracce di rete. Nella maggior parte degli esempi di questo articolo si usa SharePoint Online, ma è consigliabile sviluppare un elenco di azioni comuni in tutti i servizi di Office 365 a cui si è abbonati da testare e registrare. Ecco un esempio di base di riferimento:

  • Elenco di basi di riferimento per SPO - Passaggio 1: Esplorare la home page del sito Web di SPO ed eseguire una traccia di rete. Salvare la traccia.

  • Elenco di basi di riferimento per SPO - Passaggio 2: Cercare un termine, ad esempio il nome della propria azienda, tramite Ricerca contenuti organizzazione ed eseguire una traccia di rete. Salvare la traccia.

  • Elenco di basi di riferimento per SPO - Passaggio 3: Caricare un file di grandi dimensioni nella raccolta documenti di SharePoint Online ed eseguire una traccia di rete. Salvare la traccia.

  • Elenco di basi di riferimento per SPO - Passaggio 4: Esplorare la home page del sito Web di OneDrive ed eseguire una traccia di rete. Salvare la traccia.

Questo elenco dovrebbe includere le azioni comuni più importanti eseguite dall'utente in SharePoint Online. Si noti che l'ultimo passaggio, ossia tracciare l'accesso a OneDrive for Business, incorpora un confronto tra il carico della home page di SharePoint Online (spesso personalizzata dalle aziende) e la home page di OneDrive for Business, che viene raramente personalizzata. Si tratta di un test molto basilare riguardo alla lentezza di caricamento di un sito di SharePoint Online. È possibile inserire nei test un record di questa differenza.

Se è in corso un problema di prestazioni, molti passaggi sono uguali a quelli eseguiti per definire una base di riferimento. Le tracce di rete diventano fondamentali, quindi verrà illustrato come eseguirle in seguito.

Per affrontare un problema di prestazioni al momento, è necessario eseguire una traccia quando si è verificato tale problema. Occorre avere a disposizione gli strumenti appropriati per raccogliere log ed è necessario un piano d'azione, ossia un elenco di azioni di risoluzione dei problemi da eseguire per raccogliere le migliori informazioni possibili. La prima operazione da eseguire consiste nel registrare la data e l'ora del test, in modo che i file possano essere salvati in una cartella che rifletta questo momento. In seguito, restringere l'operazione ai passaggi stessi del problema. Si tratta dei passaggi da eseguire per i test. Tenere presenti le indicazioni di base: se il problema riguarda solo Outlook, assicurarsi di annotare che il comportamento problematico si verifica in un unico servizio di Office 365. Restringendo l'ambito del problema sarà possibile concentrarsi sulla procedura da eseguire per risolverlo.

Vedere anche

Gestione degli endpoint di Office 365

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.

×