Office
Pierakstīties

Office 365 veiktspējas pielāgošana, izmantojot bāzes datus un veiktspējas vēsturi

Ir vairāki vienkārši veidi, kā pārbaudīt Office 365 un jūsu uzņēmuma savienojuma veiktspēju un noteikt aptuvenus savienojuma pamata datus. Zināšanas par klientu datoru savienojumu veiktspējas vēsturi var palīdzēt laicīgi noteikt, identificēt un paredzēt problēmas.

Ja jums trūkst pieredzes darbā ar veiktspējas problēmām, šis raksts sniegs atbildes uz bieži uzdotiem jautājumiem, piemēram — kā noteikt, vai problēma ir veiktspējas problēma, nevis Office 365 pakalpojuma incidents? Kā nodrošināt labu veiktspēju ilgtermiņā? Kā uzraudzīt veiktspēju? Ja jūsu darba grupa vai klienti konstatē lēnu veiktspēju, lietojot Office 365, un jūs nodarbina iepriekš minētie jautājumi, šis raksts ir paredzēts jums.

Svarīgi!: Vai šobrīd pastāv veiktspējas problēma starp jūsu klientu un Office 365? Izpildiet darbības, kas norādītas sadaļā Veiktspējas problēmu novēršanas plāns pakalpojumam Office 365.

Lietas, kas jāzina par Office 365 veiktspēju

Office 365 tiek uzturēts lielas veiktspējas atvēlētā Microsoft tīklā, ko nepārtraukti uzrauga ne tikai automātika, bet arī cilvēki. Office 365 mākoņa uzturēšanā ietilpst veiktspējas pielāgošana un racionalizēšana visās iespējamās sfērās. Tā kā Office 365 mākoņa klientiem ir jāizveido savienojums ar internetu, nepārtraukti tiek veikta veiktspējas pielāgošana arī visos Office 365 pakalpojumos. Veiktspējas uzlabojumi nekad nebeidzas ar mākoni, un tiek uzkrāta apjomīga pieredze, uzturot mākoni darbspējīgu un ātru. Ja rodas veiktspējas problēma, veidojot savienojumu no savas atrašanās vietas ar pakalpojumu Office 365, labāk nesākt problēmas novēršanu ar atbalsta pieteikuma izveidi un atbildes gaidīšanu. Tā vietā sāciet problēmas izmeklēšanu no iekšpuses. Respektīvi, sāciet savā tīklā un izmēģiniet savienojuma izveidi ar Office 365. Pirms atvērt pieteikumu Office 365 atbalsta dienestā, varat savākt datus un veikt darbības, lai izpētītu un, iespējams, novērstu savu problēmu.

Svarīgi!: Ņemiet vērā kapacitātes plānošanu un ierobežojumus pakalpojumā Office 365. Šī informācija ļaus jums iepriekš sagatavoties veiktspējas problēmu novēršanai. Šeit ir saite uz Office 365 platformas pakalpojuma aprakstu. Šī ir centrālā vieta, un šeit visiem Office 365 pakalpojumiem ir pievienota saite uz atbilstošā pakalpojuma aprakstu. Tātad, ja vēlaties uzzināt, piemēram, SharePoint Online standarta ierobežojumus, jums ir jānoklikšķina uz saites SharePoint Online pakalpojuma apraksts un jāatrod SharePoint Online ierobežojumu sadaļa.

Veiciet problēmu novēršanu, ņemot vērā, ka veiktspēja ir mainīgs lielums, un mērķis nav sasniegt idealizētu vērtību un to saglabāt nemainīgu (ja uzskatāt, ka tas ir iespējams, apjomīgu platjoslas uzdevumu izpilde, piemēram, liela lietotāju skaita pievienošanās vai apjomīgas datu migrācijas, būs ļoti sarežģīta, tāpēc plānošanas laikā ņemiet vērā veiktspējas ietekmi). Jums jābūt aptuvenam priekšstatam par veiktspējas mērķiem, taču veiktspēju ietekmē plašs mainīgo lielumu klāsts, tāpēc tā var būt dažāda. Tāda ir veiktspējas būtība.

Veiktspējas problēmu novēršana nav vērsta uz noteiktu mērķu sasniegšanu un to nepārtrauktu uzturēšanu, bet esošo aktivitāšu uzlabošanu, ņemot vērā visas mainīgās vērtības.

Labi, kāda ir veiktspējas problēma?

Vispirms jums jāpārliecinās, ka patiešām ir radusies veiktspējas problēma, nevis pakalpojuma incidents. Veiktspējas problēma atšķiras no pakalpojuma incidenta pakalpojumā Office 365. Šeit aprakstīts, kā tās atšķirt.

Ja Office 365 pakalpojumam ir radusies problēma, tas ir pakalpojuma incidents. Redzēsit sarkanas vai dzeltenas ikonas sadaļā Pašreizējā darbspēja Office 365 administrēšanas centrā, iespējams, klientu datoriem, kas izveido savienojumu ar Office 365, būs lēna veiktspēja. Piemēram, ja pašreizējā darbspēja uzrāda sarkanu ikonu un blakus Exchange parādās ziņojums Notiek izmeklēšana, iespējams, saņemsit zvanus no lietotājiem savā organizācijā ar sūdzībām par to, ka klientu pastkastēm, kas izmanto Exchange Online, ir slikta veiktspēja. Šādā gadījumā ir saprātīgi pieņemt, ka jūsu Exchange Online veiktspēja pasliktinājās pakalpojuma problēmu dēļ.

Office 365 darbspējas informācijas panelis, kurā visa darba slodze tiek rādīta zaļā krāsā, izņemot Exchange, kurā tiek rādīts paziņojums par atjaunotu pakalpojuma darbību.

Šajā brīdī jums kā Office 365 administratoram jāpārbauda pašreizējā darbspēja un pēc tam regulāri jāskata detalizēta informācija un vēsture, lai izsekotu uzturēšanas darbiem, ko veicam sistēmā. Pašreizējās darbspējas informācijas panelis ir izveidots, lai informētu jūs par izmaiņām un problēmām pakalpojumā. Piezīmes un paskaidrojumi, ko administratori rakstījuši darbspējas vēsturē, ir paredzēti, lai jūs varētu novērtēt savu ietekmi un informēt par norisē esošo darbu.

Office 365 darbspējas informācijas paneļa attēls ar skaidrojumu par Exchange Online pakalpojuma atjaunināšanu un šīs darbības iemeslu.

Veiktspējas problēma nav pakalpojuma incidents, lai gan incidenti var izraisīt lēnu veiktspēju. Veiktspējas problēma izskatās šādi:

  • Veiktspējas problēma rodas neatkarīgi no tā, kādu informāciju uzrāda Office 365 administrēšanas centra pašreizējās darbspējas sadaļa.

  • Darbība, kas ir relatīvi vienkārša, aizņem ilgu laiku, lai to pabeigtu, vai arī tā netiek pabeigta.

  • Varat arī dublēt problēmu vai, vismaz jūs zināt, ka problēma radīsies, ja veiksit attiecīgās darbības.

  • Ja problēma ir neregulāra, joprojām ir risinājums, piemēram, jūs zināt, ka 10:00 saņemsit zvanus no lietotājiem, kuri nevar droši piekļūt pakalpojumam Office 365, un ka zvani tiks pārtraukti ap pusdienlaiku.

Iespējams, tas izklausās pazīstami, varbūt pat pārāk pazīstami. Kad zināt, ka tā ir veiktspējas problēma, jautājums ir: Ko darīt tālāk? Atlikusī šī raksta daļa palīdz jums iegūt atbildi uz šo jautājumu.

Kā noteikt un testēt veiktspējas problēmu

Laika gaitā bieži rodas veiktspējas problēmas, tāpēc var būt sarežģīti precīzi noteikt problēmu. Lai gūtu labu rezultātu, ir jāizveido labs problēmas priekšraksts un labi jāizprot problēmas konteksts, bet pēc tam jāizveido atkārtojamas pārbaudes darbības. Pretējā gadījumā ne savas vainas dēļ varat apjukt, kā rīkoties. Kāpēc? Tālāk piedāvājam dažus tādu problēmu priekšrakstu piemērus, kuros nav pietiekami daudz informācijas:

  • Pāriešana no iesūtnes uz kalendāru iepriekš bija nemanāma, taču tagad tas ilgst veselu kafijas pauzi. Vai iespējams atjaunot iepriekšējo darbību?

  • Failu augšupielāde pakalpojumā SharePoint Online notiek ļoti ilgi. Kāpēc pēcpusdienā tas notiek lēni, taču pārējā laikā tas ir ātri? Vai tas vienmēr nevar notikt ātri?

Iepriekš minētie problēmu priekšraksti uzrāda vairākas lielas problēmas. Precīzāk, ir daudz neskaidrību, piemēram:

  • Nav zināms, kā pāriešana no iesūtnes uz kalendāru notika klēpjdatorā.

  • Kad lietotājs saka "Vai tas vienmēr nevar notikt ātri?", ko nozīmē "ātri"?

  • Cik ilgi ir "ļoti ilgi"? Vai tās ir dažas sekundes vai minūtes, vai arī lietotājs var doties pusdienās, un process tiek pabeigts desmit minūtes pēc lietotāja atgriešanās?

Visa šī informācija ir sniegta, neņemot vērā, ka administrators un problēmu risinātājs nevar iegūt daudz informācijas no šādiem problēmu priekšrakstiem. Piemēram, kad problēma parādījās; ka lietotājs strādā no mājām un lēna pārslēgšana notiek tikai mājas tīklā; ka lietotājam jāpalaiž vairākas citas lietojumprogrammas ar intensīvu RAM noslodzi lokālajā klienta datorā vai lietotājs izmanto vecāku operētājsistēmu vai nav veicis pēdējo atjaunināšanu.

Kad lietotāji ziņo par veiktspējas problēmu, iespējams apkopot lielu daudzumu informācijas. Šīs informācijas apkopošana ir daļa no procesa, kas tiek dēvēts par problēmas noteikšanu vai izmeklēšanu. Tālāk sniegts pamata noteikšanas saraksts, ko varat izmantot, lai apkopotu informāciju par savu veiktspējas problēmu. Šis saraksts nav visaptverošs, taču tas ir noderīgs kā sākuma punkts:

  • Kurā datumā radās problēma un kādā diennakts laikā?

  • Kādu klienta datoru izmantojāt, un kāds bija tā savienojums ar uzņēmuma tīklu (VPN, vadu, bezvadu)?

  • Vai strādājat attāli vai no biroja?

  • Vai mēģinājāt veikt tās pašas darbības citā datorā un notika tas pats?

  • Veiciet darbības, kas izraisa problēmu, lai jūs varētu tās pierakstīt.

  • Cik lēna sekundēs vai minūtēs ir veiktspēja?

  • Kāda ir jūsu atrašanās vieta?

Daži no šiem jautājumiem ir saprotamāki nekā citi. Gandrīz katram ir skaidrs, ka problēmas risinātājam nepieciešams zināt precīzas darbības, lai atveidotu problēmu. Kā gan citādi jūs reģistrēsit, kas darbojas nepareizi, un kā pārbaudīsit, vai problēma ir novērsta? Mazāk uzkrītoši ir tas, ka tādu informāciju kā "Kurā datumā un laikā radās problēma?" un "Kāda ir jūsu atrašanās vieta?" iespējams izmantot kopā. Atkarībā no lietotāja darba laika dažas stundas laika starpības var nozīmēt, ka jūsu uzņēmuma tīklā jau tiek veikti uzturēšanas darbi. Ja, piemēram, jūsu uzņēmumā ir hibrīdā ieviešana, teiksim, SharePoint meklēšana, kas var izveidot vaicājumus pakalpojuma SharePoint Online un lokālas SharePoint Server 2013 instances meklēšanas indeksos, iespējams, lokālajā fermā notiek atjaunināšana. Ja jūsu uzņēmums ir pilnībā izvietots mākonī, sistēmas uzturēšana var ietvert tīkla aparatūras pievienošanu vai noņemšanu, atjauninājumu izplatīšanu uzņēmuma līmenī vai izmaiņu veikšanu DNS vai citā pamata infrastruktūrā.

Kad mēģināt novērst veiktspējas problēmu, tas ir mazliet līdzīgi nozieguma vietai, jums jārīkojas precīzi un jābūt vērīgam, lai izdarītu secinājumus no pierādījumiem. Lai to izdarītu, jāizveido labs problēmas priekšraksts, apkopojot pierādījumus. Tajā jāiekļauj datora konteksts, lietotāja konteksts, problēmas rašanās laiks un precīzas darbības, kas atklāja veiktspējas problēmu. Šim problēmas priekšrakstam jābūt jūsu piezīmju galvenajai lapai. Pēc risinājuma atrašanas vēlreiz pārskatot problēmas priekšrakstu, jūs veicat darbības, lai pārbaudītu un pārliecinātos, vai jūsu veiktās darbības novērsa problēmu. Tas ir svarīgi, lai jūs zinātu, vai esat novērsis problēmu.

Vai zināt, kāda bija veiktspēja, kad ar to viss bija kārtībā?

Ja jums neveicas, neviens nezina. Neviens nezināja skaitļus. Tas nozīmē, ka neviens nevarēja atbildēt uz vienkāršu jautājumu "Aptuveni cik daudz sekunžu pagāja, lai atvērtu iesūtni pakalpojumā Office 365?" vai "Cik ilgs laiks bija nepieciešams, lai uzņēmuma vadība sarīkotu Lync Online sapulci?", kas ir bieži sastopamas situācijas daudzos uzņēmumos.

Šeit pietrūkst veiktspējas bāzes datu.

Bāzes dati sniedz jums veiktspējas kontekstu. Jums ar noteiktu regularitāti jāreģistrē bāzes dati atkarībā no uzņēmuma vajadzībām. Ja jums ir lielāks uzņēmums, jūsu darba grupa var reģistrēt bāzes datus jūsu vietā lokālajā vidē. Piemēram, ja veicat ielāpus visiem Exchange serveriem mēneša pirmajā pirmdienā un visiem SharePoint serveriem mēneša trešajā pirmdienā, jūsu darba grupai visdrīzāk ir uzdevumu un scenāriju saraksts, kas jāveic pēc ielāpu veikšanas, lai pārbaudītu, vai darbojas kritiski svarīgas funkcijas. Piemēram, atvērt iesūtni, noklikšķināt uz Nosūtīšana/saņemšana un pārliecināties, vai mapes tiek atjauninātas, vai platformā SharePoint pārlūkojiet līdz vietnes galvenajai lapai, pārejiet uz uzņēmuma meklēšanas lapu un veiciet meklēšanu, kas atgriež rezultātus.

Ja jūsu lietojumprogrammas atrodas pakalpojumā Office 365, varat fiksēt pamata bāzes datus, piemēram, fiksēt laiku (milisekundēs) no klienta datora tīklā līdz izejas punktam vai punktam, kad pametat savu tīklu un pārejat uz Office 365. Šeit ir daži noderīgi bāzes dati, ko varat izpētīt un reģistrēt:

  • Identificējiet ierīces starp klienta datoru un izejas punktu, piemēram, starpniekserveri.

    • Jums ir jāiegūst informācija par savām ierīcēm (IP adreses, ierīces tips un cita informācija), lai nodrošinātu iespējamo veiktspējas problēmu kontekstu.

    • Starpniekserveri ir bieži izmantoti izejas punkti, un jūs varat izmantot tīmekļa pārlūkprogrammu, lai uzzinātu, vai kāds starpniekserveris ir iestatīts lietošanai.

    • Ir pieejami trešo pušu rīki, kas var atklāt un kartēt jūsu tīklu, taču drošākais veids, kā iegūt informāciju par ierīcēm, ir lūgt palīdzību kādam tīkla darba grupas dalībniekam.

  • Identificējiet savu interneta pakalpojumu sniedzēju (ISP), pierakstiet kontaktinformāciju un noskaidrojiet, cik daudz jums ir shēmu un kāds ir joslas platums.

  • Savā uzņēmumā identificējiet ierīču resursus starp klientu un izejas punktu vai identificējiet ārkārtas kontaktpersonu, ar ko sazināties tīkla darbības problēmu gadījumā.

Šeit sniegti daži bāzes dati, ko varat aprēķināt, veicot vienkāršu pārbaudi, izmantojot rīkus:

  • Laiks no klienta datora līdz izejas punktam milisekundēs

  • Laiks no izejas punkta līdz Office 365 milisekundēs

  • Tā servera atrašanās vieta, kurš atrisina vietrāžus URL pakalpojumam Office 365 pārlūkošanas laikā

  • Interneta pakalpojumu sniedzēja DNS atpazīšanas ātrums milisekundēs, nekonsekvences pakešu piegādē, augšupielādes un lejupielādes laiks milisekundēs

Ja nezināt, kā veikt šīs darbības, detalizētu informāciju iegūsit šajā rakstā.

Kas ir bāzes dati?

Jūs izjutīsit ietekmi, kad veiktspēja pasliktināsies, taču, ja nezināsit vēsturiskās veiktspējas datus, nebūs pieejams konteksts, lai saprastu, cik zema un kādā brīdī ir bijusi veiktspēja. Tātad bez bāzes datiem jums nav atslēgas puzles salikšanai: attēla uz puzles kārbiņas. Novēršot veiktspējas problēmas, jums nepieciešams salīdzinājuma punkts. Vienkāršus veiktspējas bāzes datus ir viegli iegūt. Varat uzdot savai darba grupai veikt šo uzdevumu pēc noteikta grafika. Piemēram, jūsu savienojums izskatās šādi:

Pamattīkla grafika, kurā ir attēlots klients, starpniekserveris un Office 365 mākonis.

Tas nozīmē, ka esat sazinājies ar savu tīkla grupu un uzzinājis, ka, piekļūstot internetam, pametat uzņēmuma tīklu caur starpniekserveri un ka starpniekserveris apstrādā visus pieprasījumus, ko klient dators nosūta uz mākoni. Šādā gadījumā uzzīmējiet vienkāršu sava savienojuma versiju, kurā norādītas visas saistītās ierīces. Pēc tam ievietojiet rīkus, ko varat izmantot veiktspējas pārbaudei starp klientu, izejas punktu (kurā pametat savu tīklu, lai piekļūtu internetam) Office 365 mākoni.

Pamattīkls ar klientu, starpniekserveri, mākoni un rīku ierosinājumiem PSPing, TraceTCP, kā arī tīkla izsekošanas gadījumiem.

Opcijas ir norādītas kā vienkāršas un detalizētas atkarībā no zināšanām, kas nepieciešamas veiktspējas datu atrašanai. Tīkla izsekošana būs ilga salīdzinājumā ar komandrindas rīku, piemēram, PsPing un TraceTCP, palaišanu. Šie divi komandrindas rīki ir izvēlēti, jo neizmanto ICMP paketes, ko bloķē Office 365, un norāda laiku milisekundēs, kas nepieciešams, lai pamestu klienta datoru vai starpniekserveri (ja jums ir piekļuve) un nokļūtu pakalpojumā Office 365. Katra pāreja no viena datora uz citu beidzas ar laika vērtību, un tas ir noderīgi bāzes datiem! Tikpat svarīgi zināt, ka šie komandrindas rīki ļauj jums pievienot porta numuru komandā. Tas ir noderīgi, jo Office 365 nodrošina saziņu, izmantojot portu 443, un šo portu izmanto drošligzdu slānis un transporta slāņa drošība (SSL un TLS). Taču citi trešās puses rīki var būt labāks risinājums jūsu situācijai. Microsoft neatbalsta visus šos rīkus, tāpēc, ja kāda iemesla dēļ nevarat palaist PsPing un TraceTCP, pārejiet uz tīkla izsekošanu, izmantojot tādu rīku kā Netmon.

Varat iegūt bāzes datus pirms darba laika, pēc tam lielas noslodzes laikā un vēlāk atkal pēc darba laika. Tas nozīmē, ka jums ir mapju struktūra, kas beigās izskatās mazliet līdzīga šādai struktūrai:

Grafika ar priekšlikumu par to, kā kārtot veiktspējas datus mapēs.

Jums jāizvēlas arī failu nosaukšanas princips. Daži piemēri:

  • 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

Pastāv daudz dažādu veidu, kā to izdarīt, taču formāta <dateTime><what's happening in the test> izmantošana ir labs sākums. Rūpīga attieksme šajā ziņā ir ļoti noderīga, vēlāk mēģinot novērst problēmas. Vēlāk varēsit teikt: "Es veicu divas izsekošanas 8. februārī, viena uzrādīja labu veiktspēju, bet otra uzrādīja sliktu, tāpēc varam tās salīdzināt." Tas ir ļoti noderīgi problēmu novēršanā.

Jums jābūt pārdomātam veidam, kā glabājat savus vēsturiskos bāzes datus. Šajā piemērā ar vienkāršām metodēm tika iegūtas trīs komandrindas izvades un rezultāti tika apkopoti kā ekrānuzņēmumi, taču jums tā vietā var būt tīkla tvēruma faili. Izmantojiet sev piemērotāko veidu. Glabājiet savus vēsturiskos bāzes datus un skatiet tos brīžos, kad ievērojat izmaiņas tiešsaistes pakalpojumu darbībā.

Kāpēc apkopot veiktspējas datus pilotversijas izmantošanas laikā

Office 365 pakalpojuma pilotversijas izmantošanas laiks ir vispiemērotākais brīdis, kad sākt veidot bāzes datus. Jūsu birojā var būt tūkstošiem lietotāju, simtiem tūkstoši lietotāju vai tikai pieci, taču arī pie maza lietotāju skaita varat veikt pārbaudes, lai izmērītu veiktspējas svārstības. Liela uzņēmuma gadījumā reprezentatīvu paraugu, kurā vairāki simti lietotāju izmēģina Office 365, var izvērst līdz vairākiem tūkstošiem, lai jūs varētu uzzināt potenciālos problēmu cēloņus pirms pašu problēmu rašanās.

Ja uzņēmums ir mazs un pievienošanās laikā visi lietotāji vienlaikus piekļūst pakalpojumam, turklāt netiek izmantota pilotversija, saglabājiet veiktspējas mērījumus, lai jums būtu dati, ko parādīt speciālistam, kuram var nākties novērst sliktas veiktspējas darbību. Piemēram, ja ievērojat, ka pēkšņi varat brīvi doties pastaigā, kamēr tiek augšupielādēta vidēji liela grafika, lai gan iepriekš tas notika ļoti ātri.

Kā iegūt bāzes datus

Visu problēmu novēršanas plānu gadījumā jums jāspēj identificēt vismaz šāda informācija:

  • Klienta dators, kuru lietojat (datora vai ierīces tips, IP adrese un darbības, kuru rezultātā radusies problēma)

  • Klienta datora atrašanās vieta pasaulē (piemēram, vai lietotājs izmanto VPN tīklā, strādā attāli vai uzņēmuma iekštīklā)

  • Klienta datora izmantotais izejas punkts jūsu tīklā (punkts, kurā trafiks iziet no jūsu uzņēmuma un nokļūst ISP vai internetā)

Sava tīkla izkārtojumu varat uzzināt no tīkla administratora. Ja esat mazā tīklā, aplūkojiet ierīces, kas nodrošina jūsu savienojumu ar internetu, un sazinieties ar interneta pakalpojumu sniedzēju, ja jums ir jautājumi par izkārtojumu. Turpmākai atsaucei izveidojiet gala izkārtojuma attēlu.

Šī sadaļa ir iedalīta pārskatā par vienkāršiem komandrindas rīkiem un metodēm un detalizētākām rīku iespējām. Vispirms aplūkosim vienkāršās metodes. Taču, ja jums šobrīd ir veiktspējas problēma, pārejiet uz detalizētākām metodēm un izmēģiniet veiktspējas problēmu novēršanas darbību plāna paraugu.

Vienkāršas metodes

Šo vienkāršo metožu mērķis ir apgūt, kā iegūt, izprast un pareizi glabāt vienkāršus veiktspējas bāzes datus laika gaitā, lai jums būtu informācija par Office 365 veiktspēju. Paraugam šeit sniegta ļoti vienkārša shēma, kādu esat redzējis iepriekš:

Pamattīkls ar klientu, starpniekserveri, mākoni un rīku ierosinājumiem PSPing, TraceTCP, kā arī tīkla izsekošanas gadījumiem.

Piezīmes.: 

  • TraceTCP ir iekļauts šajā ekrānuzņēmumā, jo tas ir noderīgs rīks, kas milisekundēs uzrāda, cik ilgi notiek pieprasījuma apstrāde un cik daudz lēkumu vai savstarpēju datoru savienojumu nepieciešams, lai pieprasījums sasniegtu mērķi. TraceTCP var uzrādīt arī to serveru nosaukumus, kas tiek izmantoti lēkumu laikā, un šī informācija var būt noderīga Microsoft Office 365 problēmu risinātājam.

  • TraceTCP komandas var būt ļoti vienkāršas, piemēram:

  • tracetcp.exe outlook.office365.com:443

  • Neaizmirstiet komandā iekļaut porta numuru!

  • TraceTCP ir bezmaksas lejupielāde, taču tā izmanto Wincap. Wincap ir rīks, ko arī izmanto un instalē Netmon. Mēs izmantojam Netmon arī detalizēto metožu sadaļā.

Ja jums ir vairāki biroji, saglabājiet datu kopu no klienta arī katrā no šīm atrašanās vietām. Šī pārbaude nosaka latentumu, kas šajā gadījumā ir skaitliska vērtība, kas norāda aizvadīto laiku starp brīdi, kad klients nosūta pieprasījumu uz pakalpojumu Office 365, un brīdi, kad Office 365 reaģē uz pieprasījumu. Pārbaude tiek sākta jūsu domēnā esošajā klienta datorā un mēra cikla laiku no jūsu tīkla līdz izejas punktam, cauri internetam līdz Office 365 un atpakaļ.

Pastāv vairāki veidi, kā apstrādāt informāciju par izejas punktu, kas šajā gadījumā ir starpniekserveris. Varat izsekot no 1 līdz 2 un pēc tam no 2 līdz 3, un pēc tam pievienot vērtības milisekundēs, lai iegūtu beigu kopsummu līdz sava tīkla robežām. Vai arī varat konfigurēt savienojumu, lai apietu starpniekserveri Office 365 adresēm. Lielākā tīklā ar ugunsmūri, apgriezto starpniekserveri vai abu apvienojumu, varat veikt izņēmumus starpniekserverī, lai atļautu trafikam šķērsot daudzus vietrāžus URL. Office 365 izmantotos galapunktus skatiet sadaļā Office 365 vietrāžu URL un IP adrešu diapazoni. Ja jums ir autentificēšanas starpniekserveris, sāciet ar šo izņēmumu pārbaudi:

  • Porti 80 un 443

  • TCP un HTTP

  • Savienojumi, kas iziet uz kādu no šiem vietrāžiem URL:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Visiem lietotājiem jāsniedz atļaujas piekļūt šīm adresēm bez starpniekserveru iejaukšanās vai autentifikācijas. Mazākā tīklā pievienojiet šīs adreses starpniekservera apiešanas sarakstam savā tīmekļa pārlūkprogrammā.

Lai pievienotu šīs adreses starpniekservera apiešanas sarakstam pārlūkprogrammā Internet Explorer, atveriet Rīki > Interneta opcijas > Savienojumi > LAN iestatījumi > Papildu. Cilnē Papildu norādīts arī jūsu starpniekserveris un starpniekservera ports. Iespējams, būs jāatzīmē izvēles rūtiņa Lokālajam tīklam izmantot starpniekserveri, lai piekļūtu pogai Papildu . Pārliecinieties, vai ir atzīmēta rūtiņa Lokālajām adresēm apiet starpniekserveri. Noklikšķinot uz Papildu, parādīsies tekstlodziņš, kur ievadīt izņēmumus. Nodaliet iepriekš norādītos aizstājējzīmju vietrāžus URL ar semikoliem, piemēram:

*.microsoftonline.com; *.sharepoint.com

Kad starpniekserveris tiek apiets, varat izmantot programmu Ping vai PsPing tieši Office 365 vietrādī URL. Nākamā darbība būs ehotestēt outlook.office365.com. Vai, ja izmantojat PsPing vai citu rīku, kas sniedz iespēju komandai nodrošināt porta numuru, veiciet PsPing ehotestēšanu vietrādim URL portal.microsoftonline.com:443, lai uzzinātu vidējo cikla laiku milisekundēs.

Cikla laiks vai RTT ir skaitliska vērtība, kas mēra, cik ilgs laiks nepieciešams, lai nosūtītu HTTP pieprasījumu uz serveri, piemēram, outlook.office365.com, un saņemtu atbildi, kas apstiprina, ka serveris zina, ka to esat izdarījis jūs. Dažreiz redzēsit šīs vērtības saīsinājumu RTT. Tam jābūt relatīvi neilgam laika brīdim.

Lai veiktu šo pārbaudi, ir jāizmanto PsPing vai cits rīks, kas neizmanto ICMP paketes, kuras bloķē pakalpojums Office 365.

PsPing izmantošana, lai iegūtu kopējo cikla laiku milisekundēs tieši no Office 365 vietrāža URL

  1. Izpildiet priviliģētu komandu uzvedni, veicot šīs darbības:

    1. Noklikšķiniet uz Sākt.

    2. Sākuma meklēšanas lodziņā ierakstiet cmd un pēc tam nospiediet taustiņu kombināciju CTRL+SHIFT+ENTER.

    3. Ja parādās dialoglodziņš Lietotāja konta kontrole, apstipriniet, ka tā parādītā darbība ir jūsu vēlamā darbība, un pēc tam noklikšķiniet uz Turpināt.

  2. Atveriet mapi, kur ir instalēts rīks (šajā gadījumā PsPing) un testējiet šos Office 365 vietrāžus URL:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      Komanda PSPing, kas nosūta uz microsoft-my.sharepoint.com portu 443.

Noteikti iekļaujiet porta numuru 443. Atcerieties, ka Office 365 darbojas šifrētā kanālā. Ja veicat PsPing ehotestēšanu bez porta numura, jūsu pieprasījums neizdosies. Kad esat veicis īsā saraksta ehotestēšanu, meklējiet vidējo laiku milisekundēs (ms). Jums jāreģistrē šī vērtība!

Grafika, kurā tiek rādīts attēls ar ehotestēšanu no klienta uz starpniekserveri PSPing, un cikla laiks ir 2,8 milisekundes.

Ja nepārzināt starpniekservera apiešanu un vēlaties veikt procesu pakāpeniski, vispirms uzziniet sava starpniekservera nosaukumu. Pārlūkprogrammā Internet Explorer, atveriet Rīki > Interneta opcijas > Savienojumi > LAN iestatījumi > Papildu. Cilnē Papildu būs norādīts jūsu starpniekserveris. Ehotestējiet šo starpniekserveri komandu uzvednē, izpildot šo uzdevumu:

Starpniekservera ehotestēšana un cikla laika vērtības iegūšana milisekundēs no 1. līdz 2. posmam

  1. Izpildiet priviliģētu komandu uzvedni, veicot šīs darbības:

    1. Noklikšķiniet uz Sākt.

    2. Sākuma meklēšanas lodziņā ierakstiet cmd un pēc tam nospiediet taustiņu kombināciju CTRL+SHIFT+ENTER.

    3. Ja parādās dialoglodziņš Lietotāja konta kontrole, apstipriniet, ka tā parādītā darbība ir jūsu vēlamā darbība, un pēc tam noklikšķiniet uz Turpināt.

  2. Ierakstiet ping <jūsu pārlūkprogrammas izmantotā starpniekservera nosaukums vai starpniekservera IP adrese> un pēc tam nospiediet taustiņu ENTER. Ja jums ir instalēts PsPing vai cits rīks, varat izvēlēties izmantot šo rīku.

    Jūsu komanda var izskatīties kā viens no šiem piemēriem:

    • 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. Kad izsekošana pārtrauc sūtīt testa paketes, jūs saņemat nelielu kopsavilkumu, kurā norādīts vidējais laiks milisekundēs, un tieši šī ir nepieciešamā vērtība. Uzņemiet uzvednes ekrānuzņēmumu un saglabājiet, izmantojot savu nosaukumdošanas metodi. Šajā brīdī var būt noderīgi aizpildīt shēmu ar vērtību.

Varbūt esat veicis izsekošanu agri no rīta, un jūsu klients var ātri piekļūt starpniekserverim (var citam izejas serverim uz internetu). Šādā gadījumā skaitļu vērtības var būt šādas:

Grafika, kurā attēlots 2,8 milisekunžu cikla laiks no klienta uz starpniekserveri.

Ja jūsu klienta dators ir viens no dažiem ar piekļuvi starpniekserverim (vai izejas serverim), varat veikt nākamo pārbaudes posmu, izveidojot attālu savienojumu ar šo datoru, izpildot komandu uzvedni, lai ehotestētu PsPing līdz Office 365 vietrādim URL no šī datora. Ja jums nav piekļuves šim datoram, varat sazināties ar saviem tīkla resursiem, lai saņemtu palīdzību nākamā posma izpildei un iegūtu nepieciešamos skaitļus. Ja tas nav iespējams, veiciet PsPing ehotestēšanu līdz pārbaudāmajam Office 365 vietrādim URL un salīdziniet ar PsPing vai Ping ehotestēšanas laiku līdz jūsu starpniekserverim.

Piemēram, ja nepieciešamas 51,84 milisekundes no klienta līdz Office 365 vietrādim URL, un jums ir 2,8 milisekundes no klienta līdz starpniekserverim (vai izejas punktam), kopā jums nepieciešamas 49,04 milisekundes no izejas punkta līdz Office 365. Līdzīgi, ja PsPing laiks ir 12,25 milisekundes no klienta līdz starpniekserverim dienas vidū, un 62,01 milisekunde no klienta līdz Office 365 vietrādim URL, tad vidējā vērtība starpniekservera izejai līdz Office 365 vietrādim URL ir 49,76 milisekundes.

Papildu grafika, kurā ir attēlots ehotests milisekundēs no klienta uz starpniekserveri, kā arī no klienta uz Office 365, tāpēc vērtības var tikt atņemtas.

Lai novērstu problēmas, ir vērts paturēt šos bāzes datus, jo varat atrast tajos noderīgu informāciju. Piemēram, ja atklājat, ka parasti latentums no starpniekservera vai izejas punkta līdz Office 365 vietrādim URL ir aptuveni 40 līdz 59 milisekundes, un latentums no klienta līdz starpniekserverim vai izejas punktam ir 3 līdz 7 milisekundes (atkarībā no tīkla trafika šajā dienas laikā), tad būs skaidrs, ka radusies problēma, ja pēdējie trīs reģistrētie bāzes dati ar latentumu no klienta līdz starpniekserverim vai izejas punktam uzrāda 45 milisekundes.

Detalizētas metodes

Ja tiešām vēlaties uzzināt, kas notiek ar jūsu interneta pieprasījumiem pakalpojumam Office 365, jums jāiepazīstas ar tīkla izsekošanu. Nav nozīmes, kādus rīkus izvēlaties šīs izsekošanas veikšanai — HTTPWatch, Netmon, ziņojumu analizētāju, Wireshark, Fiddler, izstrādātāja informācijas paneli vai citu, ja vien šis rīks var tvert un filtrēt tīkla trafiku. Šajā sadaļā uzzināsit, ka ir noderīgi darbināt vairākus rīkus, lai iegūtu pilnvērtīgāku priekšstatu par problēmu. Pārbaudes laikā daži rīki darbojas arī kā starpniekserveri. Raksta Veiktspējas problēmu novēršanas plāns pakalpojumam Office 365 piemēros lietotie rīki ir Netmon 3.4, HTTPWatch un WireShark.

Veiktspējas bāzes datu iegūšana ir šīs metodes vieglākā daļa, un daudzas darbības ir līdzīgas, kā novēršot veiktspējas problēmu. Detalizētās veiktspējas bāzes datu izveides metodēs jāveic tīkla izsekošana un jāglabā rezultāti. Lielākajā daļā šajā rakstā minēto piemēru izmantots pakalpojums SharePoint Online, taču jums jāizveido saraksts ir bieži veicamām darbībām jūsu abonētajos un reģistrētajos Office 365 pakalpojumos. Šeit sniegts bāzes datu piemērs:

  • SPO bāzes datu saraksts - 1. darbība. Pārlūkojiet SPO tīmekļa vietnes sākumlapu un veiciet tīkla izsekošanu. Saglabājiet izsekošanas rezultātus.

  • SPO bāzes datu saraksts - 2. darbība. Meklējiet vārdu (piemēram, sava uzņēmuma nosaukumu), izmantojot uzņēmuma meklēšanu, un veiciet tīkla izsekošanu. Saglabājiet izsekošanas rezultātus.

  • SPO bāzes datu saraksts - 3. darbība. Augšupielādējiet lielu failu SharePoint Online dokumentu bibliotēkā un veiciet tīkla izsekošanu. Saglabājiet izsekošanas rezultātus.

  • SPO bāzes datu saraksts - 4. darbība. Pārlūkojiet OneDrive tīmekļa vietnes sākumlapu un veiciet tīkla izsekošanu. Saglabājiet izsekošanas rezultātus.

Šajā sarakstā jāiekļauj svarīgākās bieži veicamās darbības, ko lietotāji veic pakalpojumā SharePoint Online. Ievērojiet, ka pēdējā darbība, izsekošana līdz OneDrive darbam, veido salīdzinājumu starp SharePoint Online sākumlapas (ko uzņēmumi bieži pielāgo) ielādi un OneDrive darbam sākumlapas, kas tiek reti pielāgota, ielādi. Šī ir ļoti vienkārša pārbaude, ja problēmu rada lēna SharePoint Online vietnes ielāde. Savā pārbaudē varat izveidot šīs starpības ierakstu.

Ja mēģināt novērst veiktspējas problēmu, daudzas darbības ir līdzīgas tām, kas jāveic, iegūstot bāzes datus. Tīkla izsekošana kļūst kritiski svarīgi, tāpēc tālāk aplūkosim, veikt svarīgu izsekošanu.

Lai novērstu veiktspējas problēmu tūlīt, jums jāveic izsekošana brīdī, kad rodas veiktspējas problēma. Jums jābūt pieejamiem nepieciešamajiem rīkiem, lai apkopotu žurnālus, un darbību plānam, kas ir problēmu novēršanas darbību saraksts, kas jāveic, lai apkopotu vislabāko iespējamo informāciju. Vispirms reģistrējiet pārbaudes datumu un laiku, lai failus varētu saglabāt mapē pēc secības. Pēc tam sašauriniet līdz problēmas darbībām. Tieši šīs darbības veiksit pārbaudē. Neaizmirstiet būtisko: ja problēma ir tikai programmā Outlook, noteikti reģistrējiet, ka problēma rodas tikai vienā Office 365 pakalpojumā. Sašaurinot problēmas tvērumu, varēsit koncentrēties uz to, ko varat atrisināt.

Skatiet arī

Office 365 galapunktu pārvaldība

Paplašiniet savas Office prasmes
Iepazīties ar apmācību
Esiet pirmais, kas saņem jaunās iespējas
Pievienoties Office Insider programmai

Vai šī informācija bija noderīga?

Paldies par jūsu atsauksmēm!

Paldies par atsauksmēm! Šķiet, ka varētu būt noderīgi sazināties ar kādu no mūsu Office atbalsta aģentiem.

×