Office 365-ytelsesjustering ved hjelp av referanseverdier og ytelseshistorikk

Det finnes noen enkle måter å kontrollere tilkoblingsytelsen mellom Office 365 og bedriften din på, som lar deg etablere en omtrentlig grunnlinje for tilkoblingen din. Det kan være nyttig å kjenne til ytelseshistorikken for klientdatamaskinens tilkoblinger med tanke på å oppdage, identifisere og forutse problemer tidlig.

Hvis du ikke er vant til å jobbe med ytelsesproblemer, er denne artikkelen laget for å hjelpe deg med å vurdere noen vanlige spørsmål, for eksempel hvordan du vet om problemet faktisk er et ytelsesproblem og ikke et generelt tjenesteproblem med Office 365. Hvordan kan du planlegge for god ytelse i det lange løp? Hvordan kan du holde øye med ytelsen? Hvis avdelingen eller klientene opplever dårlig ytelse mens de bruker Office 365, og du har noen av disse spørsmålene, er denne artikkelen noe for deg.

Viktig: Har du et problem med ytelsen mellom klienten og Office 365 akkurat nå? Følg fremgangsmåten i Feilsøkingsplan for ytelse i Office 365.

Noe du bør vite om ytelsen i Office 365

Office 365 er plassert i et dedikert Microsoft-nettverk med høy kapasitet som hele tiden overvåkes, ikke bare av maskiner, men av virkelige mennesker. En del av arbeidet med å vedlikeholde Office 365-skyen er å justere ytelsen og rasjonalisere driftsprosessene der det er mulig. Siden de som bruker Office 365-skyen, må koble seg til via Internett, gjøres det også en kontinuerlig innsats for å finjustere ytelsen til alle Office 365-tjenestene. Ytelsesforbedringene stopper egentlig aldri i skyen, og det er mye akkumulert erfaring som må til for å holde skyen sunn og rask. Hvis du opplever ytelsesproblemer når du kobler deg til Office 365 der du befinner deg, er det best å ikke starte med og vente på en brukerstøttesak. I stedet bør du begynne å undersøke problemet innenfra og ut. Det vil si at du starter med det lokale nettverket og arbeider deg utover til Office 365. Før du åpner en sak hos brukerstøtten for Office 365, kan du samle inn bakgrunnsdata og utføre handlinger som undersøker og kanskje kan løse problemet.

Viktig: Vær oppmerksom på kapasitetsplanlegging og -grenser i Office 365. Denne informasjonen vil hjelpe deg med å komme videre når du prøver å løse ytelsesproblemer. Her er en kobling til tjenestebeskrivelsen av Office 365-plattformen. Dette er et sentralt knutepunkt, og alle tjenestene som tilbys av Office 365 har en kobling til sine egne tjenestebeskrivelser herfra. Dette betyr at hvis du for eksempel trenger å se standardbegrensningene for SharePoint Online, kan du klikke på Tjenestebeskrivelse for SharePoint Online og finne inndelingen Begrensninger for SharePoint Online.

Du må være klar over at ytelsen er en glidende skala når du begynner feilsøkingen. Det dreier seg ikke om å oppnå en idealverdi og vedlikeholde den permanent. (Hvis du er av denne oppfatningen, vil det være svært stressende når det kjøres oppgaver som krever stor båndbredde, for eksempel fordi mange brukere legges til samtidig eller store mengder data blir overført. Du bør planlegge for redusert ytelse i slike tilfeller.) Du kan, og bør, ha en omtrentlig forestilling om ytelsesmålene, men mange variabler påvirker ytelsen slik at den varierer. Det er slik ytelse fungerer.

Feilsøking av ytelsen har ikke som mål å oppnå bestemte mål og opprettholde disse tallene permanent, det dreier seg heller om å forbedre eksisterende aktiviteter med tanke på alle variablene.

Så hvordan arter et ytelsesproblem seg?

Først må du sørge for at det du opplever, faktisk er et ytelsesproblem og ikke en tjenestehendelse. Et ytelsesproblem er noe annet enn en tjenestehendelse i Office 365. Slik skiller du dem fra hverandre:

Hvis det forekommer problemer med Office 365-tjenesten, er det en tjenestehendelse. Da vil du se røde eller gule ikoner under Gjeldende tilstand i administrasjonssenteret for Office 365, og du kan også legge merke til lav ytelse på klientdatamaskiner som er koblet til Office 365. Hvis gjeldende tilstand for eksempel viser et rødt ikon og det vises Undersøker ved siden av Exchange, kan du også oppleve at flere i organisasjonen ringer og klager over at klientpostbokser som bruker Exchange Online, fungerer dårlig. I slike tilfeller er det rimelig å anta at ytelsen til Exchange Online skyldes problemer med tjenesten.

Office 365-tilstandsinstrumentbord med alle arbeidsbelastninger i grønt, bortsett fra Exchange, som viser Tjeneste gjenopprettet.

Da bør du som Office 365-administrator kontrollere gjeldende tilstand og deretter vis detaljer og historikk ofte for å holde deg oppdatert om det vedlikeholdet vi utfører på systemet. Gjeldende tilstand er programmert til å oppdatere deg om endringer i og problemer med tjenesten. Notatene og forklaringene som er skrevet om helseloggen, fra administrator til administrator, er der for å hjelpe deg å måle hvordan du påvirkes, og holde deg oppdatert om pågående arbeid.

Et bilde av Office 365-tilstandsinstrumentbordet som forklarer at Exchange Online-tjenesten er gjenopprettet, og hvorfor.

Et ytelsesproblem er ikke en tjenestehendelse, selv om hendelser kan føre til lav ytelse. Et ytelsesproblem arter seg gjerne slik:

  • Et ytelsesproblem oppstår uansett hva Gjeldende tilstand i administrasjonssenteret for Office 365 rapporterer om tjenesten.

  • En handling som har pleid å gå greit unna, bruker lang tid til å bli ferdig, eller blir aldri ferdig.

  • Du kan også gjenskape problemet, eller i det minste vite at problemet vil vise seg hvis du gjennomfører de riktige trinnene.

  • Hvis problemet kommer og går, er det likevel et mønster. Du vet for eksempel at du kl. 10 blir kontaktet av brukere som ikke har noen pålitelig tilgang til Office 365, og at henvendelsene tar slutt rundt klokka 12.

Dette lyder kanskje kjent, kanskje altfor kjent. Når du vet at det er et ytelsesproblem, blir spørsmålet: Hva skal du gjøre nå? Resten av denne artikkelen hjelper deg med å finne ut det.

Slik definerer og tester du et ytelsesproblem

Ytelsesproblemer oppstår gjerne over tid. Det kan derfor være en utfordring å fastslå det faktiske problemet. Du må utarbeide en god problemrapport, få en god oppfatning av omstendighetene rundt problemet, og deretter sette opp en god testprosedyre for å komme i mål. Ellers kan det hende du mislykkes, uten at du kan klandres for det. Hvorfor? Her er noen eksempler på problemrapporter som ikke gir nok informasjon:

  • Tidligere gikk det på et blunk å bytte fra innboksen til kalenderen, men nå kan jeg like godt ta meg en kaffepause. Kan du få den til å fungere slik den pleide å gjøre?

  • Opplastingen av filene til SharePoint Online tar en uendelighet. Hvorfor går det så langsomt om ettermiddagen, mens det ikke tar noe tid på andre tidspunkter av dagen? Kan det ikke bare være fort gjort?

Det er flere problemer forbundet med ovenstående problemrapporter. Og særlig er de svært tvetydige. Eksempel:

  • Det går ikke klart frem hvordan det har pleid å fungere å bytte mellom innboksen og kalenderen på den bærbare datamaskinen.

  • Hva mener brukeren med «fort gjort» når han sier: Kan det ikke bare være fort gjort?

  • Hvor lenge innebærer «en uendelighet»? Snakker vi om flere sekunder eller minutter, eller kan brukeren gå til lunsj, mens oppgaven blir ferdig først ti minutter etter at brukeren har kommet tilbake?

Og da har vi ikke tatt hensyn til at det er mange detaljer som administratoren og den som foretar feilsøkingen, ikke kan kjenne til ut fra slike problemrapporter. For eksempel i forbindelse med at problemet først oppstod: at brukeren arbeider hjemmefra og bare opplever problemene med å bytte mellom innboksen og kalenderen når vedkommende arbeider på et hjemmenettverk. At brukeren kjører flere andre minneintensive programmer på den lokal klienten, eller at brukeren kjører et eldre operativsystem eller ikke har installert oppdateringer nylig.

Når brukere rapporterer om et ytelsesproblem, er det masse informasjon som må samles inn. Innsamlingen av denne informasjonen er en del av en prosess som kalles å identifisere omfanget av problemet, eller å undersøke det. Det følgende er en enkel liste over omfanget, som du kan bruke til å samle inn informasjon om det aktuelle ytelsesproblemet. Dette er ikke en fullstendig liste, men det er et sted hvor du kan starte din egen liste:

  • På hvilken dato oppstod problemet, og omtrent når på dagen eller kvelden?

  • Hva slags klientdatamaskin brukte du, og hvordan kobles den til bedriftens nettverk (VPN, kablet, trådløst)?

  • Jobbet du eksternt eller var du på kontoret?

  • Har du prøvd å gjøre det samme på en annen datamaskin, med samme resultat?

  • Gå gjennom trinnene som fører til problemet, slik at du kan notere det du gjør skritt for skritt.

  • Hvor langsom er ytelsen målt i sekunder eller minutter?

  • Hvor i verden befinner du deg?

Noen av disse spørsmålene er mer opplagte enn andre. Nesten alle vil forstå at en som søker etter feil, trenger nøyaktige trinn for å gjenskape problemet. Hvordan kan du ellers registrere hva som er feil, og hvordan kan du ellers teste om problemet er løst? Mindre opplagt er ting som hva datoen og klokkeslettet var da problemet oppstod, og hvor i verden du befinner deg. Dette er informasjon som kan brukes sammen. Avhengig av når brukeren arbeidet, kan et par timers forskjell bety at vedlikehold allerede er i gang på deler av bedriftens nettverk. Hvis organisasjonen for eksempel har en sammensatt installasjon, for eksempel en hybrid SharePoint Search, som kan gjennomføre spørringer av søkeindekser i både SharePoint Online og en lokal SharePoint Server 2013, kan det være at oppdateringer er i gang på den lokale farmen. Hvis organisasjonen er fullstendig i skyen, kan vedlikeholdet av systemet omfatte at det blir lagt til eller fjernet nettverksmaskinvare, at oppdateringer for hele organisasjonen rulles ut, eller at det gjøre endringer i DNS eller en annen kjerneinfrastruktur.

Når du feilsøker et ytelsesproblem, ligner det litt på befaringen av et åsted for en forbrytelse: Du må være nøyaktig og observant for å kunne trekke riktige konklusjoner fra bevismaterialet. Men for å gjøre dette må du skaffe deg en god problemrapport ved å samle inn bevismateriale. Den bør ha med datamaskinens kontekst, brukerens kontekst, når problemet først oppstod og de nøyaktige trinnene som viste at det var problemer med ytelsen. Denne problemrapporten bør befinne seg på den øverste siden i notatene dine. Når du går gjennom problemrapporten igjen etter at du har arbeidet på løsningen, gjennomfører du trinnene for å teste og vise om det du har gjort, har løst problemet. Dette er avgjørende for å avgjøre når arbeidet ditt der er ferdig.

Vet du hvordan ytelsen var da den var god?

Hvis du er uheldig, er det ingen som vet det. Ingen har tall de kan legge frem. Det betyr at ingen kan svare på følgende enkle spørsmål: Omtrent hvor mange sekunder pleide det å ta for å åpne en innboks i Office 365? Eller: Hvor lang tid pleide det å ta når ledelsen hadde et nettmøte med Lync? – en vanlig situasjon i mange selskaper.

Det som mangler her, er en ytelsesreferanse.

Referanseverdiene gir deg en kontekst for ytelsen. Du bør opprette en referanseverdi fra nå og da til ofte, avhengig av organisasjonens behov. Hvis dere er en større organisasjon, kan det være at driftsavdelingen allerede måler referanseverdier i det lokale miljøet. Hvis dere for eksempel oppdaterer alle Exchange-serverne den første mandagen i måneden og alle SharePoint-serverne den tredje mandagen, har antakelig driftsgruppen en liste over oppgaver og situasjoner som gruppen kjører etter oppdateringen for å kontrollere at kritiske funksjoner er i drift. Det kan for eksempel være å åpne innboksen, klikke Send/Motta og kontrollere at mappene oppdateres. I SharePoint kan det være å bla gjennom hovedsiden på nettstedet, gå inn på Enterprise-søkesiden og gjennomføre et søk som returnerer resultater.

Hvis programmene er i Office 365, kan noen av de mest fundamentale referanseverdiene du registrerer, måle tiden det tar (i millisekunder) fra en klientdatamaskin i nettverket til et utgangspunkt, eller punktet der du forlater nettverket og går ut til Office 365. Her er noen nyttige referanseverdier du kan undersøke og registrere:

  • Identifiser enhetene mellom klientdatamaskinen, og utgangspunktet, for eksempel proxy-serveren.

    • Du må kjenne enhetene dine, slik at du har en kontekst (IP-adresser, typen enhet og så videre) for eventuelle ytelsesproblemer som oppstår.

    • Proxy-serverne er vanlige utgangspunkter, slik at du kan gå til nettleseren for å se hvilken proxyserver den er satt opp til å bruke.

    • Det finnes verktøy som kan oppdage og kartlegge nettverket, men den sikreste måten å kjenne enhetene på er å spørre et medlem av nettverksteamet.

  • Identifiser Internett-leverandøren (ISP), skriv ned kontaktinformasjonen deres og spør hvor mye båndbredde dere har.

  • I organisasjonen bør du identifisere ressursene for enhetene mellom klienten og utgangspunktet eller identifisere en nødkontakt som du kan snakke med om nettverksproblemer.

Her er noen referanseverdier som en enkel test med verktøy kan beregne for deg:

  • tiden det tar fra klientdatamaskinen til grensepunktet i millisekunder

  • tiden fra grensepunktet til Office 365 i millisekunder

  • hvor serveren som oversetter nettadressene for Office 365 når du surfer på Internett, rent fysisk befinner seg

  • hastigheten på leverandørens DNS-oppløsning i millisekunder, inkonsekvenser i ankomst av pakker (variasjoner i nettverket), opp- og nedlastingstider i millisekunder

I tilfelle du ikke er kjent med hvordan du utfører disse trinnene, går vi mer detaljert gjennom dem senere i denne artikkelen.

Hva er en referanseverdi?

Du kjenner resultatet når ting går dårlig, men hvis du ikke kjenner historiske ytelsesdata, har du ingen kontekst for hvor dårlig det står til eller på hvilke tidspunkter. Uten referanseverdier mangler du derfor en viktig ledetråd for å kunne løse puslespillet: bildet på puslespillesken. Når du feilsøker ytelsen, trenger du noe å sammenligne med. Det er ikke vanskelig å registrere enkle ytelsesreferanser. Driftsavdelingen kan få i oppgave å utføre disse målingene etter en tidsplan. La oss for eksempel si at tilkoblingen ser slik ut:

En enkel nettverksgrafikk som viser klient, proxy og Office 365-skyen.

Dette innebærer at du har undersøkt med nettverksgruppen og funnet ut at du går fra organisasjonen og ut til Internett gjennom en proxy-server, og at denne proxyen tar seg av alle forespørslene som klientdatamaskinen sender til skyen. I dette tilfellet bør du tegne en forenklet versjon av tilkoblingen som inneholder alle de mellomliggende enhetene. Nå kan du sette inn verktøy du kan bruke til å teste ytelsen mellom klienten, utgangspunktet (punktet der du forlater nettverket og går over til Internett) og Office 365-skyen.

Grunnleggende nettverk med klient, proxy og skyen, og verktøyforslag PSPing, TraceTCP og nettverkssporinger.

Alternativene er oppført som Enkle og Avanserte ut fra hvor stor ekspertise du trenger for å finne ytelsesdataene. Det tar mye tid å spore et nettverk, i forhold til å kjøre kommandolinjeverktøy som PsPing og TraceTCP. Disse to kommandolinjeverktøyene ble valgt fordi de ikke bruker ICMP-pakker, som ville bli blokkert av Office 365, og fordi de angir hvor mange millisekunder det tar å forlate klientdatamaskinen, eller proxy-serveren (hvis du har tilgang til den), og komme til Office 365. Hvert enkelt sprang fra én datamaskin til en annen vil gi en tidsverdi, som egner seg perfekt som en referanseverdi! Like viktig er det at disse kommandolinjeverktøyene gir deg mulighet til å legge en portnummer til kommandoen. Dette er nyttig fordi Office 365 kommuniserer over port 443, som er porten som brukes av Secure Sockets Layer og Transport Layer Security (SSL og TLS). Andre tredjepartsverktøy kan imidlertid egne seg bedre for din situasjon. Microsoft støtter ikke alle disse verktøyene, så hvis du av en eller annen grunn ikke kan få PsPing og TraceTCP til å fungere, kan du gå videre til et nettverksspor med et verktøy som Netmon.

Du kan registrere en referanseverdi før åpningstid, en ny under tung bruk, og deretter på nytt etter stengetid. Dette innebærer at du kan ha en mappestruktur som til slutt vil se ut omtrent slik:

Grafikk som foreslår en måte å organisere ytelsesdata i mapper.

Du bør også velge en navnekonvensjon for filene. Her er noen eksempler:

  • 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

Det er mange måter å gjøre dette på, men formatet <dateTime><what's happening in the test> er et bra sted å starte. Hvis du er nøye med dette, vil det være til stor hjelp når du prøver å feilsøke problemer senere. Senere vil du kunne si: Jeg tok to sporinger den 8. februar. Den første viste god ytelse, mens den andre viste dårlig ytelse, slik at vi kan sammenligne dem. Dette er svært nyttig i forbindelse med en feilsøking.

Du må ha en strukturert måte å samle historiske referanseverdier på. I dette eksemplet produserte de enkle metodene tre sett med kommandolinjeutdata, og resultatene ble registrert som skjermbilder, men du kan ha filer for nettverksregistrering i stedet. Bruk metoden som fungerer best for deg. Lagre de historiske referanseverdiene, og kontroller dem når du oppdager endringer i hvordan nettbaserte tjenester fungerer.

Hvorfor samle inn ytelsesdata under en utprøving?

Det beste tidspunktet for å begynne å registrere referanseverdier er under en utprøving av Office 365-tjenesten. Organisasjonen kan ha tusenvis eller hundretusener av brukere, eller kanskje bare fem, men selv med et lite antall brukere kan du utføre tester for å måle svingninger i ytelsen. Når det gjelder store organisasjoner, kan et representativt utvalg på noen hundre brukere som prøver ut Office 365, gi resultater som kan brukes på flere tusen brukere, slik at du vet hvor det kan oppstå problemer før de viser seg.

Hvis det er snakk om en liten organisasjon, der påloggingen medfører at alle brukerne logger seg på tjenesten samtidig og dere ikke har noen utprøvingsperiode, bør du måle resultater slik at du har data du kan vise til noen som må gjennomføre en feilsøking for å løse en operasjon som fungerer dårlig. For eksempel hvis du oppdager at du plutselig kan ta deg en spasertur rundt bygningen i løpet av den tiden det tar å laste opp en mellomstor grafikkfil der det pleide å være gjort på et øyeblikk.

Hvordan hente inn referanseverdier

Alle feilsøkingsplaner forutsetter at du identifiserer følgende som et minimum:

  • klientdatamaskinen du bruker (typen datamaskin eller enhet, en IP-adresse og handlingene som forårsaket problemet)

  • hvor klientdatamaskinen er plassert i verden (for eksempel om denne brukeren er på et VPN-nettverk, jobber eksternt eller er på selskapets intranett)

  • punktet der klientdatamaskinen forlater nettverket (punktet der datatrafikken forlater bedriften til fordel for en Internett-leverandør eller Internett)

Du kan få en oversikt over nettverksoppsettet fra nettverksadministratoren. Hvis du har et lite nettverk, bør du ta en titt på enhetene som kobler deg til Internett, og kontakte Internett-leverandøren hvis du har spørsmål om oppsettet. Lag et bilde av det endelige oppsettet for fremtidig referanse.

Denne delen er delt inn i enkle kommandolinjeverktøy og -metoder og mer avanserte verktøyalternativer. Vi vil først se på de enkle metodene. Hvis du imidlertid har et ytelsesproblem akkurat nå, bør du gå til de avanserte metodene og prøve feilsøkingsplanen for å samle inn ytelsesprøver.

Enkle metoder

Hensikten med disse enkle metoder er å lære å ta, forstå og lagre enkle ytelsesreferanser over tid på en god måte slik at du holder deg oppdatert om ytelsen til Office 365. Her er diagrammet. Det er svært enkelt, og du har sett det før:

Grunnleggende nettverk med klient, proxy og skyen, og verktøyforslag PSPing, TraceTCP og nettverkssporinger.

Kommentarer: 

  • Vi har tatt med TraceTCP i dette skjermbildet fordi det er et nyttig verktøy når du vil vise hvor lang tid det tar i millisekunder å behandle en forespørsel, og hvor mange nettverkssprang, eller koblinger fra én datamaskin til den neste, som forespørselen gjennomfører for å nå et mål. TraceTCP kan også gi navnene på servere som brukes under sprang, noe som kan være nyttig når brukerstøtte skal feilsøke Microsoft Office 365.

  • TraceTCP-kommandoene kan være svært enkle, for eksempel:

  • tracetcp.exe outlook.office365.com:443

  • Husk å ta med portnummeret i kommandoen.

  • TraceTCP kan lastes ned gratis, men forutsetter Wincap. Wincap er et verktøy som også brukes og installeres av Netmon. Vi bruker også Netmon i den avanserte metodedelen.

Hvis du har flere kontorer, må du i tillegg lagre et datasett fra en klient på hver av disse plasseringene. Denne testen måler ventetiden, som i dette tilfellet er en tallverdi som beskriver tiden det tar fra en klient sender en forespørsel til Office 365, og til Office 365 svarer på forespørselen. Testingen har sitt utspring på en klientdatamaskin innenfor domenet og prøver å måle en rundtur fra et punkt i nettverket, ut gjennom et utgangspunkt, over Internett til Office 365 og tilbake igjen.

Det er flere måter å håndtere utgangspunktet på, som i dette tilfellet vil si proxy-serveren. Du kan enten spore fra 1 til 2 og videre fra 2 til 3, og deretter legger sammen tallene i millisekunder for å få en endelig totalsum til kanten av nettverket. Eller du kan konfigurere tilkoblingen slik at den ikke bruker proxyserveren for Office 365-adresser. Hvis dere har et større nettverk med en brannmur, omvendt proxy eller en kombinasjon av disse to, kan det hende at du må opprette unntak på proxy-serveren som tillater trafikk for en mengde nettadresser. Se listen over endepunkter som brukes i Office 365, iOffice 365 adresser og IP-adresseområder. Hvis du har en godkjennings-proxy, begynner du med å teste unntak for følgende:

  • port 80 og 443

  • TCP-er og HTTP-er

  • Utgående tilkoblinger til noen av disse nettadressene:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Alle brukere må ha tilgang til disse adressene uten godkjenning eller og uten å måtte bruke en proxy. Hvis dere har et mindre nettverk, bør du legge dem til på listen over adresser som ikke skal bruke proxyen i nettleseren.

I Internet Explorer legger du dem til på listen over adresser som ikke skal bruke proxy-en, ved å gå til Verktøy > Alternativer for Internett > Tilkoblinger > LAN-innstillinger > Avansert. Du finner også proxy-serveren og proxy-serverporten på Avansert-fanen. Det kan hende du må klikke i avmerkingsboksen Bruk en proxy-server til lokalnettet for å få tilgang til Avansert knappen. Pass på at det er krysset av for Ikke bruk proxy-server for lokale adresser. Når du klikker Avansert, vil du se en tekstboks der du kan skrive inn unntak. Bruk semikolon til å skille de ovenstående nettadressene med jokertegnet, for eksempel:

*.microsoftonline.com; *.sharepoint.com

Når du ikke lenger bruker en proxy, bør du kunne bruke ping eller PsPing direkte for en nettadresse til Office 365. Neste trinn er å ping-teste outlook.office365.com. Hvis du bruker PsPing eller et annet verktøy som lar deg angi et portnummer til kommandoen, bruker du PsPing mot portal.microsoftonline.com:443 for å se gjennomsnittstiden for hele runden i millisekunder.

Round Trip Time (RTT), som er tiden denne runden tar, er en tallverdi som måler hvor lang tid det tar å sende en HTTP-forespørsel til en server som outlook.office365.com og få et svar tilbake som bekrefter at serveren vet at du sendte denne forespørselen. Noen ganger ser du dette forkortet som RTT. Dette bør være et relativt kort tid.

Hvis du skal gjennomføre denne testen, må du bruke PSPing eller et annet verktøy som ikke bruker ICMP-pakker, da de blir blokkert av Office 365.

Hvordan bruke PsPing for å få en samlet rundturtid i millisekunder direkte fra en Office 365-nettadresse

  1. Kjør en forbedret ledetekst ved å gjennomføre disse trinnene:

    1. Klikk Start.

    2. Skriv inn cmd i boksen Start Søk, og trykk deretter CTRL+SKIFT+ENTER.

    3. Hvis dialogboksen Brukerkontokontroll vises, bekrefter du at handlingen den viser, er det du ønsker. Klikk deretter Fortsett.

  2. Naviger til mappen der verktøyet (i dette tilfellet PsPing) er installert, og test disse Office 365 nettadressene:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      PSPing-kommandoen til microsoft-my.sharepoint.com port 443.

Pass på å inkludere portnummeret 443. Husk at Office 365 fungerer på en kryptert kanal. Forespørselen vil mislykkes hvis du bruker PsPing uten portnummeret. Når du har pinget den korte liste, må du se etter Average time in milliseconds (ms) (Gjennomsnittstid i millisekunder (ms)). Det er denne tiden du vil registrere!

Grafikk som viser en illustrasjon av klient til proxy PSPing med en rundturtid på 2,8 millisekunder.

Hvis du ikke er kjent med hvordan du unngår proxyer og foretrekker å ta ting trinnvis, må du først finne ut hva proxy-serveren heter. Hvis du bruker Internet Explorer, går du til Verktøy > Alternativer for Internett > Tilkoblinger > LAN-innstillinger > Avansert. Du finner hvilken proxy-server du bruker, på Avansert-fanen. Ping proxy-serveren i en ledetekst ved å fullføre denne oppgaven:

Hvis du vil pinge proxy-serveren og få en rundturverdi i millisekunder for trinn 1 til 2

  1. Kjør en forbedret ledetekst ved å gjennomføre disse trinnene:

    1. Klikk Start.

    2. Skriv inn cmd i boksen Start Søk, og trykk deretter CTRL+SKIFT+ENTER.

    3. Hvis dialogboksen Brukerkontokontroll vises, bekrefter du at handlingen den viser, er det du ønsker. Klikk deretter Fortsett.

  2. Skriv inn ping <navnet på proxy-serveren nettleseren bruker, eller IP-adressen til proxy-serveren>. Trykk deretter ENTER. Hvis du har PsPing eller et annet verktøy installert, kan du bruke dette verktøyet i stedet.

    Kommandoen kan se ut som et av disse eksemplene:

    • 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. Når sporet ikke lenger sender testpakker, får du et lite sammendrag som gir et gjennomsnitt i millisekunder. Det er denne verdien du er ute etter. Ta et skjermbilde av ledeteksten, og lagre det ved hjelp av navngivningsregelen din. Her kan det også være til hjelp å skrive inn denne verdien på diagrammet.

Kanskje du har tatt et spor tidlig om morgenen, og klienten når proxyen (eller et annet utgangspunkt som dere bruker ut til Internett) raskt. I dette tilfellet ser tallene kanskje slik ut:

Grafikk som viser rundturtiden fra en klient til en proxy på 2,8 millisekunder.

Om klientdatamaskinen er en av noen få som har tilgang til proxy-serveren (eller utgangsserveren), kan du kjøre neste etappe av testen ved å koble deg til datamaskinen eksternt ved å kjøre ledeteksten for å kjøre PsPing til en nettadresse for Office 365 derfra. Hvis du ikke har tilgang til denne datamaskinen, kan du kontakte de nettverksansvarlige deres for å få hjelp med neste etappe og få nøyaktige tall på den måten. Hvis dette ikke er mulig, kan du kjøre en PsPing mot den aktuelle nettadressen for Office 365 og sammenligne den med PsPing- eller ping-tiden mot proxy-serveren.

Hvis du for eksempel måler 51,84 millisekunder fra klienten til nettadressen for Office 365, og det tar 2,8 millisekunder fra klienten til proxyen (eller utgangspunktet), da tar det 49,04 millisekunder fra utgangspunktet til Office 365. Hvis du på samme måte har en PsPing på 12,25 millisekunder fra klienten til proxy-serveren når det er størst belastning om dagen, og 62,01 millisekunder fra klienten til nettadressen for Office 365, da blir gjennomsnittsverdien 49,76 millisekunder for tiden fra proxy-utgangspunktet til nettadressen for Office 365.

Ekstra grafikk som viser ping i millisekunder fra klient til proxy i tillegg til klient i Office 365, slik at verdiene kan trekkes fra.

I forbindelse med feilsøkinger kan det være du finne noe interessant bare ved å ta vare på disse referanseverdiene. Hvis du for eksempel ser at du vanligvis har en ventetid på 40 til 59 millisekunder fra proxyen eller utgangspunktet til nettadressen for Office 365, og ventetiden er fra 3 til 7 millisekunder fra klient til proxy eller utgangspunkt (avhengig av hvor stor nettverkstrafikken er på vedkommende tidspunkt på dagen), kan du vite med sikkerhet at det har oppstått problemer hvis de siste tre referanseverdiene for klient til proxy eller utgang viser en ventetid på 45 millisekunder.

Avanserte metoder

Hvis du virkelig vil vite hva som skjer med Internett-forespørslene til Office 365, må du bli kjent med nettverksspor. Det spiller ingen rolle hvilke verktøy du foretrekker for disse sporene – HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard eller et hvilket som helst annet verktøy vil fungere, forutsatt at det kan samle og filtrere nettverkstrafikk. I denne delen vil du se at det lønner seg å kjøre flere av disse verktøyene for å få et mer fullstendig bilde av problemet. Når du tester, fungerer noen av disse verktøyene også som proxyer. Verktøy som er benyttet i den tilhørende artikkelen, Feilsøkingsplan for ytelse i Office 365 bruker Netmon 3.4, HTTPWatch eller WireShark.

Den enkle delen av denne metoden er å registrere en ytelsesreferanse, og mange av trinnene er de samme som når du feilsøker ytelsesproblemer. De mer avanserte metodene for å opprette referanseverdier for ytelsen forutsetter at du registrerer og lagrer nettverksspor. De fleste av eksemplene i denne artikkelen bruker SharePoint Online, men du bør utvikle en liste over vanlige handlinger på alle Office 365-tjenestene du abonnerer på, for testing og registrering. Her er et referanseverdieksempel:

  • Referanseverdiliste for SPO – 1. trinn: Søk på hjemmesiden for SPO-nettstedet og kjør et nettverksspor. Lagre sporet.

  • Referanseverdiliste for SPO – 2. trinn: Søk etter en term (for eksempel firmanavnet deres) med Enterprise Search, og kjør en nettverkssporing. Lagre sporet.

  • Referanseverdiliste for SPO – 3. trinn: Last opp en stor fil til et SharePoint Online-dokumentbibliotek og kjør en nettverkssporing. Lagre sporet.

  • Referanseverdiliste for SPO – 4. trinn: Søk på hjemmesiden for OneDrive-nettstedet og kjør en nettverkssporing. Lagre sporet.

Denne listen bør omfatte de viktigste vanlige handlingene som brukerne utfører mot SharePoint Online. Legg merke til at det siste trinnet, å spore ved å gå til OneDrive for Business, bygger opp en sammenligning mellom opplastingen av nettsiden for SharePoint Online (som ofte er tilpasset av selskaper) og nettsiden for OneDrive for Business, som sjelden blir tilpasset. Dette er en svært enkel test av et SharePoint Online-nettsted som lastes inn langsomt. Du kan bygge et register av denne forskjellen inn i testingen.

Hvis du står midt i et ytelsesproblem, vil mange disse trinnene være de samme som når du registrerer en referanseverdi. Nettverkspor er helt avgjørende. I neste punkt vil vi derfor se på hvordan du registrerer de viktige sporene.

Hvis du skal takle et ytelsesproblem her og nå, må du registrere et spor nettopp når du opplever ytelsesproblemet. Du må ha de riktige verktøyene tilgjengelig for å samle inn logger, og du trenger en handlingsplan, det vil si en liste over feilsøkingshandlinger for å samle inn best mulig informasjon. Det første du må gjøre, er å registrere datoen og klokkeslettet for testen slik at filene kan lagres i en mappe som gjenspeiler tidspunktet. Neste trinn er å begrense til selve problemtrinnene. Dette er de nøyaktige trinnene du føler for testingen. Du må ikke glemme det grunnleggende: Hvis problemet bare forekommer med Outlook, må du passe på å registrere at problemet kun oppstår i én Office 365-tjeneste. Du må gradvis snevre inn omfanget av dette problemet. Det vil hjelpe deg til å fokusere på noe du kan løse.

Se også

Administrere Office 365-endepunkter

Utvid ferdighetene dine
Utforsk opplæring
Vær først ute med de nye funksjonene
Bli med i Office Insiders

Var denne informasjonen nyttig?

Takk for tilbakemeldingen!

Takk for tilbakemeldingen! Det høres ut som det kan være lurt å sette deg i kontakt med én av våre Office-kundestøtteagenter.

×