Prestandajustering för Office 365 med baslinjer och prestandahistorik

Det finns några enkla sätt att kontrollera anslutningsprestanda mellan Office 365 och ditt företag så att du kan upprätta en ungefärlig baslinje för anslutningen. Att känna till prestandahistoriken för klientdatoranslutningarna kan hjälpa dig att identifiera nya problem tidigt, identifiera och förutsäga problem.

Om du inte är van att arbeta med prestandaproblem är den här artikeln utformad för att hjälpa dig att överväga några vanliga frågor. Hur vet du att problemet du ser är ett prestandaproblem och inte en Office 365 tjänstincident? Hur kan du planera för bra prestanda på lång sikt? Hur kan du hålla ett öga på prestanda? Om ditt team eller klienter ser långsamma prestanda när de använder Office 365, och du undrar över någon av dessa frågor, kan du läsa vidare.

Viktigt

Har du prestandaproblem mellan klienten och Office 365 just nu? Följ stegen som beskrivs i felsökningsplanen för prestanda för Office 365.

Något du bör känna till om Office 365 prestanda

Office 365 finns i ett dedikerade Microsoft-nätverk med hög kapacitet som övervakas av automatisering och verkliga människor. En del av att underhålla Office 365 molnet är prestandajustering och effektivisering där det är möjligt. Eftersom klienter i det Office 365 molnet måste ansluta via Internet, finns det fortlöpande arbete med att finjustera prestandan för Office 365 tjänster också.

Prestandaförbättringar slutar aldrig riktigt i molnet, så inte heller erfarenhet av att hålla molnet hälsosamt och snabbt. Om du har problem med att ansluta från din plats till Office 365 är det bäst att inte börja med eller vänta på ett supportärende. I stället bör du börja undersöka problemet inifrån och ut. Det vill sägs börja i nätverket och arbeta dig ut för att Office 365. Innan du öppnar ett ärende med supporten kan du samla in data och vidta åtgärder som utforskar och kan lösa problemet.

Viktigt

Var medveten om kapacitetsplanering och begränsningar i Office 365. Med den här informationen hamnar du före kurvan när du försöker lösa ett prestandaproblem. Här är en länk till tjänstbeskrivningarna för Microsoft 365 och Office 365. Det här är en central hubb och alla tjänster som erbjuds av Office 365 har en länk som går till deras egna tjänstbeskrivningar härifrån. Det innebär att om du till exempel behöver se standardgränserna för SharePoint Online klickar du på SharePoint Online-tjänstbeskrivning och letar upp avsnittet Begränsningar för SharePoint Online.

Se till att du går in i felsökningen med insikten att prestanda är en glidande skala. Det handlar inte om att uppnå ett idealiserat värde och underhålla det permanent. Tillfälliga uppgifter med hög bandbredd som att registrera ett stort antal användare eller utföra stora datamigreringar kommer att vara stressande, så planera för prestandapåverkan då. Du bör ha en ungefärlig uppfattning om dina prestandamål, men många variabler spelar in i prestanda, så prestanda varierar.

Prestandafelsökning handlar inte om att uppfylla specifika mål och upprätthålla dessa siffror på obestämd tid, det handlar om att förbättra befintliga aktiviteter med tanke på alla variabler.

Hur ser ett prestandaproblem ut?

Först måste du se till att det du upplever verkligen är ett prestandaproblem och inte en tjänstincident. Ett prestandaproblem skiljer sig från en tjänstincident i Office 365. Så här skiljer du dem åt.

Tjänstincidenter inträffar när själva Office 365-tjänsten har problem. Du kan se röda eller gula ikoner under Aktuell hälsa i Administrationscenter för Microsoft 365. Du kanske märker att prestandan på klientdatorer som ansluter till Office 365 är långsam. Om Aktuell hälsa till exempel rapporterar en röd ikon och du ser Undersöka bredvid Exchange kan du även få samtal från personer i organisationen som klagar på att klientpostlådor med Exchange Online är långsamma. I så fall är det rimligt att anta att din Exchange Online prestanda har drabbats av tjänstproblem.

Nu bör du, Office 365 administratör, kontrollera Aktuell hälsa och sedan Visa information och historik, ofta, för att hålla dig uppdaterad om underhåll i systemet. Instrumentpanelen För aktuell hälsa har gjorts för att uppdatera dig om ändringar i och problem i tjänsten. Anteckningarna och förklaringarna som skrivits till hälsohistoriken, administratör till administratör, finns där för att hjälpa dig att mäta och hålla dig uppdaterad om pågående arbete.

Ett prestandaproblem är inte en tjänstincident, även om incidenter kan orsaka långsamma prestanda. Ett prestandaproblem ser ut så här:

• Ett prestandaproblem uppstår oavsett vad administrationscentret Aktuell hälsa rapporterar för tjänsten.

• Ett beteende som används för att flöda tar lång tid att slutföra eller aldrig slutföra.

• Du kan också replikera problemet eller veta att det kommer att inträffa om du utför rätt serie steg.

• Om problemet är tillfälligt kan det fortfarande finnas ett mönster. Du vet till exempel att du senast kl. 10:00 har samtal från användare som inte alltid kan komma åt Office 365. Samtalen avslutas vid lunchtid.

Den här listan låter förmodligen bekant; kanske för bekant. När du är medveten om att det är ett prestandaproblem blir frågan "Vad gör du härnäst?" Resten av den här artikeln hjälper dig att avgöra exakt detta.

Definiera och testa prestandaproblemet

Prestandaproblem uppstår ofta över tid, så det kan vara svårt att definiera det faktiska problemet. Skapa en bra problembeskrivning med en bra uppfattning om problemkontexten och sedan måste du utföra upprepningsbara teststeg. Här följer några exempel på probleminstruktioner som inte ger tillräckligt med information:

• Att växla från min inkorg till min kalender brukade vara något jag inte märkte, och nu är det en kaffepaus. Kan du få det att bete sig som det brukade?

• Det tar för alltid att ladda upp mina filer till SharePoint Online. Varför är det långsamt på eftermiddagen, men någon annan gång är det snabbt? Kan det inte bara gå snabbt?

Det finns flera stora utmaningar som probleminstruktionerna ovan medför. Mer specifikt för många tvetydigheter att hantera. Till exempel:

• Det är oklart hur växling mellan Inbox och Calendar brukade agera på den bärbara datorn.

• Vad är "snabbt" när användaren säger "Kan det inte bara gå snabbt"?

• Hur länge är "för evigt"? Är det flera sekunder? Eller många minuter? Eller kan användaren ta lunch och åtgärden skulle slutföras 10 minuter efter att de kom tillbaka?

Administratören och felsökaren kan inte känna till information om problemet från allmänna instruktioner som dessa. De vet till exempel inte när problemet började hända. Felsökaren kanske inte vet att användaren arbetar hemifrån och ser bara långsamma växlingar i hemnätverket. Eller att användaren kör andra RAM-intensiva program på den lokala klienten. Administratörer kanske inte vet att användaren kör ett äldre operativsystem eller inte har kört de senaste uppdateringarna.

När användare rapporterar ett prestandaproblem finns det mycket information att samla in. Att hämta och registrera information kallas omfång för problemet. Här är en grundläggande omfångslista som du kan använda för att samla in information om prestandaproblem. Den här listan är inte fullständig, men det är en plats att börja på:

• Vilket datum inträffade problemet och vid vilken tid på dagen eller natten?

• Vilken typ av klientdator använde du och hur ansluter den till företagsnätverket (VPN, kabelanslutet, trådlöst)?

• Jobbade du på distans eller var du på kontoret?

• Provade du samma åtgärder på en annan dator och såg samma beteende?

• Gå igenom de steg som ger dig problem så att du kan skriva de åtgärder som du utför.

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

• Var i världen finns du?

Vissa av dessa frågor är mer uppenbara än andra. De flesta kommer att förstå att en felsökare behöver de exakta stegen för att återskapa problemet. Hur kan du i annat fall registrera vad som är fel och hur kan du annars testa om problemet är åtgärdat? Mindre uppenbara är saker som "Vilket datum och tid såg du problemet?", och "Var i världen finns du?", information som kan användas tillsammans. Beroende på när användaren arbetade kan en tidsskillnad på några timmar innebära att underhåll redan pågår på delar av företagets nätverk. Företaget har till exempel en hybridimplementering, till exempel en SharePoint-hybridsökning, som kan köra frågor mot sökindex i både SharePoint Online och en lokal SharePoint Server 2013-instans. Uppdateringar kan vara på gång i den lokala servergruppen. Om ditt företag är helt i molnet kan systemunderhåll omfatta att lägga till eller ta bort nätverksmaskinvara, distribuera uppdateringar som är företagsomfattande eller göra ändringar i DNS eller annan kärninfrastruktur.

När du felsöker ett prestandaproblem är det lite som en brottsplats, du måste vara exakt och uppmärksam för att dra några slutsatser från bevisen. För att göra detta måste du få en bra problembeskrivning genom att samla in bevis. Den bör innehålla datorns kontext, användarens kontext, när problemet började och de exakta steg som exponerade prestandaproblemet. Den här problembeskrivningen ska vara och förbli den översta sidan i dina anteckningar. Genom att gå igenom problembeskrivningen igen när du arbetar med lösningen vidtar du stegen för att testa och bevisa om de åtgärder du vidtar har löst problemet. Detta är viktigt för att veta när ditt arbete, där, är gjort.

Vet du hur prestanda brukade se ut när det var bra?

Om du har otur, vet ingen. Ingen hade siffror. Det innebär att ingen kan svara på den enkla frågan "Om hur många sekunder tog det att ta upp en inkorg i Office 365?", eller "Hur lång tid tog det när cheferna hade ett Lync Online-möte?", vilket är ett vanligt scenario för många företag.

Vad saknas här är en prestandabaslinje?

Baslinjer ger dig en kontext för dina prestanda. Du bör ta en baslinje ibland till ofta, beroende på företagets behov. Om du är ett större företag kan ditt driftteam redan ha baslinjer för din lokala miljö. Om du till exempel korrigerar alla Exchange-servrar den första måndagen i månaden och alla SharePoint-servrar den tredje måndagen har ditt driftteam förmodligen en lista över uppgifter och scenarier som körs efter korrigeringen, för att bevisa att kritiska funktioner fungerar. Du kan till exempel öppna Inkorgen, klicka på Skicka/ta emot och se till att mapparna uppdateras, eller i SharePoint bläddra på webbplatsens huvudsida, gå till sidan Företagssökning och göra en sökning som returnerar resultat.

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

• Identifiera enheterna mellan klientdatorn och din utgående punkt, till exempel proxyservern.

  • Du måste känna till dina enheter så att du har kontext (IP-adresser, typ av enhet, etc.) för prestandaproblem som uppstår.

  • Proxyservrar är vanliga utgående punkter, så du kan kontrollera webbläsaren för att se vilken proxyserver den är inställd på att använda, om någon.

  • Det finns verktyg från tredje part som kan identifiera och mappa ditt nätverk, men det säkraste sättet att veta dina enheter är att fråga en medlem i ditt nätverksteam.

• Identifiera internetleverantören (ISP), skriv ned deras kontaktinformation och fråga hur många kretsar du har.

• I företaget kan du identifiera resurser för enheterna mellan klienten och utgångspunkten eller identifiera en nödsituationskontakt som du kan prata med om nätverksproblem.

Här är några baslinjer som enkel testning med verktyg kan beräkna åt dig:

• Tid från klientdatorn till din utgående punkt i millisekunder

• Tid från din utgående punkt till Office 365 i millisekunder

• Plats i servervärlden som löser URL:erna för Office 365 när du bläddrar

• Hastigheten för ISP:ns DNS-matchning i millisekunder, inkonsekvenser i paketinhämtning (nätverks jitter), uppladdnings- och nedladdningstider i millisekunder

Om du inte är bekant med hur du utför de här stegen går vi in mer i detalj i den här artikeln.

Vad är en baslinje?

Du kommer att känna till effekten när det går dåligt, men om du inte känner till dina historiska prestandadata går det inte att ha någon kontext för hur illa det kan ha blivit och när. Så utan en baslinje saknar du den viktigaste ledtråden för att lösa pusslet: bilden på pussellådan. I prestandafelsökning behöver du en jämförelsepunkt. Enkla prestandabaslinjer är inte svåra att ta. Ditt driftteam kan få i uppgift att utföra dessa enligt ett schema. Anta till exempel att anslutningen ser ut så här:

Det innebär att du har kontrollerat med nätverksteamet och fått reda på att du lämnar företaget för Internet via en proxyserver och att proxyn hanterar alla begäranden som klientdatorn skickar till molnet. I det här fallet bör du rita en förenklad version av anslutningen som visar en lista över alla mellanliggande enheter. Infoga nu verktyg som du kan använda för att testa prestanda mellan klienten, utgående punkt (där du lämnar nätverket för Internet) och Office 365 molnet.

Alternativen visas som Enkla och Avancerade på grund av den mängd expertis du behöver för att hitta prestandadata. En nätverksspårning tar mycket tid jämfört med att köra kommandoradsverktyg som PsPing och TraceTCP. Dessa två kommandoradsverktyg valdes eftersom de inte använder ICMP-paket, som blockeras av Office 365, och eftersom de ger den tid i millisekunder som det tar att lämna klientdatorn eller proxyservern (om du har åtkomst) och anländer till Office 365. Varje enskilt hopp från en dator till en annan får ett tidsvärde, och det är bra för baslinjer! Lika viktigt är att dessa kommandoradsverktyg gör att du kan lägga till ett portnummer i kommandot. Detta är användbart eftersom Office 365 kommunicerar via port 443, som är porten som används av Secure Sockets Layer and Transport Layer Security (SSL och TLS). Andra verktyg från tredje part kan dock vara bättre lösningar för din situation. Microsoft stöder inte alla dessa verktyg, så om du av någon anledning inte kan få PsPing och TraceTCP att fungera går du vidare till en nätverksspårning med ett verktyg som Netmon.

Du kan ta en baslinje före kontorstid, igen under tung användning och sedan igen efter timmar. Det innebär att du kan ha en mappstruktur som ser ut ungefär så här i slutändan:

Du bör också välja en namngivningskonvention för 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

• Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

Det finns många olika sätt att göra detta, men att använda formatet <dateTime><vad som händer i testet> är ett bra ställe att börja på. Att vara noggrann med detta hjälper mycket när du försöker felsöka problem senare. Senare kommer du att kunna säga "Jag tog två spår den 8 februari, en visade bra prestanda och en visade dålig, så vi kan jämföra dem". Det här är användbart för felsökning.

Du måste ha ett organiserat sätt att behålla dina historiska baslinjer. I det här exemplet skapade de enkla metoderna tre kommandoradsutdata och resultaten samlades in som skärmbilder, men du kan ha nätverksavbildningsfiler i stället. Använd den metod som passar dig bäst. Lagra dina historiska baslinjer och referera till dem på platser där du märker ändringar i beteendet för onlinetjänster.

Varför samla in prestandadata under en pilot?

Det finns ingen bättre tid att börja göra baslinjer än under en pilot av Office 365-tjänsten. Ditt kontor kan ha tusentals användare, hundratusentals eller fem, men även med några få användare kan du utföra tester för att mäta variationer i prestanda. När det gäller ett stort företag kan ett representativt urval av flera hundra användare som testar Office 365 projiceras utåt till flera tusen så att du vet var problem kan uppstå innan de inträffar.

När det gäller ett litet företag, där ombordstigning innebär att alla användare går till tjänsten samtidigt och det inte finns någon pilot, behåller du prestandamått så att du har data att visa för alla som kan behöva felsöka en åtgärd som fungerar dåligt. Om du till exempel märker att du helt plötsligt kan gå runt i byggnaden under den tid det tar att ladda upp en medelstor grafik där den brukade ske snabbt.

Samla in baslinjer

För alla felsökningsplaner måste du minst identifiera dessa saker:

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

• Där klientdatorn finns i världen (till exempel om den här användaren använder ett VPN till nätverket, arbetar via fjärranslutning eller på företagets intranät)

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

Du kan ta reda på nätverkslayouten från nätverksadministratören. Om du är i ett litet nätverk kan du ta en titt på de enheter som ansluter dig till Internet och ringa internetleverantören om du har frågor om layouten. Skapa en bild av den slutliga layouten för referensen.

Det här avsnittet är indelat i enkla kommandoradsverktyg och -metoder samt mer avancerade verktygsalternativ. Vi tar först upp enkla metoder. Men om du har ett prestandaproblem just nu bör du gå vidare till avancerade metoder och prova åtgärdsplanen för prestandafelsökning.

Enkla metoder

Målet med dessa enkla metoder är att lära sig att ta, förstå och korrekt lagra enkla prestandabaslinjer över tid så att du informeras om Office 365 prestanda. Här är det enkla diagrammet för enkelt, som du har sett tidigare:

Obs!

TraceTCP ingår i den här skärmbilden eftersom det är ett användbart verktyg för att i millisekunder visa hur lång tid en begäran tar att bearbeta och hur många nätverkshopp eller anslutningar från en dator till nästa som begäran tar för att nå ett mål. TraceTCP kan också ge namnen på servrar som används under hopp, vilket kan vara användbart för en Microsoft Office 365 felsökare i supporten. > TraceTCP-kommandon kan vara mycket enkla, till exempel: >tracetcp.exe outlook.office365.com:443> Kom ihåg att inkludera portnumret i kommandot! >TraceTCP är en kostnadsfri nedladdning, men förlitar sig på Wincap. Wincap är ett verktyg som också används och installeras av Netmon. Vi använder även Netmon i avsnittet avancerade metoder.

Om du har flera kontor måste du även behålla en uppsättning data från en klient på var och en av dessa platser. Det här testet mäter svarstiden, vilket i det här fallet är ett talvärde som beskriver hur lång tid det går mellan att en klient skickar en begäran till Office 365 och Office 365 svarar på begäran. Testningen kommer från din domän på en klientdator och ser ut att mäta en tur och retur-resa inifrån nätverket, ut via en utgående punkt, via Internet för att Office 365 och tillbaka.

Det finns några sätt att hantera utgående punkt, i det här fallet proxyservern. Du kan antingen spåra från 1 till 2 och sedan 2 till 3 och sedan lägga till siffrorna i millisekunder för att få en slutlig summa till nätverksgränsen. Eller så kan du konfigurera anslutningen så att den kringgår proxyn för Office 365 adresser. I ett större nätverk med en brandvägg, omvänd proxy eller någon kombination av de två kan du behöva göra undantag på proxyservern som tillåter att trafik skickas för många URL:er. En lista över slutpunkter som används av Office 365 finns i Office 365 URL:er och IP-adressintervall. Om du har en autentiseringsproxy börjar du med att testa undantag för följande:

• Portarna 80 och 443

• TCP och HTTPs

• Anslutningar som är utgående till någon av dessa URL:er:

• *.microsoftonline.com

• *.microsoftonline-p.com

• *.sharepoint.com

• *.outlook.com

• *.lync.com

• osub.microsoft.com

Alla användare måste få komma till dessa adresser utan proxyinterferens eller autentisering. I ett mindre nätverk bör du lägga till dessa i listan över förbikoppling av proxy i webbläsaren.

Om du vill lägga till dessa i listan över förbikoppling av proxy i Internet Explorer går du till Verktyg>Internetalternativ>Lan-inställningar>>Avancerade anslutningar. Den avancerade fliken är också där du hittar proxyservern och proxyserverporten. Du kan behöva klicka på kryssrutan Använd en proxyserver för ditt LAN för att få åtkomst till knappen Avancerat . Du bör kontrollera att Kringgå proxyservern för lokala adresser är markerad. När du klickar på Avancerat visas en textruta där du kan ange undantag. Avgränsa jokertecken-URL:erna som anges ovan med semikolon, till exempel:

*.microsoftonline.com; *.sharepoint.com

När du kringgår proxyn bör du kunna använda ping eller PsPing direkt på en Office 365 URL. Nästa steg är att testa ping outlook.office365.com. Eller, om du använder PsPing eller ett annat verktyg som låter dig ange ett portnummer till kommandot, psping mot portal.microsoftonline.com:443 för att se den genomsnittliga tur och retur-tiden i millisekunder.

Tur och retur-tiden, eller RTT, är ett talvärde som mäter hur lång tid det tar att skicka en HTTP-begäran till en server som outlook.office365.com och få ett svar tillbaka som bekräftar att servern vet att du har gjort det. Ibland ser du detta förkortat som RTT. Detta bör vara en relativt kort tid.

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

Så här använder du PsPing för att få en total tur- och returtid i millisekunder direkt från en Office 365 URL

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

2. Klicka på Start.

3. I rutan Starta sökning skriver du cmd och trycker sedan på CTRL+SKIFT+RETUR.

4. Om dialogrutan User Account Control (User Account Control ) visas bekräftar du att åtgärden som visas är det du vill ha och klickar sedan på Fortsätt.

5. Navigera till mappen där verktyget (i det här fallet PsPing) är installerat och testa dessa Office 365 URL:er:

• psping admin.microsoft.com:443

• psping microsoft-my.sharepoint.com:443

• psping outlook.office365.com:443

• psping www.yammer.com:443

  

Se till att inkludera portnumret 443. Kom ihåg att Office 365 fungerar på en krypterad kanal. Om du PsPing utan portnumret misslyckas din begäran. När du har pingat din korta lista letar du upp genomsnittlig tid i millisekunder (ms). Det är vad du vill spela in!

Om du inte är bekant med proxy bypass och föredrar att ta saker steg för steg måste du först ta reda på namnet på proxyservern. I Internet Explorer går du till Verktyg>InternetAlternativ>Anslutningar LAN-inställningar>>Avancerat. Fliken Avancerat är där proxyservern visas. Pinga proxyservern i en kommandotolk genom att slutföra den här uppgiften:

Pinga proxyservern och få ett returvärde i millisekunder för steg 1 till 2

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

2. Klicka på Start.

3. I rutan Starta sökning skriver du cmd och trycker sedan på CTRL+SKIFT+RETUR.

4. Om dialogrutan User Account Control (User Account Control ) visas bekräftar du att åtgärden som visas är det du vill ha och klickar sedan på Fortsätt.

5. Skriv ping <namnet på proxyservern som din webbläsare använder, eller IP-adressen för proxyservern> och tryck sedan på RETUR. Om du har PsPing eller något annat verktyg installerat kan du välja att använda verktyget i stället.

   Kommandot kan se ut som något av följande exempel:

• pinga 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 skicka testpaket får du en liten sammanfattning som visar ett genomsnitt, i millisekunder, och det är det värde du är efter. Ta en skärmbild av prompten och spara den med din namngivningskonvention. I det här läget kan det också hjälpa att fylla i diagrammet med värdet.

Kanske har du tagit en spårning tidigt på morgonen, och klienten kan snabbt komma till proxyn (eller vilken utgående server som går ut till Internet). I det här fallet kan dina siffror se ut så här:

Om klientdatorn är en av de utvalda med åtkomst till proxyservern (eller utgående) servern kan du köra nästa del av testet genom att fjärransluta till datorn och köra kommandotolken till PsPing till en Office 365 URL därifrån. Om du inte har åtkomst till den datorn kan du kontakta nätverksresurserna för att få hjälp med nästa steg och få exakta siffror på det sättet. Om det inte är möjligt kan du ta en PsPing mot den aktuella Office 365 URL:en och jämföra den med PsPing- eller Ping-tiden mot proxyservern.

Om du till exempel har 51,84 millisekunder från klienten till Office 365 URL och du har 2,8 millisekunder från klienten till proxyn (eller utgående punkt) har du 49,04 millisekunder från utgående till Office 365. Om du har en PsPing på 12,25 millisekunder från klienten till proxyn under dagen och 62,01 millisekunder från klienten till den Office 365 URL:en är det genomsnittliga värdet för proxyutgången till den Office 365 URL:en 49,76 millisekunder.

När det gäller felsökning kan du hitta något intressant bara från att behålla dessa baslinjer. Om du till exempel upptäcker att du vanligtvis har cirka 40 millisekunder till 59 millisekunders svarstid från proxyn eller utgående punkt till Office 365 URL: en, och har en klient till proxy eller utgående punktfördröjning på cirka 3 millisekunder till 7 millisekunder (beroende på hur mycket nätverkstrafik du ser under den tiden på dagen) kommer du säkert att veta att något är problematiskt om dina tre sista klienter till proxy- eller utgångsbaslinjer visar en svarstid på 45 millisekunder.

Avancerade metoder

Om du verkligen vill veta vad som händer med dina Internetbegäranden till Office 365 måste du bekanta dig med nätverksspårningar. Det spelar ingen roll vilka verktyg du föredrar för dessa spårningar, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, instrumentpanelen för utvecklare eller någon annan kommer att göra så länge verktyget kan samla in och filtrera nätverkstrafik. I det här avsnittet ser du att det är bra att köra mer än ett av dessa verktyg för att få en mer fullständig bild av problemet. När du testar fungerar vissa av dessa verktyg också som proxyservrar i sig själva. Verktyg som används i den tillhörande artikeln Prestandafelsökningsplan för Office 365, inkluderar Netmon 3.4, HTTPWatch eller WireShark.

Att använda en prestandabaslinje är den enkla delen av den här metoden, 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 att du tar och lagrar nätverksspårningar. De flesta av exemplen i den här artikeln använder SharePoint Online, men du bör utveckla en lista över vanliga åtgärder i de Office 365 tjänster som du prenumererar på för att testa och registrera. Här är ett baslinjeexempel:

• Baslinjelista för SPO – ** Steg 1: ** Bläddra på 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öretagsnamn) via Enterprise Search och gör en nätverksspårning. Spara spårningen.

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

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

Den här listan bör innehålla de viktigaste vanliga åtgärderna som användare vidtar mot SharePoint Online. Observera att det sista steget, för att spåra gå till OneDrive för företag, bygger in en jämförelse mellan belastningen på SharePoint Online-startsidan (som ofta anpassas av företag) och OneDrive för företag startsida, som sällan anpassas. Det här är ett grundläggande test när det gäller en SharePoint Online-webbplats med långsam inläsning. Du kan skapa en post med den här skillnaden i testningen.

Om du är mitt i ett prestandaproblem är många av stegen desamma som när du tar en baslinje. Nätverksspårningar blir kritiska, så vi ska hantera hur vi ska ta de viktiga spårningarna härnäst.

För att lösa ett prestandaproblem måste du just nu ta en spårning när du upplever prestandaproblemet. Du måste ha rätt verktyg tillgängliga för att samla in loggar, och du behöver en åtgärdsplan, d.v.s. en lista över felsökningsåtgärder som ska vidtas för att samla in den bästa informationen som du kan. Det första du bör göra är att registrera datum och tid för testet så att filerna kan sparas i en mapp som återspeglar tidpunkten. Därefter kan du begränsa till själva problemstegen. Det här är de exakta stegen som du kommer att använda för testning. Glöm inte grunderna: om problemet bara gäller Outlook bör du registrera att problemet bara inträffar i en Office 365 tjänst. Genom att begränsa omfånget för det här problemet kan du fokusera på något som du kan lösa.

Se även

Hantera Office 365-slutpunkter