Prestandajustering för Office 365 med baslinjer och prestandahistorik

Det finns några enkla sätt att kontrollera prestandan för anslutningen mellan Office 365 och ditt företag, vilka gör det möjligt att upprätta en ungefärlig baslinje för anslutningen. Det kan vara bra att känna till prestandahistoriken för klientdatoranslutningar för att kunna upptäcka och identifiera problem tidigt och förutse eventuella problem.

Den här artikeln är avsedd för den som inte är van att arbeta med prestandaproblem, och hjälper till med vanliga frågor som: Hur vet jag att det jag ser är ett prestandaproblem och inte ett problem med Office 365-tjänsten? Hur kan jag planera för bra prestanda på lång sikt? Hur kan jag hålla ett öga på prestandan? Om din grupp eller dina klienter upplever låg prestanda i Office 365 och du undrar över några av de här frågorna, så är det här rätt artikel för dig.

Viktigt!: Är det prestandaproblem mellan din klient och Office 365 just nu? Följ stegen som beskrivs i planen för prestandafelsökning för Office 365.

Något du bör veta om prestanda i Office 365

Office 365 finns i ett dedikerat Microsoft-nätverk med hög kapacitet, som inte bara övervakas automatiskt utan även manuellt. I Office 365-molnets underhåll ingår finjustering av prestanda och rationalisering där det är möjligt. Eftersom kunderna i Office 365-molnet måste ansluta via Internet arbetar vi ständigt för att finjustera prestandan mellan Office 365-tjänsterna. Prestandaförbättringarna i molnet är ständigt pågående och vår samlade erfarenhet hjälper oss att hålla molnet snabbt och funktionellt. Om du upplever prestandaproblem när du ansluter till Office 365 från din plats är det bäst att inte påbörja ett supportärende som du sedan får vänta på. I stället bör du först undersöka problemet "inifrån och ut". Det innebär att du börjar i ditt nätverk och arbetar dig utåt mot Office 365. Innan du påbörjar ett ärende hos Office 365-supporten kan du samla in data och vidta åtgärder där du utforskar problemet och kanske också kan lösa det.

Viktigt!: Var medveten om kapacitetsplanering och begränsningar i Office 365. Sådan information är viktig när du försöker lösa ett prestandaproblem. Här är en länk till Tjänstbeskrivning av Office 365-plattformen. Det här är ett centralt nav. För varje tjänst som ingår i Office 365 finns en länk som leder till tjänstbeskrivningen. Det innebär att om du till exempel vill se standardbegränsningarna för SharePoint Online så klickar du på Tjänstbeskrivning av SharePoint Online och går till avsnittet om begränsningar för SharePoint Online.

När du påbörjar felsökningen bör du tänka på att prestanda är en glidande skala. Det handlar inte om att uppnå det idealiska värdet och bibehålla det permanent. (Om du har den inställningen kan det bli mycket stressande med uppgifter med hög bandbredd och stort antal användare eller stora datamigreringar, så planera för prestandapåverkan vid sådana tillfällen). Du kan och bör ha en ungefärlig uppfattning om prestandamålen, men det är många variabler som spelar in och prestandan kommer därför att variera. Det ligger helt enkelt i sakens natur.

Felsökning av prestandaproblem handlar inte om att nå specifika mål och konstant ligga på en hög nivå, utan om att förbättra befintliga aktiviteter och ta med alla variabler i beräkningen.

Hur ser då ett prestandaproblem ut?

Först måste du se till att det verkligen handlar om ett prestandaproblem och inte ett problem med själva tjänsten. Prestandaproblem skiljer sig från tjänstproblem i Office 365. Så här kan du skilja dem åt.

Om det är ett problem i själva tjänsten Office 365 kallas det ett tjänstproblem. Då visas röda eller gula ikoner under Aktuell status i administratörscentret i Office 365, och du kanske också upplever försämrad prestanda på klientdatorer som ansluter till Office 365. Om till exempel en röd ikon visas under Aktuell status och Undersöker visas intill Exchange kan du också få samtal från medarbetare med klagomål på att klientpostlådor som använder Exchange Online fungerar dåligt. I sådana fall är det rimligt att anta att Exchange Online-prestandan är låg på grund av tjänstproblem.

Office 365-hälsoinstrumentpanel med alla arbetsbelastningar gröna, förutom Exchange, som visar Tjänsten har återställts.

I det här läget bör du som Office 365-administratör kontrollera Aktuell status och sedan Visa information och historik ofta, så att du håller dig uppdaterad om det underhåll vi utför i systemet. Instrumentpanelen Aktuell status är avsedd att uppdatera dig om ändringar och problem i tjänsten. De anteckningar och förklaringar som finns i statushistoriken admin till admin är avsedd att hjälpa dig fastställa hur du påverkas och hålla dig informerad om det pågående arbetet.

En bild av Office 365-hälsoinstrumentpanelen som förklarar att Exchange Online-tjänsten har återställts och varför.

Ett prestandaproblem är inte ett tjänstproblem även om låg prestanda också kan orsakas av tjänstproblem. Ett prestandaproblem ser ut så här:

  • Ett prestandaproblem uppstår oavsett vad som rapporteras för tjänsten under Aktuell status i admincentret i Office 365.

  • En funktion som normalt är smidig tar lång tid att slutföra eller slutförs inte alls.

  • Du kan replikera problemet eller vet att det kan replikeras om du utför vissa åtgärder i en viss följd.

  • Även om problemet uppstår oregelbundet finns det ändå ett mönster. Du kanske till exempel vet att du klockan 10:00 brukar få samtal från användare som inte har tillförlitlig åtkomst till Office 365, och att samtalen ebbar ut omkring klockan 12:00.

Det låter förmodligen bekant – kanske alltför bekant. När du vet att det är ett prestandaproblem uppstår frågan: "Vad gör jag nu?" I resten av den här artikeln får du hjälp med att avgöra vad du ska göra härnäst.

Definiera och testa prestandaproblem

Prestandaproblem uppstår ofta med tiden, så det kan vara svårt att definiera exakt vad problemet är. För att kunna lösa problemet måste du skapa en bra problemrapport, skaffa dig en god uppfattning om problemets kontext och skapa reproducerbara teståtgärder. Annars kan problemet bli oöverstigligt. Hur kan det te sig? Här är några exempel på problemrapporter som inte tillhandahåller tillräcklig information:

  • Det brukade vara så smidigt att växla från Inkorgen till Kalendern att jag inte märkte det, men nu tar det hela kafferasten. Kan du få det att fungera som förut?

  • Det tar evigheter att ladda upp mina filer till SharePoint Online. Varför går det långsamt på eftermiddagen men snabbt vid andra tillfällen? Kan det inte vara snabbt hela tiden?

Problemrapporterna ovan medför flera stora utmaningar. Det finns många tvetydigheter, till exempel:

  • Det är oklart hur växlingen mellan Inkorgen och Kalendern fungerade på den bärbara datorn förut.

  • När användaren säger "Kan det inte vara snabbt hela tiden", vad menas då med "snabbt"?

  • Hur länge är "evigheter"? Är det flera sekunder eller flera minuter, eller kan användaren gå på lunch och åtgärden slutförs inte förrän tio minuter efter att han eller hon kommit tillbaka?

Det har skrivits utan tanke på att det inte ger administratören och felsökningen någon detaljerad information om problemet, till exempel vid vilken tid problemet uppstod, att användaren arbetar hemifrån och bara upplever långsam växling i hemnätverket, att användaren måste köra andra minneskrävande program på den lokala klientdatorn eller användaren kör ett äldre operativsystem, eller inte har gjort de senaste uppdateringarna.

När användare rapporterar ett prestandaproblem finns det en mängd information att samla in. Informationsinsamling är en del av att undersöka problemet och fastställa dess omfattning. Följande är en grundläggande lista som du kan använda när du samlar in information om prestandaproblemet och dess omfattning. Listan är inte uttömmande men den ger dig något att utgå ifrån när du skapar en egen lista:

  • Vilket datum uppstod problemet, och ungefär vilken tid på dagen eller natten?

  • Vilken typ av klientdator användes och hur ansluts den till nätverket (VPN, kabel, trådlöst)?

  • Arbetade du på distans eller på kontoret?

  • Provade du att utföra åtgärden på en annan dator, och hände samma sak där?

  • Gå steg för steg igenom den process som ger dig problem och skriv ner vad du gör.

  • Hur långsam, i sekunder eller minuter, är prestandan?

  • Var i världen befinner du dig?

Vissa av frågorna är mer uppenbara än andra. De flesta användare förstår att en felsökare behöver de exakta steg som krävs för att återskapa problemet. Hur skulle det annars gå att dokumentera vad som är fel och testa om problemet är löst? Mindre uppenbart är sådant som "Vilket datum och vilken tid uppstod problemet?" och "Var i världen befinner du dig?", information som kan användas tillsammans. Beroende på när användaren arbetade kan några timmars tidsskillnad innebära att underhåll redan pågår i delar av företagets nätverk. Om företaget till exempel har en hybridinstallation, som en hybrid-SharePoint-sökning som kan använda sökindex i både SharePoint Online och en lokal SharePoint Server 2013-instans, kan uppdateringar redan vara på gång i det lokala systemet. Om ditt företag har allting i molnet kan systemunderhåll innebära att nätverksmaskinvara läggs till eller tas bort, att företagsomspännande uppdateringar distribueras eller att ändringar görs i DNS eller annan kärninfrastruktur.

När du felsöker ett prestandaproblem är det lite grann som en brottsplats – du måste vara exakt och vara observant för att kunna dra slutsatser utifrån bevisen. För att kunna göra det måste du skapa en bra problemrapport genom att samla in bevis. Problemrapporten bör innefatta dator, användarens kontext, när problemet uppstod och de exakta åtgärder som exponerade prestandaproblemen. Problemrapporten ska vara och förbli den första sidan i dina anteckningar. När du går igenom problemrapporten igen efter att du har arbetat med lösningen genomför du ett test för att se om dina åtgärder har löst problemet. Det är viktigt att veta när ditt arbete är klart.

Vet du hur prestandan såg ut när den var bra?

Om du har otur finns det ingen som vet det. Ingen har några siffror. Det innebär att ingen kan besvara den enkla frågan "Hur många sekunder tog det att öppna Inkorgen i Office 365?" eller "Hur lång tid tog det när ledningen hade ett Lync Online-möte?", vilket är ett vanligt scenario på många företag.

Det som saknas här är en baslinje för prestanda.

Med en baslinje sätts prestandan in i en kontext. Du bör ta fram en baslinje då och då eller ofta, beroende på vilka behov företaget har. Om det är ett större företag kan din verksamhetsgrupp ta fram baslinjer för den lokala miljön redan nu. Om du till exempel kör korrigeringar på alla Exchange-servrar första måndagen i månaden och på alla SharePoint-servrar tredje måndagen i månaden, har din grupp förmodligen en lista med aktiviteter och scenarier som körs efter korrigeringarna för att verifiera att viktiga funktioner fungerar. Det kan till exempel vara att öppna Inkorgen, klicka på Skicka/ta emot eller se till att mappar uppdateras. I SharePoint kan det vara att gå till webbplatsens huvudsida, gå till företagets söksida eller göra en sökning som returnerar resultat.

Om dina program finns i Office 365 kan du göra några grundläggande baslinjer för den tid (i millisekunder) som det tar från en klientdator i nätverket till en utgående punkt, eller till den punkt där du lämnar nätverket och går ut till Office 365. Här kommer några användbara baslinjer som du kan undersöka och registrera:

  • Identifiera enheterna mellan datorn och din utgående punkt, till exempel din proxyserver.

    • Du måste känna till enheterna så att du har kontexten (IP-adresser, enhetstyper osv.) för eventuella problem som kan uppstå.

    • Proxyservrar är vanliga som utgående punkter, så att du kan titta i din webbläsare och se vilken proxyserver den är inställd att använda.

    • Det finns tredjepartsverktyg som identifierar och kartlägger nätverket, men det säkraste sättet att lära känna dina enheter är att fråga någon i nätverksgruppen.

  • Identifiera din Internet-leverantör (ISP), skriv ned deras kontaktinformation och frågar hur många kretsar och hur mycket bandbredd du har.

  • Inom företaget identifierar du resurser för enheterna mellan klienten och den utgående punkten eller identifierar en nödkontakt som du kan vända dig till vid nätverksproblem.

Här är några baslinjer som kan beräknas med enkla testverktyg:

  • Tid från datorn till den utgående punkten i millisekunder

  • Tid från den utgående punkten till Office 365 i millisekunder

  • Plats i världen för den server som löser URL:erna för Office 365 när du söker

  • Hastigheten på Internet-leverantörs DNS-upplösning i millisekunder, inkonsekvenser i paketmottagning (nätverksjitter), tider för upp- och nedladdning i millisekunder

Om du inte vet hur du gör det finns det mer detaljerad information längre fram i artikeln.

Vad är en baslinje?

Du kommer att se effekterna när det går dåligt, men om du inte har tillgång till prestandadata över en längre tid är det omöjligt att sätta i kontext hur dåligt det hade kunnat bli och när. Utan en baslinje går du alltså miste om den viktigaste ledtråden till pusslet: bilden på kartongen. För felsökning av prestandaproblem behövs en jämförelsepunkt. Enkla prestandabaslinjer är inte svåra att göra. Din grupp kan få i uppdrag att genomföra dem enligt ett schema. Anta till exempel att din anslutning ser ut så här:

En grundläggande nätverksbild med klienten, proxy och Office 365-molnet.

Du har kollat med nätverksgruppen och fått reda på att företagets anslutningar till Internet sker via en proxyserver som hanterar alla förfrågningar som klientdatorn skickar till molnet. I det här fallet bör du rita en förenklad version av anslutningen som innehåller alla mellanliggande enheter. Nu kan du infoga verktyg som du kan använda för att testa prestanda mellan klienten, den utgående punkten där du lämnar ditt nätverk och går ut på Internet, och Office 365-molnet.

Grundläggande nätverk med klient, proxy och moln samt verktygsförslag, PSPing, TraceTCP och nätverksspårningar.

Alternativen är Enkel och Avancerad efter hur mycket kunskap du behöver för att hitta prestandadata. Nätverksspårning tar lång tid jämfört med att köra verktyg på kommandoraden som PsPing och TraceTCP. De här två verktygen används eftersom de inte använder ICMP-paket, som blockeras av Office 365, och eftersom de visar den tid (i millisekunder) som det tar att lämna klientdatorn eller proxyservern (om du har tillgång till den) och nå Office 365. Varje enskilt hopp från en dator till en annan har ett tidsvärde, vilket passar utmärkt för baslinjer! Kommandoverktygen låter dig även lägga till ett portnummer i kommandot, vilket är användbart eftersom Office 365 kommunicerar via port 443, samma port som används av SSL (Secure Sockets Layer) och TLS (Transport Layer Security). Det finns även andra verktyg från tredje part som kan vara bättre lösningar för din situation. Microsoft har inte stöd för alla verktyg, så om du av någon anledning inte kan få PsPing och TraceTCP att fungera kan du prova nätverksspårning med hjälp av ett verktyg som Netmon.

Du kan göra en baslinje innan arbetsdagens början, en gång till under kraftig användning och sedan igen efter kontorstid. Till slut kan du ha en mappstruktur som ser ut ungefär så här:

Grafiken föreslår ett sätt att organisera prestandadata i mappar.

Du bör också ha ett specifikt sätt att benämna dina filer. Här är några exempel:

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerf

  • 08_feb_2015_0830_PerfBaseline_GoodPerf

Det finns många olika sätt att göra det här, men formatet <dateTime><what's happening in the test> är en bra början. Om du använder det här sättet konsekvent underlättar det betydligt när du ska felsöka problem senare. Du kommer exempelvis att kunna säga ”jag gjorde två spårningar den 8 februari, en visade bra prestanda och en visade dålig, så vi kan jämföra dem”. Det här är oerhört användbart för felsökning.

Det är viktigt att ordna alla baslinjer på ett organiserat sätt. I det här exemplet resulterade den enkla metoden i tre utdata från kommandoraden och resultatet sparades som skärmbilder, men om du vill kan du låta nätverket samla in filer i stället. Använd den metod som passar dig bäst. Lagra dina gjorda baslinjer och ha dem som referens när du märker ändringar i online-tjänstens beteende.

Varför är det bra att samla in prestandadata under ett pilottest?

Det är bäst att börja skapa baslinjer redan i pilotversionen av Office 365-tjänsten. Office kan ha tusentals användare, hundratusentals, eller bara fem, men även med ett litet antal användare kan du utföra tester för att mäta svängningar i prestanda. För stora företag kan ett representativt urval av flera hundra användare av pilotversionen av Office 365 projiceras utåt på flera tusentals så att du vet var problem kan uppstå innan de uppstår.

För små företag där alla användare börjar använda tjänsten samtidigt och det inte finns någon pilotversion kan du behålla prestandamätningar så att du har data att visa för de som ska felsöka problem. Om du till exempel helt plötsligt märker att du kan gå ett varv runt byggnaden under den tid det tar att ladda upp en medelstor bild när det brukade ske mycket snabbt.

Hur du hämtar baslinjer

För alla felsökningsplaner behöver du som minst identifiera följande saker:

  • Den klientdator du använder (typ av dator eller enhet, IP-adress samt de åtgärder som orsakade problemet)

  • Klientdatorns fysiska plats (till exempel om användaren har en VPN-anslutning till nätverket, arbetar på distans eller i företagets intranät)

  • Den utgående punkt som klientdatorn använder från nätverket (den punkt där trafiken lämnar företaget och går till en Internetleverantör eller Internet)

Du kan få din nätverkslayout från nätverksadministratören. Om du har ett litet nätverk kan du titta på enheterna som ansluter dig till Internet och ringa Internet-leverantören om du har frågor om layouten. Gör en bild av den färdiga layouten för att ha som referens.

Det här avsnittet är uppdelat i enkla kommandoradsbaserade verktyg och metoder, och mer avancerade verktyg. Först går vi in på enkla metoder. Om du däremot har prestandaproblem just nu ska du gå till avancerade metoder och använda handlingsplanen för prestandafelsökning.

Enkla metoder

Syftet med de enkla metoderna är att lära dig att göra, förstå och korrekt lagra enkla prestandabaslinjer så att du får information om Office 365-prestanda. Här är ett mycket enkelt diagram som du har sett förut:

Grundläggande nätverk med klient, proxy och moln samt verktygsförslag, PSPing, TraceTCP och nätverksspårningar.

Meddelanden: 

  • I den här skärmbilden syns TraceTCP, som är ett användbart verktyg för att visa (i millisekunder) hur lång tid en begäran tar att behandla, och hur många nätverkshopp eller anslutningar från en dator till nästa som det tar för en begäran att nå sitt mål. TraceTCP kan även visa namnen på servrar som används under hopp, vilket kan vara användbart för felsökare i Microsoft Office 365-supporten.

  • Vissa TraceTCP-kommandon är mycket enkla, till exempel:

  • tracetcp.exe outlook.office365.com:443

  • Kom ihåg att ha med portnumret i kommandot!

  • TraceTCP kan laddas ned kostnadsfritt, men det kräver Wincap. Wincap är också ett verktyg som används och installeras av Netmon. Vi använder även Netmon i avsnittet om avancerade metoder.

Om du har flera kontor behöver du ha en uppsättning data från en klient i var och en av de platserna. Det här testet mäter svarstid, vilket i det här fallet är ett numeriskt värde som beskriver tiden det tar från det att en klient skickar en begäran till Office 365 tills det att Office 365 svarar på begäran. Testet börjar på en klientdator i din domän och mäter en resa från ditt nätverk, ut genom en port, över Internet till Office 365 och hela vägen tillbaka.

Det finns några olika sätt att hantera den utgående punkten, i det här fallet proxyservern. Du kan spåra från 1 till 2 och sedan 2 till 3 och sedan addera talen i millisekunder för att få en totalsumma vid kanten av nätverket. Du kan också konfigurera anslutningen till att förbigå proxyservern för Office 365-adresser. I ett större nätverk med en brandvägg, omvänd proxyserver eller en kombination av de två, kan du behöva göra undantag för proxyservern som gör att trafik kan passera för många URL:er. Listan över slutpunkter som används av Office 365 finns i Office 365 URL:er och IP-adressintervall. Om du har en autentiserande proxy kan du börja med att testa undantag för följande:

  • Portarna 80 och 443

  • TCP och HTTP

  • Utgående anslutningar till någon av dessa URL:er:

  • * .microsoftonline.com

  • * .microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • * .lync.com

  • osub.microsoft.com

Alla användare behöver kunna komma åt de här adresserna utan någon inblandning från proxy eller autentisering. I mindre nätverk bör du lägga till adresserna i undantagslistan för proxyadresser i din webbläsare.

För att lägga till dem i undantagslistan för proxyadresser i Internet Explorer går du till Verktyg > Internetalternativ > Anslutningar > LAN-inställningar > Avancerat. På fliken avancerat hittar du även din proxyserver och proxyserverport. Du kan behöva markera kryssrutan Använd en proxyserver för nätverket för att få åtkomst till knappen Avancerat. Du bör kontrollera att Använd inte någon proxyserver för lokala adresser är markerad. När du klickar på Avancerat ser du en textruta där du kan ange undantag. Separera URL:en ovan med semikolon, till exempel:

*.microsoftonline.com; *.sharepoint.com

När du kringgår din proxy bör du kunna använda ping eller PsPing direkt på en Office 365-URL. Nästa steg är att testa att pinga outlook.office365.com. Eller, om du använder PsPing eller ett annat verktyg där du kan ange ett portnummer i kommandot, så kan du utföra en PsPing på portal.microsoftonline.com:443 för att se den genomsnittliga tiden dit och tillbaka i millisekunder.

Tidsfördröjning för svar, eller RTT (Round-trip time), är ett värde som innebär den tid det tar att skicka en HTTP-begäran till en server som outlook.office365.com och få ett svar som bekräftar att servern vet att du gjorde det. Ibland används förkortningen RTT. Det bör vara en relativt kort tid.

För att kunna göra det här testet måste du använda PSPing eller ett annat verktyg som inte använder ICMP-paket som blockeras av Office 365.

Använda PsPing för att få en tidsfördröjning för svar (i millisekunder) direkt från en Office 365-URL

  1. Kör en upphöjd kommandotolk genom att utföra följande steg:

    1. Klicka på Start.

    2. I rutan Starta sökningen skriver du cmd och sedan trycker du på Ctrl+Skift+Retur.

    3. Om dialogrutan Kontroll av användarkonto visas bekräftar du att den visar vad du vill och sedan klickar du på Fortsätt.

  2. Navigera till den mapp där verktyget (i det här fallet PsPing) är installerat och testa följande Office 365-URL:er:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      PSPing-kommandot till microsoft-my.sharepoint.com-port 443.

Se till att inkludera portnumret 443. Kom ihåg att Office 365 körs på en krypterad kanal. Om du gör en PsPing utan portnummer kommer din begäran att misslyckas. När du har pingat en kort lista letar du efter den genomsnittliga tiden i millisekunder (ms). Det är den du vill spara!

Illustration som visar en bild av klienten för proxy-PSPing med en tidsfördröjning på 2,8 millisekunder.

Om du inte är bekant med att kringgå proxy och föredrar att ta ett steg i taget måste du först ta reda på namnet på din proxyserver. I Internet Explorer går du till Verktyg > Internetalternativ > Anslutningar > LAN-inställningar > Avancerat. Du kan se din proxyserver på fliken Avancerat. Pinga proxyservern via kommandotolken genom att göra följande:

Pinga proxyservern och få en tidsfördröjning för svar i millisekunder för steg 1 till 2

  1. Kör en upphöjd kommandotolk genom att utföra följande steg:

    1. Klicka på Start.

    2. I rutan Starta sökningen skriver du cmd och sedan trycker du på Ctrl+Skift+Retur.

    3. Om dialogrutan Kontroll av användarkonto visas bekräftar du att den visar vad du vill och sedan klickar du på Fortsätt.

  2. Skriv ping <namnet på proxyservern webbläsaren använder, eller IP-adressen till proxyservern> och tryck sedan på RETUR. Om du har PsPing eller något annat verktyg installerat kan du välja att använda det verktyget i stället.

    Ditt kommando kan se ut som något av de här exemplen:

    • 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 spårningen slutar att skicka testpaket kommer du att få en liten sammanfattning som visar ett medelvärde i millisekunder, vilket är värdet som du är ute efter. Ta en skärmbild av texten och spara den enligt ditt sätt att namnge filer. Vid det här laget kan det också vara bra att fylla i värdet i diagrammet.

Du kanske har gjort en spårning tidigt på morgonen och din klient kan komma till proxyn (eller den utgående servern till Internet) snabbt. I det här fallet kan talen se ut så här:

Bild som visar tidsfördröjning för svar från en klient till en proxy på 2,8 millisekunder.

Om klientdatorn är en av få med tillgång till proxyservern (eller den utgående servern) kan du köra nästa del av testet genom att fjärransluta till den datorn och köra kommandotolken för att göra en PsPing på en Office 365-URL därifrån. Om du inte har tillgång till den datorn kan du kontakta nätverkshjälpen för att få hjälp med nästa del av testet och få exakta värden på så sätt. Om det inte är möjligt kan du göra en PsPing för den aktuella Office 365-URL:en och jämföra den med PsPing- eller Ping-tiden för din proxyserver.

Om det tar till exempel 51,84 millisekunder från klienten till Office 365:s URL och det tar 2,8 millisekunder från klienten till proxy (eller den utgående punkten) tar det 49,04 millisekunder från den utgående punkten till Office 365. På samma sätt, om PsPing tar 12,25 millisekunder från klienten till proxy mitt på dagen och 62,01 millisekunder från klienten till Office 365 URL är det genomsnittliga värdet för proxys utgående punkt till Office 365:s URL 49,76 millisekunder.

Ytterligare bild som visar ping i millisekunder från klienten till proxy bredvid klienten till Office 365, så att värdena kan subtraheras.

Vad gäller felsökning kan du eventuellt hitta något intressant bara genom att hålla kvar dessa baslinjer. Om du till exempel i allmänhet finner att det är omkring 40 till 59 millisekunders latens från proxys utgående punkt till Office 365 URL och att latens från klient till proxy eller utgående punkt är ca 3 till 7 millisekunder (beroende på hur mycket nätverkstrafik som förekommer den tiden på dagen) så vet du att något är problematiskt om de senaste tre baslinjerna för klient till proxy eller utgående punkt uppvisar en latens på 45 millisekunder.

Avancerade metoder

Om du verkligen vill veta vad som händer med dina Internet-förfrågningar till Office 365 måste du bekanta dig med nätverksspårningar. Det spelar ingen roll vilket verktyg du föredrar för dessa spårningar, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard-verktyget eller något annat, så länge verktyget kan spela in och filtrera nätverkstrafik. Du kommer att märka i det här avsnittet att det är fördelaktigt att köra fler än ett av de här verktygen för att få en mer fullständig bild av problemet. När du testar fungerar några av dessa verktyg själva som proxy. Bland de verktyg som används i den relaterade artikeln Prestandafelsökningsplan för Office 365 finns Netmon 3.4, HTTPWatch och WireShark.

Att skapa en prestandabaslinje är den enkla delen av denna metod och många av stegen är desamma som när du felsöker ett prestandaproblem. De mer avancerade metoderna för att skapa baslinjer för prestanda kräver du att gör och lagrar nätverksspårningar. I de flesta av exemplen i den här artikeln används SharePoint Online, men du bör skapa en lista med vanliga åtgärder med alla Office 365-tjänster som du abonnerar på för att testa och spela in. Här är ett exempel på en baslinje:

  • Baslinjelista för SPO - Steg 1: Besök startsidan för SPO-webbplatsen och gör en nätverksspårning. Spara spårningen.

  • Baslinjelista för SPO - Steg 2: Sök efter en term (till exempel ditt företags namn) via Enterprise Search och gör en nätverksspårning. Spara spårningen.

  • Baslinjelista för SPO - Steg 3: Överför en stor fil till ett SharePoint Online-dokumentbibliotek och gör en nätverksspårning. Spara spårningen.

  • Baslinjelista för SPO - Steg 4: Besök startsidan för OneDrive-webbplatsen och gör en nätverksspårning. Spara spårningen.

Den här listan ska innehålla de viktigaste vanliga åtgärder som användare vidtar mot SharePoint Online. Observera att det sista steget, att spåra att gå till OneDrive for Business, inbegriper en jämförelse mellan laddning av SharePoint Onlines startsida (som ofta anpassas för företag) och OneDrive for Business startsida, som sällan anpassas. Det här är ett väldigt grundläggande test när det gäller en SharePoint Online-webbplats som laddar in långsamt. Du kan bygga in ett notering av den här skillnaden i din testning.

Om du befinner dig mitt i ett prestandaproblem blir många av stegen samma som när du gör en baslinje. Nätverkspårningar blir viktiga, så vi ska behandla härnäst hur de viktiga spårningarna ska göras.

För att ta itu med ett prestandaproblem precis nu måste du hålla på att göra en spårning vid den tidpunkt då du upplever prestandaproblemet. Du måste ha rätt verktyg tillgängliga för att samla in loggar och du behöver en handlingsplan, dvs. en lista med felsökningsåtgärder att vidta för att samla in den bästa möjliga informationen. Det första man måste göra är registrera datum och tid för testet så att filer kan sparas i en mapp som avspeglar den tiden. Begränsa härnäst till själva problemstegen. Det är precis dessa steg som du kommer att använda för att testa. Glöm inte grunderna: om problemet bara uppstår med Outlook, se till att notera att problembeteendet endast inträffar i en enda Office 365-tjänst. Om du begränsar problemets omfattning hjälper det dig att fokusera på något som går att lösa.

Mer information finns i

Hantera Office 365-slutpunkter

Utöka dina kunskaper
Utforska utbildning
Få nya funktioner först
Anslut till Office Insiders

Hade du nytta av den här informationen?

Tack för din feedback!

Tack för din feedback! Det låter som att det kan vara bra att koppla dig till en av våra Office-supportrepresentanter.

×