Reglarea performanței Office 365 utilizând niveluri de referință și istoricul performanței

Există câteva moduri simple de a verifica performanța conexiunii dintre Office 365 și firma dvs., care vă permit să stabiliți un nivel brut de referință al conectivității. Cunoașterea istoricului de performanță al conexiunilor computerului dvs. client vă poate ajuta să detectați probleme în curs de dezvoltare mai devreme, să identificați și să prevedeți problemele.

Dacă nu sunteți obișnuit să remediați probleme de performanță, acest articol are rolul de a vă aduce în atenție câteva întrebări comune, precum: de unde știți că problema pe care o întâmpinați este o problemă de performanță și nu un incident de serviciu Office 365? Cum puteți planifica pentru o performanță bună, pe termen lung? Cum puteți monitoriza performanța? Dacă echipa sau clienții dvs. întâmpină performanțe lente în timp ce utilizează Office 365 și vă puneți oricare dintre aceste întrebări, citiți mai departe.

Important : Aveți o problemă de performanță între client și Office 365 chiar acum? Urmați pașii subliniați în Plan de depanare a performanței pentru Office 365.

Lucruri de reținut despre performanța Office 365

Office 365 se află în interiorul unei rețele Microsoft dedicate, de mare capacitate, care este monitorizată constant nu doar în mod automat, ci și de persoane reale. O parte din rolului întreținerii mediului cloud Office 365 este de a încorpora reglaje de performanță și de a eficientiza acolo unde este posibil. Deoarece clienții din cloud Office 365 trebuie să se conecteze prin internet, există un efort continuu de a ajusta în detaliu performanța și în serviciile Office 365. Îmbunătățirile performanței nu se opresc niciodată în cloud și există o mulțime de experiență acumulată în a păstra mediul cloud sănătos și rapid. În cazul în care vă confruntați cu o problemă de performanță la conectarea din locația dvs. la Office 365, este cel mai bine să nu începeți și să așteptați rezolvarea unui caz de asistență. În schimb, ar trebui să începeți investigarea problemei „din interior”. Adică să începeți din interiorul rețelei dvs. și să mergeți spre Office 365. Înainte de a deschide un caz de asistență Office 365, puteți să colectați date și să efectuați acțiuni care vor explora problema și ar putea s-o rezolve.

Important : Înțelegeți limitele și planificarea capacității în Office 365. Aceste informații vă vor oferi un avantaj atunci când încercați să rezolvați o problemă de performanță. Iată un link către Descrierea serviciilor platformei Office 365. Acesta este un hub central și toate serviciile oferite de Office 365 au un link care merge la propria descriere a serviciului de aici. Acest lucru înseamnă că, dacă trebuie să vedeți limitele standard pentru SharePoint Online, de exemplu, faceți clic pe Descrierea serviciului SharePoint Online și găsiți secțiunea Limite pentru SharePoint Online.

Nu uitați să începeți depanarea fiind conștient că performanța nu este o scală glisantă, nu este vorba de a atinge o valoare idealizată și de a o face permanentă (dacă aceasta este opinia dvs., activitățile ocazionale care necesită o lățime mare de bandă, cum ar fi înscrierea unui număr mare de utilizatori sau migrarea de date mari, vor fi foarte stresante, deci luați în calcul impactul lor asupra performanței). Puteți și ar trebui să aveți o idee generală despre obiectivele dvs. de performanță, dar ele sunt afectate de multe variabile, prin urmare, performanța variază. Aceasta este natura performanței.

Depanarea performanței nu se reduce la atingerea anumitor obiective și menținerea lor pe o perioadă nedeterminată, ci la îmbunătățirea activităților existente, având în vedere toate variabilele.

Bine, cum arată o problemă de performanță?

Mai întâi, trebuie să vă asigurați că ceea ce întâmpinați este într-adevăr o problemă de performanță și nu un incident de serviciu. O problemă de performanță este diferită de un incident de serviciu în Office 365. Iată cum să le deosebiți.

Dacă serviciul Office 365 are probleme, este un incident de serviciu. Veți vedea pictograme galbene sau roșii sub Starea curentă în centrul de administrare Office 365 și puteți observa performanțe lente pe computerele client care se conectează la Office 365. De exemplu, dacă Starea curentă raportează o pictogramă roșie și vedeți Se investighează lângă Exchange, este posibil să primiți o serie de apeluri de la persoane din organizație care se plâng de performanța slabă a cutiilor poștale client care utilizează Exchange Online. În acest caz, se poate presupune că performanța dvs. Exchange Online a devenit o victimă a unor probleme din cadrul serviciului.

Tabloul de bord pentru Starea Office 365 cu toate soluțiile colorate în verde, cu excepția Exchange, care afișează Serviciu restaurat.

În acest moment, dvs., administratorul Office 365, trebuie să verificați frecvent Starea curentă, apoi Vedeți detaliile și istoricul, pentru a rămâne la curent cu operațiunile de întreținere efectuate de noi asupra sistemului. Tabloul de bord Stare curentă a fost creat pentru a vă anunța despre modificările și problemele din serviciu. Notele și explicațiile scrise în istoricul de sănătate, de la administrator la administrator, sunt acolo pentru a vă ajuta să vă măsurați impactul și a vă ține la curent cu activitățile în curs.

O imagine a tabloului de bord cu starea Office 365 care explică faptul că s-a restaurat serviciul Exchange Online și de ce.

O problemă de performanță nu este un incident de serviciu, deși incidentele pot provoca performanțe lente. O problemă de performanță arată astfel:

  • O problemă de performanță are loc indiferent ce raportează Starea curentă din centrul de administrare Office 365 pentru serviciu.

  • Un comportament care se desfășura relativ fără poticniri durează mult timp sau nu se mai termină.

  • Puteți reproduce problema sau, cel puțin, știți că va apărea dacă parcurgeți o anumită secvență de pași.

  • Dacă problema este intermitentă, există totuși un tipar, de exemplu, știți că până la ora 10:00 veți primi apeluri de la utilizatori care nu pot accesa fiabil Office 365 și știți că apelurile vor înceta în jurul prânzului.

Acest lucru sună probabil familiar; poate prea familiar. Odată ce știți că este o problemă de performanță, apare întrebarea „Ce facem acum?” Restul acestui articol vă ajută să determinați exact acest lucru.

Cum se definește și se testează problema de performanță

Problemele de performanță apar adesea în timp, astfel încât poate fi o provocare să definiți adevărata problemă. Trebuie să creați un bun enunț al problemei și să înțelegeți bine contextul problemei, apoi să repetați pașii de testare pentru a reuși. Altfel, este posibil să vă pierdeți, deși nu din vina dvs. De ce? Ei bine, iată câteva exemple de enunțuri de probleme care nu furnizează suficiente informații:

  • Înainte nici nu observam când treceam de la Inbox la calendar, iar acum durează cât toată pauza de cafea. Îl puteți face să meargă ca înainte?

  • Încărcarea fișierelor mele în SharePoint Online pare că nu se mai termină. De ce este lent după-amiaza, dar rapid în orice altă perioadă? Nu poate fi rapid tot timpul?

Enunțurile de probleme de mai sus pun câteva provocări mari. Mai exact, sunt o mulțime de ambiguități de tratat. De exemplu:

  • Nu este clar cum funcționa înainte comutarea între Inbox și Calendar pe laptop.

  • Atunci când utilizatorul întreabă „Nu poate fi rapid tot timpul”, ce înseamnă pentru el „rapid”?

  • Cât timp înseamnă „nu se mai termină”? Câteva secunde, minute sau poate suficient timp cât să poată utilizatorul lua prânzul și să se termine la zece minute după ce a ajuns înapoi?

Toate acestea, fără a lua în considerare că administratorul și depanatorul nu pot afla multe detalii din enunțuri de probleme ca acestea. De exemplu, când a început să apară problema; dacă utilizatorul lucrează de acasă și trecerile lente apar doar într-o rețea de domiciliu; dacă utilizatorul trebuie să ruleze mai multe alte aplicații care consumă multă memorie RAM pe clientul local sau dacă rulează un sistem de operare mai vechi sau nu a rulat actualizările recente.

Atunci când utilizatorii raportează o problemă de performanță, sunt multe informații de colectat. Colectarea acestor informații face parte dintr-un proces denumit identificarea problemei sau investigarea acesteia. Urmează o listă de bază de identificare pe care o puteți utiliza pentru a colecta informații despre problema dvs. de performanță. Lista nu este exhaustivă, dar este un punct bun de plecare pentru a crea una proprie:

  • Pe ce dată a apărut problema și aproximativ la ce oră?

  • Ce tip de computer client utilizați atunci și cum se conectează acesta la rețeaua de business (VPN, cu fir, wireless)?

  • La momentul respectiv, lucrați la distanță sau erați la birou?

  • Ați încercat aceeași acțiuni pe un alt computer și ați văzut același comportament?

  • Parcurgeți pașii care vă fac probleme, pentru a putea scrie pe ceva acțiunile efectuate.

  • Cât de lentă este performanța, în secunde sau minute?

  • Unde vă aflați din punct de vedere geografic?

Unele dintre aceste întrebări sunt mai evidente ca altele. Aproape toată lumea va înțelege că un depanator are nevoie de pașii exacți pentru a reproduce problema. Cum altfel puteți înregistra ce se întâmplă și cum vă puteți testa dacă s-a remediat problema? Mai puțin evidente ar fi informațiile precum „La ce dată și oră ați observat problema?” și „Unde vă aflați din punct de vedere geografic?”, informații care pot fi utilizate împreună. În funcție de ora când lucra utilizatorul, o diferență de câteva ore poate însemna că întreținerea este deja în curs de desfășurare pentru anumite părți ale rețelei dvs. de firmă. Dacă, de exemplu, firma dvs. are o implementare hibridă, cum ar fi o Căutare SharePoint hibridă, care poate interoga indexuri de căutare atât din SharePoint Online, cât și dintr-o instanță locală SharePoint Server 2013 locală, actualizările pot fi în curs de desfășurare la ferma locală. Dacă firma dvs. este toată în cloud, întreținerea sistemului poate include adăugarea sau eliminarea de hardware de rețea, lansarea actualizărilor de la nivelul firmei sau efectuarea de modificări asupra DNS sau a altei infrastructuri de bază.

Atunci când depanați o problemă de performanță, seamănă puțin cu studierea locului unei infracțiuni; trebuie să fiți atent pentru a trage orice concluzii din dovezile existente. Pentru a face acest lucru, trebuie să obțineți un bun enunț al problemei, adunând dovezi. Acestea trebuie să includă contextul computerului, contextul utilizatorului, când a început problema și pașii exacți care au expus problema de performanță. Enunțul problemei ar trebui să fie și să rămână pe prima pagină din notele dvs. Prin parcurgerea enunțului problemei din nou după ce lucrați la rezolvarea acestuia, efectuați pașii necesari pentru a testa și a dovedi dacă acțiunile efectuate au rezolvat problema. Acest lucru este esențial pentru a ști când terminați lucrul.

Știți cum funcționa când era bine?

Dacă sunteți ghinionist, nimeni nu știe. Nimeni nu avea cifrele exacte. Aceasta înseamnă că nimeni nu poate răspunde la întrebarea simplă „Cam câte secunde erau necesare pentru a deschide un Inbox în Office 365?” sau „Cât timp dura când era o întâlnire Lync Online a directorilor?”, un scenariu comun pentru multe firme.

Ce lipsește de aici este un nivel de referință al performanței.

Nivelurile de referință vă oferă un context al performanței. Ar trebui să înregistrați un nivel de referință ocazional sau chiar frecvent, în funcție de necesitățile firmei dvs. Dacă sunteți o companie mai mare, echipa dvs. de operațiuni poate înregistra deja niveluri de referință pentru mediul local. De exemplu, dacă efectuați corecții asupra tuturor serverelor Exchange în prima zi de luni din lună și asupra tuturor serverelor SharePoint în a treia zi de luni, echipa de operațiuni are probabil o listă de activități și scenarii pe care le rulează după corecție, pentru a demonstra că funcțiile critice sunt operaționale. De exemplu, deschiderea Inboxului, un clic pe Trimitere/Primire și asigurarea că se actualizează folderele sau, în SharePoint, navigarea la pagina principală a site-ului, intrarea în pagina Căutare pentru întreprindere și efectuarea unei căutări care returnează rezultate.

Dacă aplicațiile dvs. sunt în Office 365, unele dintre cele mai fundamentale niveluri de referință pe care le puteți nota măsoară timpul (în milisecunde) de la un computer client din rețeaua dvs. la un punct de ieșire sau la punctul în care părăsiți rețeaua dvs. și accesați Office 365. Iată câteva niveluri de referință utile pe care puteți să le investigați și să le înregistrați:

  • Identificați dispozitivele dintre computerul client și punctul de ieșire, de exemplu, serverul proxy.

    • Trebuie să vă cunoașteți dispozitivele, pentru a cunoaște contextul oricăror probleme de performanță care apar (adresele IP, tipul de dispozitiv etc).

    • Serverele proxy sunt puncte de ieșire uzuale, astfel că puteți verifica browserul web pentru a vedea ce server proxy este setat să se utilizeze, dacă există vreunul.

    • Există instrumente de la terți care pot să vă descopere și să vă mapeze rețeaua, dar cea mai sigură modalitate de a vă cunoaște dispozitivele este să întrebați un membru al echipei dvs. de rețea.

  • Identificați furnizorul de servicii internet (ISP), scrieți informațiile sale de contact și întrebați câte circuite și ce lățime de bandă aveți.

  • În interiorul firmei, identificați resursele pentru dispozitivele dintre client și punctul de ieșire sau identificați o persoană de contact de urgență cu care să discutați despre problemele de rețea.

Iată câteva niveluri de referință care se pot calcula ușor, folosind instrumente de testare:

  • Timpul de la computerul client la punctul de ieșire, în milisecunde

  • Timpul de la punctul de ieșire la Office 365, în milisecunde

  • Locația din lume a serverului care rezolvă URL-urile pentru Office 365 atunci când navigați

  • Viteza de rezoluție DNS a ISP-ului dvs. în milisecunde, inconsistențele la sosirea pachetelor (variațiile rețelei), timpii de încărcare și descărcare în milisecunde

Dacă nu sunteți familiarizat cu efectuarea acestor pași, vom intra în mai multe detalii în acest articol.

Ce este un nivel de referință?

Veți ști impactul atunci când lucrurile nu merg bine, dar dacă nu vă știți datele istorice de performanță, nu veți putea avea la dispoziție un context pentru a ști cât de rea a devenit situația și când. Astfel, fără un nivel de referință, ratați indiciul cheie pentru a rezolva puzzle-ul: imaginea de pe cutia de puzzle. În depanarea performanței, aveți nevoie de un punct de comparație. Nivelurile de referință simple ale performanței nu sunt greu de înregistrat. Echipa de operațiuni poate fi însărcinată să efectueze această activitate conform unui program. De exemplu, să presupunem aveți o conexiune care arată astfel:

Un grafic de rețea elementar care afișează clientul, proxy și mediul cloud Office 365.

Aceasta înseamnă că ați verificat cu echipa de rețea și ați aflat că ieșiți din firmă spre internet printr-un server proxy și că acesta gestionează toate solicitările pe care le trimite computerul client în cloud. În acest caz, ar trebui să desenați o versiune simplificată a conexiunii, care listează toate dispozitivele ce intervin. Acum inserați instrumente pe care le puteți utiliza pentru a testa performanța dintre client, punctul de ieșire (de unde plecați din rețea spre internet) și mediul cloud Office 365.

Rețea de bază cu client, proxy și mediu cloud și sugestii de instrumente PSPing, TraceTCP și urmărire de rețea.

Opțiunile sunt listate drept Simple și Complexe din cauza volumului de experiență de care aveți nevoie pentru a găsi datele despre performanță. O trasare de rețea va dura mult timp, comparativ cu rularea de instrumente în linia de comandă, cum ar fi PsPing și TraceTCP. Aceste două instrumente în linia de comandă au fost alese pentru că nu utilizează pachete ICMP, care vor fi blocate de Office 365, și pentru că oferă durata (în milisecunde) necesară pentru a părăsi computerul client sau serverul proxy (dacă aveți acces) și a ajunge la Office 365. Fiecare salt individual de la un computer la altul se va încheia cu o valoare de timp, iar acest lucru este grozav pentru nivelurile de referință! La fel de important, aceste instrumente din linia de comandă vă permit să adăugați un număr de port în comandă, iar acest lucru este util pentru că Office 365 comunică prin portul 443, care este portul utilizat de SSL și TLS. Cu toate acestea, alte instrumente de la terți pot fi soluții mai bune pentru situația dvs. Microsoft nu acceptă toate aceste instrumente, așadar dacă, din anumite motive, nu puteți utiliza PsPing și TraceTCP, treceți la o trasare de rețea folosind un instrument precum Netmon.

Puteți înregistra un nivel de referință înainte de începerea programului de lucru, din nou în perioada de maximă utilizare, apoi din nou după sfârșitul programului. Aceasta înseamnă că este posibil să aveți o structură de foldere care arată similar cu aceasta:

Grafic care propune o modalitate de a organiza datele referitoare la performanță în foldere.

De asemenea, ar trebui să alegeți o convenție de denumire a fișierelor. Iată câteva exemple:

  • 09_Feb_2015_9amEET_ReferPerformanță_Netmon_ClientSpreIeșire_Normal

  • 10_Ian_2015_3pmEET_ReferPerformanță_PsPing_ClientLaO365_ocolireProxy_LENT

  • 08_Feb_2015_2pmEET_ReferPerformanță_PerformSLABĂ

  • 08_Feb_2015_8-30amEET_ReferPerformanță_PerformBună

Există multe moduri diferite de a face acest lucru, dar utilizarea formatului <dateTime><what's happening in the test> este un bun punct de pornire. Perseverența vă va ajuta mult atunci când încercați să depanați problemele mai târziu. Veți putea spune „am efectuat două trasări pe 8 februarie, una a arătat o performanță buna și una a arătat o performanță slabă, iar acum le putem compara”. Acest lucru este extrem de util pentru depanare.

Trebuie să aveți o modalitate organizată de a vă păstra nivelurile de referință istorice. În acest exemplu, metodele simple au produs trei ieșiri de linie de comandă, iar rezultatele au fost colectate sub forma unor capturi de ecran, dar este posibil ca dvs. să aveți fișiere captură de rețea în schimb. Utilizați metoda cea mai potrivită pentru dvs. Stocați nivelurile de referință istorice și consultați-le atunci când observați modificări ale comportamentului serviciilor online.

De ce să colectați date despre performanță în timpul unui pilot?

Nu există niciun moment mai bun pentru a începe să creați niveluri de referință, decât în timpul unui pilot al serviciului Office 365. Firma dvs. poate avea mii de utilizatori, sute de mii sau poate doar cinci, dar chiar și cu un număr mic de utilizatori, puteți efectua teste pentru a măsura fluctuațiile performanței. În cazul unei firme mari, un eșantion reprezentativ de câteva sute de utilizatori care utilizează pilotul Office 365 poate fi proiectat la câteva mii, astfel încât să știți unde pot apărea problemele înainte ca acest lucru să se întâmple.

În cazul unei firme mici, unde înscrierea înseamnă că toți utilizatorii accesează serviciul în același timp și nu există niciun pilot, păstrați măsurile de performanță, astfel încât să aveți date pe care să le puteți arăta oricărei persoane care trebuie să depaneze o operațiune care nu funcționează bine. De exemplu, dacă observați că, dintr-o dată, puteți face o plimbare în jurul clădirii în timpul necesar pentru a încărca o imagine de dimensiune medie, pe când înainte, acest lucru se făcea foarte repede.

Cum se colectează nivelurile de referință

Pentru toate planurile de depanare, trebuie să identificați cel puțin aceste lucruri:

  • Computerul client utilizat (tipul de computer sau dispozitiv, o adresă IP și acțiunile care au provocat problema)

  • Unde se află computerul client în lume (de exemplu, dacă acest utilizator folosește o rețea VPN, lucrează de la distanță sau pe intranetul firmei)

  • Punctul de ieșire pe care îl utilizează computerul client din rețea (punctul în care traficul părăsește firma dvs. și pleacă spre un ISP sau spre internet)

Puteți afla care este structura rețelei de la administratorul de rețea. Dacă vă aflați într-o rețea mică, uitați-vă la dispozitivele care vă conectează la internet și apelați ISP-ul dacă aveți întrebări despre structura rețelei. Creați o ilustrație a structurii finale, pentru referință.

Această secțiune este împărțită în metode și instrumente în linie de comandă simple și mai multe opțiuni de instrumente complexe. Vom acoperi mai întâi metodele simple. Dar dacă aveți o problemă de performanță chiar acum, ar trebui să treceți la metodele complexe și să încercați mostra noastră de plan de acțiune pentru depanarea performanței.

Metode simple

Obiectivul acestor metode simple este să învățați să înregistrați, să înțelegeți și să stocați corect niveluri de referință ale performanței simple, în timp, astfel încât să fiți informat despre performanța Office 365. Iată o diagramă foarte simplă, așa cum ați văzut anterior:

Rețea de bază cu client, proxy și mediu cloud și sugestii de instrumente PSPing, TraceTCP și urmărire de rețea.

Note : 

  • TraceTCP este inclus în această captură de ecran, deoarece este un instrument util pentru a afișa, în milisecunde, durata necesară pentru procesarea unei solicitări și câte salturi de rețea sau conexiuni de la un computer la altul sunt necesare pentru a ajunge la o destinație. TraceTCP vă poate furniza, de asemenea, numele serverelor utilizate în timpul salturilor, care pot fi utile unui depanator Microsoft Office 365 în asistență.

  • Comenzile TraceTCP pot fi foarte simple, precum:

  • tracetcp.exe outlook.office365.com:443

  • Nu uitați să includeți numărul de port în comandă!

  • TraceTCP este o descărcare gratuită, dar se bazează pe Wincap. Wincap este un instrument care este utilizat și instalat, de asemenea, de Netmon. Utilizăm Netmon și în secțiunea de metode complexe.

Dacă aveți mai multe birouri, va trebui să păstrați un set de date de la un client în fiecare dintre aceste locații. Acest test măsoară latența care, în acest caz, este o valoare numerică ce descrie perioada de timp dintre trimiterea unei solicitări de către un client la Office 365 și răspunsul Office 365 la solicitare. Testarea este inițiată în domeniul dvs., pe un computer client, și încearcă să măsoare o rută dus-întors din interiorul rețelei dvs. până la un punct de ieșire, pe internet până la Office 365 și înapoi.

Există mai multe modalități de a gestiona punctul de ieșire, în acest caz, serverul proxy. Puteți să trasați de la 1 la 2 și apoi de la 2 la 3 și apoi să adunați valorile în milisecunde pentru a obține un total final către marginea rețelei. Sau puteți configura conexiunea să ocolească proxy-ul pentru adresele Office 365. Într-o rețea mai mare cu un firewall, un proxy invers sau o combinație între cele două, poate fi nevoie să faceți excepții pe serverul proxy care vor permite traficul pentru multe URL-uri. Pentru lista de puncte finale utilizate de Office 365, consultați Adrese URL și intervale de adrese IP Office 365. Dacă aveți un proxy de autentificare, începeți prin testarea excepțiilor pentru următoarele:

  • Porturile 80 și 443

  • TCP și HTTPs

  • Conexiuni care ies spre oricare dintre aceste URL-uri:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Toți utilizatorii trebuie să poată accesa aceste adrese fără autentificare sau interferențe proxy. Într-o rețea mai mică, trebuie să le adăugați la lista de ocolire proxy din browserul web.

Pentru a le adăuga la lista de ocolire proxy din Internet Explorer, accesați Instrumente > Opțiuni internet > Conexiuni > Setări LAN > Complex. Fila Complex este și locul unde veți găsi serverul proxy și portul de server proxy. Poate fi necesar să faceți clic pe caseta de selectare Utilizare server proxy pentru rețeaua locală, pentru a accesa butonul Complex. Se recomandă să vă asigurați că este bifată opțiunea Evitare server proxy pentru adresele locale. După ce faceți clic pe Complex, veți vedea o casetă text unde puteți introduce excepții. Separați URL-urile wildcard listate mai sus cu punct și virgulă, de exemplu:

*.microsoftonline.com; *.sharepoint.com

După ce treceți de proxy, ar trebui să puteți utiliza ping sau PsPing direct pe un URL Office 365. Următorul pas va fi să faceți un ping de testare la outlook.office365.com. Sau, dacă utilizați PsPing sau alt instrument care vă va permite să furnizați un număr de port pentru comandă, rulați PsPing la portal.microsoftonline.com:443 pentru a vedea timpul mediu dus-întors în milisecunde.

Timpul dus-întors, sau RTT (round trip time), este o valoare numerică ce măsoară cât timp durează să trimiteți o solicitare HTTP la un server ca outlook.office365.com și să obțineți un răspuns care arată că serverul știe că ați făcut acest lucru. Îl veți vedea uneori abreviat ca RTT. Ar trebui să fie un timp relativ scurt.

Pentru a face acest test, trebuie să utilizați PSPing sau alt instrument care nu utilizează pachete ICMP blocate de Office 365.

Cum se utilizează PsPing pentru a obține un timp de revenire întors total, în milisecunde, direct de la un URL Office 365

  1. Rulați o linie de comandă elevată, efectuând acești pași:

    1. Faceți clic pe Start.

    2. În caseta Pornire căutare tastați cmd, apoi apăsați CTRL+SHIFT+ENTER.

    3. Dacă apare caseta de dialog Control cont utilizator, confirmați că acțiunea afișată este ceea ce doriți, apoi faceți clic pe Continuare.

  2. Navigați la folderul unde este instalat instrumentul (în acest caz PsPing) și testați aceste URL-uri Office 365:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      Comanda PSPing care accesează microsoft-my.sharepoint.com port 443.

Nu uitați să includeți numărul de port 443. Rețineți că Office 365 funcționează pe un canal criptat. Dacă faceți PsPing fără numărul de port, solicitarea dvs. nu va reuși. După ce ați făcut ping cu lista scurtă, căutați timpul mediu în milisecunde (ms). Pe acesta doriți să-l înregistrați!

Grafic care afișează o ilustrație a acțiunii PSPing client-proxy, cu un timp dus-întors de 2,8 milisecunde.

Dacă nu sunteți familiarizat cu ocolirea proxy și preferați să luați lucrurile pas cu pas, trebuie să aflați mai întâi numele serverului proxy. În Internet Explorer, accesați Instrumente > Opțiuni internet > Conexiuni > Setări LAN > Complex. Fila Complex este locul unde veți vedea serverul proxy listat. Faceți ping acelui server proxy la o linie de comandă, astfel:

Pentru a face ping serverului proxy și a obține o valoare de revenire în milisecunde pentru faza 1-2

  1. Rulați o linie de comandă elevată, efectuând acești pași:

    1. Faceți clic pe Start.

    2. În caseta Pornire căutare tastați cmd, apoi apăsați CTRL+SHIFT+ENTER.

    3. Dacă apare caseta de dialog Control cont utilizator, confirmați că acțiunea afișată este ceea ce doriți, apoi faceți clic pe Continuare.

  2. Tastați ping <numele serverului proxy pe care îl utilizează browserul dvs. sau adresa IP a serverului proxy>, apoi apăsați ENTER. Dacă aveți PsPing sau alt instrument instalat, puteți alege să utilizați în schimb acel instrument.

    Comanda dvs. poate arăta ca unul din aceste exemple:

    • 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. Atunci când trasarea nu mai trimite pachete de test, veți obține un rezumat mic ce listează o medie în milisecunde și aceea este valoarea dorită. Faceți o captură de ecran cu promptul și salvați-o utilizând convenția de denumire. În acest moment, aceasta poate ajuta și la completarea diagramei cu valoarea.

Poate că ați efectuat o trasare dimineața devreme și clientul dvs. poate ajunge rapid la proxy (sau la serverul de ieșire care merge spre internet). În acest caz, valorile dvs. pot arăta astfel:

Grafic care afișează timpul dus-întors de la un client la un proxy de 2,8 milisecunde.

În cazul în care computerul dvs. client este unul dintre puținele cu acces la serverul proxy (sau de ieșire), puteți rula următoarea parte a testului conectându-vă de la distanță la computerul respectiv și rulând linia de comandă pentru PsPing la un URL Office 365 de acolo. Dacă nu aveți acces la respectivul computer, puteți contacta resursele dvs. de rețea pentru ajutor în etapa următoare și pentru a obține valorile exacte. Dacă acest lucru nu este posibil, faceți un PsPing pentru URL-ul Office 365 respectiv și comparați-l cu durata PsPing sau Ping față de serverul dvs. proxy.

De exemplu, dacă aveți 51,84 milisecunde de la client la URL-ul Office 365 și 2,8 milisecunde de la client la proxy (sau la punctul de ieșire), aveți 49,04 milisecunde de la ieșire la Office 365. La fel, dacă aveți un PsPing de 12,25 milisecunde de la client la proxy în intervalul din zi de maximă utilizare și 62,01 milisecunde de la client la URL-ul Office 365, valoarea medie pentru ieșirea proxy la URL-ul Office 365 este de 49,76 milisecunde.

Grafic suplimentar care afișează acțiunea ping în milisecunde de la client la proxy lângă cea de la client la Office 365, astfel încât valorile să poată fi scăzute.

În ce privește depanarea, puteți găsi ceva interesant și doar dacă păstrați aceste niveluri de referință. De exemplu, dacă observați că, în general, aveți între 40 și 59 milisecunde de latența de la proxy sau de la punctul de ieșire la URL-ul Office 365 și aveți o latență de la client la proxy sau la punctul de ieșire de 3 - 7 milisecunde (în funcție de traficul de rețea din perioada respectivă a zilei), veți ști sigur că există o problemă dacă ultimele trei niveluri de referință de la client la proxy sau la punctul de ieșire arată o latență de 45 milisecunde.

Metode complexe

Dacă doriți să știți ce se întâmplă cu solicitările de internet pentru Office 365, trebuie să vă familiarizați cu urmărirea de rețea. Nu contează ce instrumente preferați pentru aceste urmăriri, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard sau altele, oricare dintre acestea va funcționa dacă poate să captureze și să filtreze traficul de rețea. În această secțiune, veți vedea că este bine să rulați mai multe dintre aceste instrumente pentru a obține o imagine mai cuprinzătoare a problemei. Atunci când testați, unele dintre aceste instrumente acționează și ca proxy-uri independente. Între instrumentele utilizate din articolul însoțitor, Plan de depanare a performanței pentru Office 365, se numără Netmon 3.4, HTTPWatch sau WireShark.

Înregistrarea unui nivel de referință de performanță este partea simplă a acestei metode și mulți pași sunt la fel ca atunci când depanați o problemă de performanță. Metodele mai complexe de a crea niveluri de referință pentru performanță necesită să efectuați și să stocați trasări de rețea. Majoritatea exemplelor din acest articol utilizează SharePoint Online, dar ar trebui să dezvoltați o listă de acțiuni obișnuite în serviciile Office 365 la care vă abonați, pentru a le testa și a le înregistra. Iată un exemplu de nivel de referință:

  • Listă de referință pentru SPO - Pasul 1: Navigați la pagina de pornire a site-ului web SPO și faceți o trasare de rețea. Salvați trasarea.

  • Listă de referință pentru SPO - Pasul 2: Căutați un termen (cum ar fi numele firmei dvs.) prin Căutarea de întreprindere și faceți o trasare de rețea. Salvați trasarea.

  • Listă de referință pentru SPO - Pasul 3: Încărcați un fișier mare într-o bibliotecă de documente SharePoint Online și faceți o trasare de rețea. Salvați trasarea.

  • Listă de referință pentru SPO - Pasul 4: Navigați la pagina de pornire a site-ului web OneDrive și faceți o trasare de rețea. Salvați trasarea.

Această listă trebuie să includă cele mai importante acțiuni uzuale pe care le efectuează utilizatorii pe SharePoint Online. Observați că ultimul pas, trasarea spre OneDrive pentru business, include o comparație între sarcina paginii de pornire SharePoint Online (care este adesea particularizată de firme) și pagina de pornire OneDrive pentru business, care este rareori particularizată. Acesta este un test foarte simplu atunci când vine vorba de un site SharePoint Online care se încarcă lent. Puteți construi o înregistrare a acestei diferențe în testarea dvs.

Dacă sunteți în mijlocul unei probleme de performanță, mulți pași sunt similar ca atunci când înregistrați un nivel de referință. Trasările de rețea devin critice, astfel că vom explica cum se efectuează trasările importante în continuare.

Pentru a aborda o problemă de performanță, chiar acum, trebuie să efectuați o trasare în momentul în care întâmpinați problema de performanță. Trebuie să aveți instrumentele potrivite disponibile pentru a colecta jurnale și aveți nevoie de un plan de acțiune, adică de o listă de acțiuni de depanare pentru a colecta informațiile cele mai bune. Primul lucru pe care trebuie să-l faceți este să înregistrați data și ora testului, astfel încât fișierele să poată fi salvate într-un folder care reflectă momentul. În continuare, restrângeți la pașii problemei propriu-zise. Acestea sunt pașii exacți pe care îi veți utiliza pentru testare. Nu uitați lucrurile de bază: dacă problema este doar cu Outlook, aveți grijă să înregistrați faptul că problema apare într-un singur serviciu Office 365. Restrângerea domeniului de acoperire al acestei probleme vă va ajuta să vă concentrați pe un element pe care îl puteți rezolva.

Consultați și

Gestionarea punctelor finale Office 365

Extindeți-vă competențele
Explorați instruirea
Fiți primul care obține noile caracteristici
Alăturați-vă utilizatorilor Office Insider

Au fost utile aceste informații?

Vă mulțumim pentru feedback!

Vă mulțumim pentru feedback! Se pare că ar fi util să luați legătura cu unul dintre agenții noștri de asistență Office.

×