Justering af ydeevne for Office 365 ved hjælp af grundlinjer og ydeevnehistorik

Der findes nogle enkle måder at kontrollere ydeevnen i forbindelsen mellem Office 365 og din virksomhed, som gør det muligt at fastlægge en omtrentlig grundlinje for dine forbindelse. Når du har en oversigt over ydeevnen for din klientcomputers forbindelser kan du opdage latente komplikationer og identificere og forudsige problemer.

Hvis du ikke er vant til at arbejde med problemer med ydeevne, vil denne artikel hjælpe dig med at overveje nogle almindelige spørgsmål, f.eks. hvor ved du fra, at det problem, du oplever, er et ydelsesproblem og ikke en Office 365-tjenestehændelse? Hvordan kan du planlægge god ydeevne på lang sigt? Hvordan kan du holde øje med ydeevnen? Hvis dit team eller dine klienter oplever langsom ydeevne, mens de bruger Office 365, og du undrer dig over nogen af disse spørgsmål, så fortsæt med at læse denne artikel.

Vigtigt: Har du ydelsesproblemer mellem din klient og Office 365 lige nu? Følg de trin, der er beskrevet i Ydeevne, fejlfinding i forbindelse med planen for Office 365.

Der er noget, du bør vide om Office 365-ydeevnen

Office 365 fungerer i et dedikeret Microsoft-netværk med høj kapacitet, der er konstant overvåget, ikke blot ved automatisering, men af rigtige mennesker. En del af rollen med at vedligeholde Office 365-skyen er justering og strømlining af den indbyggede ydeevne, hvor det er muligt. Da klienter i Office 365-skyen skal oprette forbindelse på tværs af internettet, er det en fortløbende indsats at finjustere ydeevnen på tværs af Office 365-tjenesterne. Forbedring af ydeevnen stopper aldrig rigtig i skyen, og der findes en masse erfaringer med at holde skyen sund og hurtig. Hvis du oplever ydelsesproblemer i forbindelse med at oprette forbindelse fra din placering til Office 365, er det bedst ikke at starte med, og vente på, en supportsag. Du skal i stedet starte med at undersøge problemet 'indefra og ud'. Dvs. starte inden i dit netværk og arbejde dig ud til Office 365. Før du åbner en sag med Office 365 Support, kan du indsamle data og udføre handlinger, som vil undersøge, og evt. løse, dit problem.

Vigtigt: Vær opmærksom på planlægningen af kapacitet og begrænsninger i Office 365. Disse oplysninger vil give dig et forspring, når du forsøger at løse problemer med ydeevnen. Her er et link til Tjenestebeskrivelsen af Office 365-platformen. Dette er en central hub, og alle tjenester, der tilbydes i Office 365, har et link, der peger på deres egne Tjenestebeskrivelser herfra. Det betyder, at hvis du har brug for at se f.eks. standardbegrænsningerne for SharePoint Online, skal du klikke på Tjenestebeskrivelse for SharePoint Online og finde afsnittet SharePoint Online-begrænsninger.

Sørg for, at du går til fejlfindingen med forståelsen for, at ydeevne er en glidende skala, det handler ikke om at opnå en idealiseret værdi og at bevare den permanent (hvis du mener dette er tilfældet, vil lejlighedsvise opgaver, der kræver høj båndbredde, som at få et stort antal brugere i gang eller at foretage store dataoverførsler, blive meget stressende – så lav planer om ydeevnens påvirkninger derefter). Du kan og skal have en overordnet ide om dine mål, men mange variabler spiller ind i ydeevnen, derfor varierer resultaterne. Det er en del af ydeevnens natur.

Fejlfinding af ydeevne handler ikke om at opfylde specifikke mål og vedligeholde disse tal på ubestemt tid. Det handler om at forbedre eksisterende aktiviteter på baggrund af alle variablerne.

Ok, hvordan ser et ydelsesproblem ud?

Først skal du sikre dig, at det, du rent faktisk oplever, er et ydelsesproblem og ikke en tjenestehændelse. Et ydelsesproblem adskiller sig fra en tjenestehændelse i Office 365. Sådan kan du skelne dem fra hinanden.

Hvis Office 365-tjenesten oplever problemer, så er det en tjenestehændelse. Du kan se røde eller gule ikoner under Aktuel tilstand i Office 365 Administration, du oplever muligvis også langsom ydeevne på klientcomputere, der er forbundet til Office 365. Hvis f.eks. Aktuel tilstand rapporterer et rødt ikon, og du kan se Undersøgelse ud over Exchange, kan det være, at du også modtager en masse opkald fra personer i organisationen, som klager over, at klientpostkasser, der bruger Exchange Online, fungerer dårligt. I dette tilfælde er det rimeligt at antage, at din Exchange Online-ydeevne oplever problemer inden for tjenesten.

Tilstandsdashboardet i Office 365 med alle arbejdsbelastninger, som viser grønt, bortset fra Exchange, som viser Tjenesten er gendannet.

På dette tidspunkt bør du, Office 365-administratoren, kontrollere Aktuel tilstand og derefter Vis detaljer og oversigt ofte for at holde dig opdateret om den vedligeholdelse, vi udfører på systemet. Dashboardet Aktuel tilstand blev lavet for at opdatere dig om ændringer af og problemer med tjenesten. De noter og forklaringer, der er i tilstandshistorikken, fra administrator til administrator, er der for at hjælpe dig med at måle dine resultater og for at holde dig opdateret om igangværende arbejde.

Et billede af dashboardet for tjenestetilstand Office 365, som angiver, at Exchange Online-tjenesten er gendannet og hvorfor.

Ydelsesproblemer er ikke en tjenestehændelse, selvom hændelser kan medføre langsom ydeevne. Ydelsesproblemer kan være:

  • Problemer med ydeevnen, uanset hvad Office 365 Administration Aktuel tilstand rapporterer til tjenesten.

  • Funktioner, der normalt er relativt problemfrie, tager lang tid at gennemføre eller gennemføres aldrig.

  • At du også kan gentage problemet, eller du i det mindste ved, at problemet vil forekomme, hvis du udfører den rigtige række trin.

  • Midlertidige, men med et mønster. Du ved f.eks., at kl. 10:00 får du opkald fra brugere, der ikke kan få adgang til Office 365, og at opkaldene bliver færre omkring middag.

Dette lyder højst sandsynligt velkendt, måske også lidt for velkendt. Når du ved, at det er et ydelsesproblem, er spørgsmålet "Hvad gør du så?" Resten af denne artikel hjælper dig med at finde ud af netop det.

Sådan definerer og tester du ydelsesproblemet

Problemer med ydeevnen opstår ofte over tid, så det kan være en udfordring at definere det egentlige problem. Du skal lave en god problemformulering, have en idé om problemets kerne og derefter generere testtrin for at løse problemet. Ellers kan du være helt tabt, uden du selv er skyld i det. Hvorfor? Her er nogle eksempler på problemformulering, der ikke giver nok oplysninger:

  • Det at skifte fra min indbakke til min kalender plejer at være noget, som jeg ikke bemærker, og nu tager det lige så lang tid som en kaffepause. Kan du få det til at fungere, som det plejer?

  • Det at overføre mine filer til SharePoint Online tager uendelig lang tid. Hvorfor er det langsomt om eftermiddagen, mens det på andre tidspunkter er hurtigt? Kan det ikke blot være hurtigt?

Der er flere større udfordringer med ovenstående problemformuleringer. Der er især mange uklarheder, der skal håndteres. Det kan f.eks. være:

  • Det er uklart, hvordan skiftet mellem Indbakke og Kalender plejede at påvirke den bærbare computer.

  • Når brugeren siger "Kan det ikke blot være hurtigt", hvad er så "hurtigt"?

  • Hvor lang tid er "uendelig lang tid"? Er det flere sekunder eller minutter, eller kan brugeren gå til frokost, og det er først færdigt ti minutter efter brugeren er kommet tilbage?

Alt dette er uden at overveje, at administratoren og fejlfinderen ikke får nok detaljer fra sådanne problemformuleringer. Det kan f.eks. være, hvornår problemet startede; at brugeren arbejder hjemmefra og altid kun oplever langsomme skift, når han eller hun er på et hjemmenetværk, at brugeren skal køre flere andre RAM-krævende programmer på den lokale klient; eller at brugeren kører et ældre operativsystem eller ikke har de nyeste opdateringer.

Når brugerne rapporterer om ydelsesproblemer, er der mange oplysninger, der skal indsamles. Indsamling af disse oplysninger er en del af en proces kaldet angivelse af problemets omfang eller undersøgelse af problemet. Følgende er en grundlæggende liste, du kan bruge til at indsamle oplysninger om ydelsesproblemet. Listen er ikke komplet, men du kan bruge den som grundlag for dine egne lister:

  • På hvilken dato forekom problemet, og på hvilket tid af døgnet?

  • Hvilken type klientcomputer brugte du, og hvordan opretter den forbindelse til virksomhedens netværk (VPN, kablet, trådløst)?

  • Arbejdede du eksternt eller på kontoret?

  • Prøvede du de samme handlinger på en anden computer, og oplevede du det samme?

  • Gennemgå de trin, der giver dig problemer, så du kan notere de handlinger, du foretager.

  • Hvor langsom i er ydeevnen i sekunder eller minutter?

  • Hvor i verden er du placeret?

Nogle af disse spørgsmål er mere oplagte end andre. De fleste har forståelse for, at fejlfindere har brug for de nøjagtige trin for at genskabe problemet. For hvordan kan du ellers finde ud af, hvad der er galt, og hvordan kan du ellers afprøve, om problemet er løst? Mindre indlysende er ting som "Hvilken dato og hvilket klokkeslæt oplevede du problemet?" og "Hvor i verden er du placeret? " – oplysninger, som kan bruges samlet. Afhængigt af, hvornår brugeren arbejdede, kan et par timers tidsforskel betyde, at vedligeholdelse allerede er i gang på dele af firmaets netværk. Hvis f.eks. dit firma har en hybrid implementering, f.eks. en hybrid SharePoint Search, som kan sende en forespørgsel om søgeindekset i både SharePoint Online og en lokal SharePoint Server 2013-forekomst, er der måske opdateringer undervejs i den lokale farm. Hvis din virksomhed er helt i skyen, kan systemvedligeholdelse omfatte at tilføje eller fjerne netværkshardware, lancere opdateringer, der gælder for hele virksomheden, eller foretage ændringer af DNS eller anden grundlæggende infrastruktur.

Når du fejlfinder et ydelsesproblem, er det lidt lige som efterforskning af en forbrydelse, du skal være præcis og opmærksom for at drage konklusioner ud fra beviserne. For at gøre dette skal du have en god problemformulering ved at indsamle beviser. Det bør omfatte computerens kontekst, brugerens kontekst, hvornår problemet startede samt de nøjagtige trin, der afdækkede ydelsesproblemerne. Problemformuleringen skal være, og skal blive ved med at være, den første side i dine noter. Ved at gennemgå problemformuleringen igen, efter du har arbejdet på en løsning, tester og beviser du, om de handlinger, du har foretaget, har løst problemet. Dette er afgørende for at vide, hvornår dit arbejde er udført.

Ved du, hvordan ydelsen så ud, når den var god?

Hvis du er uheldig, er der ingen, der ved det. Ingen havde tallene. Det betyder, at ingen kan besvare det simple spørgsmål "Hvor mange sekunder plejede det at tage for at få vist en indbakke i Office 365?" eller "Hvor lang tid plejede det at tage, når lederne havde et Lync Online-møde?", hvilket er et almindeligt scenario for mange virksomheder.

Det, der mangler her, er en grundlinje for ydeevnen.

Grundlinjer giver dig en kontekst for din ydeevne. Du bør ind i mellem eller jævnligt lave en grundlinje, afhængigt af behovene i din virksomhed. Hvis du er i en større virksomhed, har dit driftsteam muligvis allerede en grundlinje for dit lokale miljø. Hvis du f.eks. udfører programrettelse af alle Exchange-servere den første mandag i måneden og alle dine SharePoint-servere hver tredje mandag, har dit driftsteam formentlig en liste over opgaver og scenarier, der køres, når programrettelserne er gennemført, for at kunne efterprøve, at kritiske funktioner fungerer. Det kan f.eks. være åbning af Indbakke, klik på Send/modtag og sørge for, at mapper er opdateret. I SharePoint kan det være at gennemgå primære sider på webstedet, gå til Enterprise Search-side og at foretage søgninger, der returnerer resultater.

Hvis dine programmer findes i Office 365, vil nogle af de mest grundlæggende grundlinjer, du kan oprette, måle tid (i millisekunder) fra en klientcomputer inden i dit netværk, til et udgangspunkt, eller det punkt, hvor du forlader dit netværk og går ud til Office 365. Her er nogle nyttige grundlinjer, som du kan undersøge og registrere:

  • Identificer enhederne mellem computeren og dit udgangspunkt, f.eks. din proxyserver.

    • Du skal kende dine enheder, så du har konteksten (IP-adresser, type af enhed osv.) for de ydelsesproblemer, der opstår.

    • Proxyservere er almindelige udgangspunkter, så du kan tjekke din webbrowser for at se, hvordan proxyserveren indstilles til brug, hvis dette er relevant.

    • Der findes tredjepartsværktøjer, der kan opdage og afbilde netværket, men den sikreste måde at kende dine enheder på er at spørge et medlem af dit netværksteam.

  • Identificer din internetudbyder (ISP), notér deres kontaktoplysninger, og spørg, hvor mange kredsløb, og hvor meget båndbredde du har.

  • Identificer ressourcer inden for virksomheden til enhederne mellem din klient og udgangspunktet, eller identificer en nødkontakt for at tale om netværksproblemer.

Her er nogle grundlinjer, som en simpel test med værktøjer kan beregne for dig:

  • Tid fra klientcomputeren til dit udgangspunkt i millisekunder

  • Tid fra dit udgangspunkt peger på Office 365 i millisekunder

  • Placering i verden på serveren, der løser URL-adresserne for Office 365, når du er på nettet

  • Hastigheden på din internetudbyders DNS-opløsning i millisekunder, uoverensstemmelser i pakkeoverførsler overskrider ankomst (netværksrysten), tider for upload og download i millisekunder

Hvis du ikke ved, hvordan du kan udføre disse trin, går vi mere i detaljer i denne artikel.

Hvad er en grundlinje?

Du kender påvirkningen, når det går dårligt, men hvis du ikke kender dine historiske ydeevnedata, er det ikke muligt at have en kontekst for, hvor dårligt det kan være blevet, og hvornår. Så uden en grundlinje mangler du det vigtigste punkt for at løse puslespillet: billedet på puslespillet. Ved fejlfinding af ydeevne skal du have et punkt at sammenligne med. Det er ikke svært at lave simple grundlinjer for ydeevnen. Dit driftsteam kan have til opgave at sikre disse ud fra en tidsplan. Antag f.eks., at din forbindelse ser sådan ud:

En grundlæggende netværksgrafik, som viser klient, proxy og Office 365-sky.

Det betyder, at du har tjekket med dit netværksteam og fandt ud af, at din virksomhed kommer på internettet via en proxyserver, og at proxy håndterer alle anmodninger, som klientcomputeren sender til skyen. I dette tilfælde skal du tegne en forenklet udgave af din forbindelse, der viser alle de mellemliggende enheder. Nu skal du indsætte værktøjer, som du kan bruge til at teste ydeevnen mellem klienten, udgangspunktet (hvor du efterlader netværket til internettet), og Office 365-skyen.

Standardnetværk med klient, proxy og sky, og værktøjsforslagene PSPing, TraceTCP og netværkssporing.

Indstillingerne vises som Enkle og Avancerede på grund af den mængde ekspertise, du skal bruge for at finde dataene for ydeevnen. Et netværksspor tager lang tid, sammenlignet med løbende kommandolinjeværktøjer som PsPing og TraceTCP. Disse to kommandolinjeværktøjer blev valgt, fordi de ikke bruger ICMP-pakker, som vil være blokeret af Office 365, og fordi de angiver tiden i millisekunder, der kræves for at lade klientcomputeren eller proxyserveren (hvis du har adgang) at nå frem til Office 365. Hver enkelt hop fra én computer til en anden ender med en klokkeslætsværdi, og det er godt til grundlinjen! Hvad der er lige så vigtigt, så gør disse kommandolinjeværktøjer det muligt at tilføje portnummeret på kommandoen, dette er praktisk, fordi Office 365 kommunikerer over port 443, som er den port, der bruges af Secure Sockets Layer og Transport Layer Security (SSL og TLS). Men andre tredjepartsværktøjer kan være bedre løsninger for din situation. Microsoft understøtter ikke alle disse værktøjer, så hvis du af en eller anden grund ikke kan få PsPing og TraceTCP til at fungere, skal du gå videre til et netværksspor med et værktøj som Netmon.

Du kan lave en grundlinje før åbningstid, igen under intensiv brug og derefter igen efter lukketid. Det betyder, at du kan have en mappestruktur, som ser lidt sådan ud i slutningen:

Grafik, som foreslår en måde at organisere dine ydeevnedata i mapper.

Du bør også vælge en navngivningsregel for dine filer. Her er nogle 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

Der er mange forskellige måder at gøre dette på, men brug af formatet <dateTime><what's happening in the test> er et godt sted at starte. Det vil hjælpe meget at være omhyggelig med dette, når du forsøger at foretage fejlfinding af problemer senere. Senere skal du kunne sige "jeg lavede to sporinger den 8. februar, hvori én viste god ydeevne og én viste en dårlig ydeevne, så vi kan sammenligne dem". Dette er især nyttigt til fejlfinding.

Du skal have en organiseret måde at bevare dine historiske grundlinjer på. I dette eksempel fremstillede de enkle metoder tre kommandolinjeoutput, og resultaterne blev indsamlet som skærmbilleder, men du kan også indsamle filer i stedet. Benyt den metode, der virker bedst for dig. Gem dine historiske grundlinjer, og henvis til dem på punkter, hvor du bemærker ændringer i dine onlinetjenesters funktioner.

Hvorfor indsamle data om ydeevne under et pilotprojekt?

Der er intet bedre tidspunkt at begynde at oprette grundlinjer på end under et pilotprojekt med Office 365-tjenesten. Dit Office kan have tusindvis af brugere, hundreder af tusinder, eller det kan være fem, men selv med et lille antal brugere, kan du udføre test til at måle udsving i ydeevnen. Hvis du arbejder i en stor virksomhed kan en repræsentativ stikprøve af flere hundrede brugere i et pilotprojekt med Office 365 projiceres udad til flere tusinde, så du ved, hvor problemerne kan opstå, før de forekommer.

Hvis du arbejder i en lille virksomhed, hvor ibrugtagning betyder, at alle brugerne bruger tjenesten på samme tid, og der ikke er noget pilotprojekt, skal du gemme målene for ydeevnen, så du har data, du kan vise alle, der skal foretage fejlfinding af en operation, hvor der opleves dårlig ydeevne. Det kan f.eks. være, at du bemærker, at du pludselig kan gå rundt om bygningen i den tid, det tager at overføre en mellemstor grafikfil, hvor det plejede at ske meget hurtigt.

Sådan indsamler du grundlinjer

For alle fejlfindingsplaner skal du som minimum identificere disse ting:

  • Den klientcomputer du bruger (den type computer eller enhed, en IP-adresse og de handlinger, der forårsagede problemet)

  • Hvor klientcomputeren findes i verden (f.eks. om brugeren er på et VPN med forbindelse til netværket, arbejder eksternt eller på virksomhedens intranet)

  • Det udgangspunkt, klientcomputeren bruger i dit netværk (det punkt, hvor trafikken går fra din virksomhed til en internetudbyder eller internettet)

Du kan finde ud, hvilket layout dit netværk har fra netværksadministratoren. Hvis du er på et lille netværk, kan du kigge lidt på enheder, der forbinder dig til internettet, og ringe til din internetudbyder, hvis du har spørgsmål til layoutet. Opret et billede af det endelige layout til referencen.

Dette afsnit er opdelt i simple kommandolinjeværktøjer og metoder og mere avancerede værktøjer. De enkle metoder bliver gennemgået først. Hvis du derimod har et ydelsesproblem lige nu, skal du gå til avancerede metoder og prøve handlingsplanen for fejlfinding af ydeevne.

Simple metoder

Formålet med disse simple metoder er at lære at oprette, forstå og korrekt gemme simple grundlinjer med ydeevne over tid, så du får oplysninger om Office 365-ydeevnen. Her er det meget simple diagram, som du har set før:

Standardnetværk med klient, proxy og sky, og værktøjsforslagene PSPing, TraceTCP og netværkssporing.

Bemærkninger: 

  • TraceTCP er inkluderet i dette skærmbillede, fordi det er et praktisk værktøj til at vise, i millisekunder, hvor lang tid det tager at behandle en anmodning, samt hvor mange netværkshop, eller forbindelser fra den ene computer til den næste, anmodningen bruger på at nå en destination. TraceTCP kan også give navnene på de servere, der blev brugt under hop, hvilket kan være nyttigt for en Microsoft Office 365-fejlfinder i Support.

  • TraceTCP-kommandoer kan være meget simple, f.eks.:

  • tracetcp.exe outlook.office365.com:443

  • Husk at medtage portnummeret i kommandoen!

  • TraceTCP kan hentes gratis, men er afhængig af Wincap. Wincap er et værktøj, som også bruges og installeres af Netmon. Vi bruger også Netmon i afsnittet med avancerede metoder.

Hvis du har flere kontorer, skal du også beholde et sæt data fra en klient i hver af disse steder. Denne test måler ventetid, som i dette tilfælde er en talværdi, der beskriver mængden af tid mellem en klient, der sender en anmodning til Office 365, og Office 365, der svarer på anmodningen. Testen stammer inde fra dit domæne på en klientcomputer og ser ud til at måle en returkørsel inde fra dit netværk, ud gennem et udgangspunkt, på tværs af internettet til Office 365 og tilbage igen.

Der er flere forskellige måder at behandle udgangspunktet på, i dette tilfælde proxyserveren. Du kan enten spore fra 1 til 2 og derefter 2 til 3 og derefter tilføje tallene i millisekunder for at få en endelig total til kanten af dit netværk. Du kan også konfigurere forbindelsen til at ignorere proxy til Office 365-adresser. I et stort netværk med en firewall, omvendt proxy eller en kombination af de to, kan det være nødvendigt at gøre undtagelser på proxyserveren, der skal tillade trafik at videregive mange URL-adresser. For listen over slutpunkter, der bruges af Office 365, skal du se Office 365-webadresser og IP-adresseområder. Hvis du har en godkendende proxy, kan du begynde ved at teste undtagelser for følgende:

  • Portene 80 og 443

  • TCP og HTTP'er

  • Forbindelser, der er udgående til en af disse URL-adresser:

  • * .microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Alle brugere skal have lov til at nå disse adresser uden proxyforstyrrelser eller -godkendelse. På et mindre netværk skal du tilføje disse til din proxytilsidesættelsesliste i din webbrowser.

Du kan føje disse til din proxytilsidesættelsesliste i Internet Explorer ved at gå til Funktioner > Internetindstillinger > Forbindelser > LAN-indstillinger > Avanceret. Fanen Avanceret er også der, hvor du finder din proxyserver og proxyserverport. Du skal muligvis klikke på afkrydsningsfeltet Brug en proxyserver til LAN for at få adgang til knappen Avanceret. Du skal sørge for, at Brug ikke proxyserver til lokale adresser er markeret. Når du klikker på Avanceret, ser du et tekstfelt, hvor du kan angive undtagelser. Adskil URL-adresser, der er markeret med stjerne herover, med semikolon, f.eks.:

* .microsoftonline.com; * .sharepoint.com

Når du tilsidesætter din proxy, skal du kunne bruge ping eller PsPing direkte på en URL-adresse til Office 365. Det næste skridt bliver at teste ping outlook.office365.com. Eller, hvis du bruger PsPing eller et andet værktøj, som gør det muligt at angive et portnummer til kommandoen, PsPing mod portal.microsoftonline.com:443 for at se gennemsnittet for tiden på returkørslen i millisekunder.

Tiden på returkørslen, eller RTT, er en talværdi, der måler, hvor lang tid det tager at sende en HTTP-anmodning til en server som outlook.office365.com og få respons tilbage, der anerkender, at serveren ved, at det lykkedes. Du får nogen gange vist denne forkortet som RTT. Dette bør vare relativ kort tid.

Du skal bruge PSPing eller et andet værktøj, der ikke anvender ICMP-pakker, som blokeres af Office 365, for at kunne udføre denne test.

Sådan bruger du PsPing til at få en overordnet rundturstid i millisekunder direkte fra en URL-adresse til Office 365

  1. Kør en kommandoprompt med administratorrettigheder ved at udføre disse trin:

    1. Klik på Start .

    2. I feltet Start søgning skal du skrive cmd og derefter trykke på Ctrl+Shift+Enter.

    3. Hvis dialogboksen Kontrol af brugerkonti vises, skal du bekræfte, at den handling, der vises, er den, som du ønsker, og derefter klikke på Fortsæt.

  2. Naviger til den mappe, hvor værktøjet (i dette tilfælde PsPing) er installeret, og test disse URL-adresser til Office 365:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      PSPing-kommando for at gå til microsoft-my.sharepoint.com port 443.

Sørg for at medtage portnummeret på 443. Husk, at Office 365 virker på en krypteret kanal. Hvis du bruger PsPing uden portnummeret, vil din anmodning mislykkes. Når du har pinget din indstillingsliste, skal du kigge efter den gennemsnitlige tid i millisekunder (ms). Det er det, du vil registrere!

Billede, der viser en illustration af klienten til PSPing-proxy med tiden for en returkørsel på 2,8 millisekunder.

Hvis du ikke kender til proxytilsidesættelse og foretrækker at tage tingene trin for trin, skal du først finde ud af navnet på din proxyserver. Gå til Værktøjer > Internetindstillinger > Forbindelser > LAN-indstillinger > Avanceret i Internet Explorer. Fanen Avanceret er det sted, hvor din proxyserver er angivet. Ping proxyserveren med en kommandoprompt ved at gøre følgende:

Sådan pinger du proxyserveren og får en rundtursværdi i millisekunder for trin 1 til 2

  1. Kør en kommandoprompt med administratorrettigheder ved at udføre disse trin:

    1. Klik på Start .

    2. I feltet Start søgning skal du skrive cmd og derefter trykke på Ctrl+Shift+Enter.

    3. Hvis dialogboksen Kontrol af brugerkonti vises, skal du bekræfte, at den handling, der vises, er den, som du ønsker, og derefter klikke på Fortsæt.

  2. Skriv ping <navnet på den proxyserver, din browser bruger, eller IP-adressen på proxyserveren>, og tryk derefter på Enter. Hvis du har PsPing eller noget helt andet værktøj installeret, kan du vælge at bruge dette værktøj i stedet for.

    Din kommando kan se ud som nogen af disse eksempler:

    • 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 sporingen stopper med at sende testpakker, får du en lille oversigt, der viser et gennemsnit, i millisekunder, og det er den værdi, du leder efter. Tag et skærmbillede af prompten, og gem den med din navngivningskonvention. På dette tidspunkt kan det også være en hjælp at udfylde diagrammet med værdien.

Det kan være, at du har udført en sporing tidligt om morgen, og din klient kan komme hurtigt til proxyen (eller hvilken som helst udgangsserver der afsluttes til internettet). I dette tilfælde kan dine tal se således ud:

Billede, der viser tiden for en returkørsel fra en klient til en proxy på 2,8 millisekunder.

Hvis computeren er en af de få udvalgte med adgang til proxyserveren (eller udgangsserveren), kan du køre næste etape af testen ved at tilslutte eksternt til den pågældende computer, der kører kommandoprompten til PsPing på en URL-adresse til Office 365 derfra. Hvis du ikke har adgang til computeren, kan du kontakte dine netværksressourcer for at få hjælp til næste etape og få nøjagtige tal på den måde. Hvis det ikke er muligt, kan du tage et PsPing mod den pågældende URL-adresse til Office 365 og sammenligne det med PsPing eller pinge tid mod din proxyserver.

Hvis du f.eks. har 51,84 millisekunder fra klienten til URL-adressen til Office 365, og du har 2,8 millisekunder fra klienten til proxyen (eller udgangspunktet), så har du 49,04 millisekunder fra udgangspunktet til Office 365. Og hvis du har en PsPing på 12,25 millisekunder fra klienten til proxyen på det tidspunkt på dagen, hvor der er travlest, og 62,01 millisekunder fra klienten til URL-adressen til Office 365, er gennemsnitsværdien for proxy udgangspunktet til URL-adressen til Office 365 49,76 millisekunder.

Yderligere grafik, der viser ping i millisekunder fra klient til proxy ud for klienten til Office 365, så værdierne kan trækkes fra.

Med hensyn til fejlfinding finder du måske noget spændende ved bare at beholde disse oprindelige planer. Hvis du f.eks. finder ud af, at du generelt har ca. 40 til 59 millisekunder med ventetid fra proxyen eller udgangspunktet til URL-adressen til Office 365 og har en ventetid fra klient til proxy eller udgangspunkt på ca. 3 til 7 millisekunder (afhængigt af mængden af netværkstrafik, du ser i dette tidsrum på dagen), så vil du sikkert vide, at noget er problematisk, hvis dine seneste oprindelige planer for klient til proxy eller udgangspunkt viser en ventetid på 45 millisekunder.

Avancerede metoder

Hvis du gerne vil vide, hvad der sker med dine internetbaserede anmodninger til Office 365, skal du lære at bruge netværksspor. Det er lige meget, hvilke værktøjer du foretrækker til disse spor, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Udviklerdashboardværktøjer eller andre, kan bruges, så længe dette værktøj kan hente og filtrere netværkstrafik. I dette afsnit vises det, at det kan være fordelagtigt at køre mere end ét af disse værktøjer for at få et mere komplet billede af problemet. Når du tester, fungerer nogle af disse værktøjer også som proxy'er i sig selv. Værktøjerne, der bruges i ledsagerartiklen, Plan for fejlfinding af ydeevne for Office 365 inkluderer Netmon 3.4, HTTPWatch eller WireShark.

Det at lave en grundlinje over ydeevnen er den enkle del af denne metode, og mange af trinnene er de samme som ved fejlfinding af ydelsesproblemer. De mere avancerede metoder til oprettelse af oprindelige planer for ydeevnen kræver, at du tager og gemmer netværkssporinger. De fleste af eksemplerne i denne artikel bruger SharePoint Online, men du bør udarbejde en liste over almindelige handlinger på tværs af Office 365-tjenester, du abonnerer på, for at teste og registrere. Her er et eksempel på en grundlinje:

  • Liste over grundlinje for SPO – Trin 1: Gå til startsiden for SPO-webstedet, og en netværkssporing. Gem sporingen.

  • Liste over grundlinje for SPO – Trin 2: Søg efter et ord (f.eks. virksomhedens navn) via Enterprise Search, og lav en netværkssporing. Gem sporingen.

  • Liste over grundlinje for SPO – Trin 3: Overfør en større fil til et SharePoint Online-dokumentbibliotek, og lav en netværkssporing. Gem sporingen.

  • Liste over grundlinje for SPO – Trin 4: Gå til startsiden for OneDrive-webstedet, og lav en netværkssporing. Gem sporingen.

Denne liste bør medtage de vigtigste almindelige handlinger, som brugerne foretager på SharePoint Online. Bemærk, at det sidste trin, for en sporing af OneDrive for Business, bygger på en sammenligning mellem den belastning af SharePoint Online-startsiden (som ofte tilpasses af virksomheder) og startsiden for OneDrive for Business, som sjældent bliver tilpasset. Det er en meget enkel test hvad angår et SharePoint Online-websted, der indlæses langsomt. Du kan oprette en post til denne forskel i din test.

Hvis du står med et ydelsesproblem, vil mange af trinnene være de samme, som når du opretter en grundlinje. Netværkssporing bliver vigtigt, så i det næste kan du læse, hvordan du skal lave de næste vigtige sporinger.

For at løse et ydelsesproblem lige nu skal du lave en sporing på det tidspunkt, hvor du oplever problemet med ydeevnen. Du skal have de rette værktøjer, som kan bruges til at samle logfiler, og du har brug for en handlingsplan, dvs. en liste over fejlfindingshandlinger, du kan foretage for at få den bedste information. Det første, du kan gøre, er at registrere datoen og klokkeslættet for testen, så filerne kan gemmes i en mappe, der afspejler den pågældende tidsindstilling. Dernæst skal du indskrænke til selve problemtrinnene. Dette er de nøjagtige trin, du skal bruge til testen. Glem ikke det grundlæggende: Hvis problemet kun er med Outlook, skal du sørge for at registrere, at problemets adfærd kun sker i én Office 365-tjeneste. Indsnævring af omfanget af dette problem kan hjælpe dig med at fokusere på noget, du kan løse.

Se også

Administrere Office 365-slutpunkter

Udvid dine færdigheder
Gå på opdagelse i kurser
Få nye funktioner først
Bliv Office Insider

Var disse oplysninger nyttige?

Tak for din feedback!

Tak for din feedback! Det lyder, som om det vil kunne hjælpe, hvis du bliver sat i forbindelse med en af vores Office-supportteknikere.

×