Plan för prestandafelsökning för Office 365

Do you need to know the steps to take to identify and fix lags, hangs, and slow performance between SharePoint Online, OneDrive for Business, Exchange Online, or Skype for Business Online, and your client computer? Before you call support, this article can help you troubleshoot Office 365 performance issues and even fix some of the most common issues.

Obs!:  Vi vill kunna erbjuda dig bästa möjliga supportinnehåll så fort som möjligt och på ditt språk. Den här sidan har översatts med hjälp av automatiserad översättning och kan innehålla grammatiska fel eller andra felaktigheter. Vår avsikt är att den här informationen ska vara användbar för dig. Vill du berätta för oss om informationen är till hjälp längst ned på sidan? Här är artikeln på engelska som referens.

Den här artikeln är i själva verket ett exempel på en handlingsplan som du kan använda för att få värdefull information om prestandaproblem när de uppstår. Några vanliga problem visas också här.

Om nätverksprestanda är nytt för dig och du vill lägga upp en långsiktig plan för att övervaka prestanda mellan klientdatorer och Office 365 kan du läsa Prestandajustering och felsökning i Office 365 – administratörer och IT-tekniker.

Exempel på handlingsplan vid felsökning av prestanda

Denna handlingsplan innehåller två delar, en förberedelsefas och en loggningsfas. Om du har ett prestandaproblem precis nu och du behöver samla in data kan du börja använda den här planen direkt.

Förbered klientdatorn

  • Hitta en klientdator som kan återskapa prestandaproblemet. Den här datorn kommer att användas under felsökningen.

  • Skriv ned de steg som ger upphov till prestandaproblemen så att du är redo när det blir dags att testa.

  • Installera verktyg för insamling och inspelning av information:

    • Installera Netmon 3.4 (eller använd ett likvärdigt verktyg för nätverksspårning).

    • Installera den kostnadsfria basversionen av HTTPWatch (eller använd ett likvärdigt verktyg för nätverksspårning).

    • Använd ett skärminspelningsprogram eller kör Steps Recorder (PSR.exe) som medföljer Windows Vista och senare för att spela in de åtgärder du vidtar vid testning.

Registrera prestandaproblemet

  • Stäng alla ovidkommande webbläsare.

  • Starta Steps Recorder eller en annan skärminspelare.

  • Starta Netmon-inspelningen (eller nätverksspårningsverktyget).

  • Rensa DNS-cachen på klientdatorn från kommandoraden genom att skriva in ipconfig /flushdns.

  • Starta en ny webbläsarsession och aktivera HTTPWatch.

  • Valfritt: Om du testar Exchange Online, kör verktyget Exchange Client Performance Analyzer från administratörskonsolen för Office 365.

  • Återskapa de exakta steg som ger upphov till prestandaproblemet.

  • Stoppa Netmon eller det andra verktygets spårning.

  • På kommandoraden, kör en spårningsbana till Office 365-prenumerationen genom att skriva in följande kommando och trycka på RETUR:

    tracert <prenumerationsnamn>.onmicrosoft.com

  • Stoppa Steps Recorder och spara videon. Glöm inte att ange datum och tid för inspelningen och om den visar på goda eller dåliga prestanda.

  • Spara spårningsfilerna. Återigen, glöm inte att ange datum och tid för inspelningen och om den visar på goda eller dåliga prestanda.

Om du inte är bekant med att använda de verktyg som nämns i den här artikeln, var lugn - vi beskriver stegen här. Om du är van vid detta slags nätverksinspelning kan du gå vidare till avsnittet Så här avläser du spårningar, som beskriver filtrering och avläsning av loggarna.

Rensa först DNS-cachen

Varför? Genom att rensa DNS-cachen startas testen med en ren utgångspunkt. Genom att rensa cachen kan du återställa DNS-lösarens innehåll till de mest aktuella posterna. Kom ihåg att rensning inte innebär att HOST-filens poster tas bort. Om du använder HOST-filens poster mycket bör du kopiera dessa poster till en fil i en annan katalog och sedan tömma HOST-filen.

Flush your DNS resolver cache

  1. Öppna kommandotolken (antingen Start > Kör > cmd eller Windows-tangenten > cmd).

  2. Skriv in följande kommando och tryck på RETUR:

    ipconfig /flushdns

Netmon

Microsoft's Network Monitoring tool (Netmon) analyzes packets, that is traffic, that passes between computers on networks. By using Netmon to trace traffic with Office 365 you can capture, view, and read packet headers, identify intervening devices, check important settings on network hardware, look for dropped packets, and follow the flow of traffic between computers on your corporate network and Office 365. Because the actual body of the traffic is encrypted, that is, it(travels on port 443 via SSL/TLS, you can't read the files being sent. Instead, you get an unfiltered trace of the path that the packet takes which can help you track down the problem behavior.

Se till att inte använda ett filter i det här sammanhanget. Gå i stället igenom stegen och demonstrera problemet innan du avbryter spårningen och sparar.

När du har installerat Netmon 3.4 , öppna verktyget och utför dessa steg:

Take a Netmon trace and reproduce the issue

  1. Starta Netmon 3.4.

    There are three panes on the Start page: Recent Captures, Select Networks, and the Getting Started with Microsoft Network Monitor 3.4. Notice. The Select Networks panel will also give you a list of the default networks from which you can capture. Be sure that network cards are selected here.

  2. Klicka på Ny inspelning längst upp på Start-sidan. Då läggs en ny flik till bredvid Start-sidans flik som kallas Inspelning 1.

    Nemons användargränssnitt med knapparna Ny registrering, Start och Stopp markerade.

  3. Gör en enkel inspelning genom att klicka på Start i verktygsfältet.

  4. Återskapa de steg som ger upphov till ett prestandaproblem.

  5. Klicka på Stop > Arkiv > Spara som. Kom ihåg att ange datum och tid med tidszon och om det visar på dåliga eller goda prestanda.

HTTPWatch

HTTPWatch comes in charged, and a free edition. The free Basic Edition covers everything you need for this test. HTTPWatch monitors network traffic and page load time right from your browser window. HTTPWatch is a plug-in to Internet Explorer that graphically describes performance. The analysis can be saved and viewed in HTTPWatch Studio.

Meddelanden: 

  • Om du använder en annan webbläsare, till exempel Firefox eller Google Chrome, eller om du inte kan installera HTTPWatch i Internet Explorer kan du öppna ett nytt webbläsarfönster och trycka på F12 på tangentbordet. Du bör se popup-fönstret för Developer Tool längst ned i din webbläsare. Om du använder Opera trycker du på CTRL+SKIFT+I för Web Inspector och klicka sedan på flikenNätverk och slutför testet enligt nedan. Informationen kommer att vara något annorlunda, men laddningstiderna visas fortfarande i millisekunder.

  • HTTPWatch är också mycket användbart för problem med sidladdningstider för SharePoint Online.

Run HTTPWatch and reproduce the issue

  1. HTTPWatch är ett webbläsartillägg, så att visning av verktyget i webbläsaren är olika för varje version av Internet Explorer. Vanligtvis kan du hitta HTTPWatch under fältet Kommandon i webbläsaren Internet Explorer.

    Om du inte ser HTTPWatch-tillägget i webbläsarfönstret, kontrollera versionen av webbläsaren genom att klicka på Hjälp > Om, eller i senare versioner av Internet Explorer klickar du på kugghjulssymbolen och Om Internet Explorer. För att öppna fältet Kommandon högerklickar du på menyraden i Internet Explorer och klickar på fältet Kommandon. Tidigare har HTTPWatch kopplats till både fältet Kommandon och fältet Utforskaren, så om du inte ser ikonen när du har installerat (även efter omstart), sök efter ikonen i Verktyg och verktygsfälten. Kom ihåg att verktygsfält kan anpassas och att alternativ kan läggas till i dem.

    Internet Explorers kommandoverktygsfält med HTTPWatch-ikonen visas.

  2. Starta HTTPWatch i ett Internet Explorer-fönster. Det visas dockat i webbläsaren längst ned i fönstret. Klicka på Spela in.

  3. Återskapa de exakta stegen som ingår i prestandaproblemet. Klicka på knappen Stoppa i HTTPWatch.

  4. Spara HTTPWatch eller Skicka via e-post. Kom ihåg att namnge filen så att den innehåller datum och tid och en indikation om kontrollen visar på goda eller dåliga prestanda.

    HTTPWatch visar fliken Nätverk för inläsning av en sida på startsidan för Office 365.

    Denna skärmbild är tagen från den professionella versionen av HTTPWatch. Du kan öppna spårningar som gjorts i basversionen på en dator med en professionell version och läsa den där. Det kan finnas extra information tillgänglig från spårningen genom den metoden.

Problemregistrering

Steps Recorder, eller PSR.exe, låter dig till spela in problem medan de inträffar. Det är ett mycket användbart verktyg och mycket enkelt att använda.

Run Problem Steps Recorder (PSR.exe) to record your work

  1. Använd antingen Start > Kör > skriv in PSR.exe > OK eller klicka på Windows-tangenten > skriv in PSR.exe > och tryck sedan på RETUR.

  2. När det lilla PSR.exe-fönstret visas klickar du på Starta inspelning och återskapar de steg som uppvisar prestandaproblemet.

    You can add comments as needed, by clicking Add Comments.

  3. Click Stop Record when you have completed the steps. If the performance issue is a page render, wait for the page to render before you stop the recording.

  4. Klicka på Spara.

En skärmbild av Problemregistrering eller PSR.exe.

The date and time is recorded for you. This links your PSR to your Netmon trace and HTTPWatch in time, and helps with precision troubleshooting. The date and time in the PSR record can show that a minute passed between the login and browsing of the URL and the partial render of the admin site, for example.

Läs dina spårningar

Det går inte att lära ut allt som någon kan behöva veta om nätverk och felsökning av prestandaproblem i en artikel. För att bli duktig på prestanda krävs erfarenhet och kunskap om hur nätverket fungerar. Det går däremot att sammanställa en lista med vanliga frågor och visa hur verktyg kan göra det enklare för dig att lösa de vanligaste problemen.

If you want to pick up skills reading network traces for your Office 365 sites, there is no better teacher than creating traces of page loads regularly and gaining experience reading them. For example, when you have a chance, load an Office 365 service and trace the process. Filter the trace for DNS traffic, or search the FrameData for the name of the service you browsed. Scan the trace to get an idea of the steps that occur when the service loads. This will help you learn what normal page load should look like, and in the case of troubleshooting, particularly around performance, comparing good to bad traces can teach you a lot.

Netmon uses Microsoft Intellisense in the Display filter field. Intellisense, or intelligent code completion, is that trick where you type in a period and all available options are displayed in a drop-down selection box. If, for example, you are worried about TCP window scaling, you can find your way to a filter (such as .protocol.tcp.window < 100) by this means.

Skärmbild av Netmon som visar att fältet Visa filter använder IntelliSense.

Netmon traces can have a lot of traffic in them. If you aren't experienced with reading them, it's likely you will be overwhelmed opening the trace the first time. The first thing to do is separate the signal from the background noise in the trace. You tested against Office 365, and that's the traffic you want to see. If you are used to navigating through traces, you may not need this list.

Trafik mellan klienten och Office 365 färdas via TLS, vilket innebär att huvuddelen av trafiken krypteras och inte kan läsas i en allmän Netmon-spårning. För prestandaanalysen behövs inga specifika detaljer om informationen i paketet. Mer intressant är rubrikerna i paketet och den information de innehåller.

Tips to get a good trace

  • Det är viktigt att veta klientdatorns IPv4- eller IPv6-adress. Du kan hämta den via kommandotolken genom att skriva IPConfig och sedan trycka på RETUR. När du vet adressen kan du genast se om trafiken i spårningen direkt berör klientdatorn. Om det finns en känt proxy, pinga den och få dess IP-adress också.

  • Rensa DNS-resolverns cache och, om möjligt, stäng alla webbläsare utom den där du kör dina tester. Om det inte går, till exempel om supporten använder ett webbläsarbaserat verktyg för att se din klientdators skrivbord, kan du istället filtrera din spårning.

  • In a busy trace, locate the Office 365 service that you're using. If you've never or seldom seen your traffic before, this is a helpful step in separating the performance issue from other network noise. There are a few ways to do this. Directly before your test, you can use ping or, PsPing, to the URL of the specific service (ping outlook.office365.com and/or psping -4 microsoft-my.sharepoint.com:443, for examples) . You can also easily find that PsPing in a Netmon trace (by its process name). That will give you a place to start looking.

    Det går lika bra att bara använda Netmon-spårning vid tidpunkten för problemet. För att orientera dig kan du använda filter som ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"). Du kan spara ditt ramnummer från spårningsfilen. Du kan också rulla fönstret Ramsammanfattning hela vägen till höger och leta efter kolumnen Konversations-ID. Där finns ett nummer som visar ID för den specifika konversationen och som du också kan spara och titta på separat senare. Kom ihåg att ta bort filtret innan du lägger till en annan filtrering.

    Tips: Netmon har många användbara inbyggda filter. Prova med knappen ”Läs in filter” högst upp i fönstret Visa filter.

    Hitta din IP-adress med hjälp av PSPing på kommandoraden på klientdatorn.

    Netmon-spårningen från klienten visar samma PSPing-kommando genom filtret TCP.Flags.Syn == 1.

    Bekanta dig med din trafik, och lär dig att hitta den information du behöver. Till exempel kan du lära dig att avgöra vilket paket i spårningen som har den första referensen till den Office 365-tjänst som du använder (t.ex. "Outlook" ).

Om vi tar Office 365 Outlook Online som exempel börjar trafiken ungefär så här:

  • DNS-standardfråga och DNS-svar för outlook.office365.com med matchande fråge-ID. Det är viktigt att notera tidsförskjutningen för vändningen samt var i världen Office 365 Global DNS skickar begäran om namnmatchning. Så lokalt som möjligt är mycket bättre än till andra sidan jordklotet. (Detta kan följas av en del DNS-trafik till online-inloggningen.)

  • En HTTP-begäran av typen HÄMTA vars statusrapport flyttades permanent (301)

  • RWS-trafik, däribland RWS Anslutningsförfrågningar och Anslutningssvar. (Remote Winsock gör en anslutning åt dig.)

  • A TCP SYN and TCP SYN/ACK conversation. A lot of the settings in this conversation impact your performance.

  • Sedan kommer en serie TLS: TLS-trafik är var TLS-handskakningen och konversationerna om TLS-certifikat äger rum. (Kom ihåg att data krypteras via SSL/TLS.)

Alla delar av trafiken är viktiga och sammanhängande, men små delar av spårningen innehåller information som är särskilt viktig när det gäller felsökning av prestandaproblem. Vi kommer därför att fokusera på dessa områden. Eftersom vi på Microsoft har gjort många felsökningar av prestandaproblem i Office 365 och kunnat sammanställa en lista över de 10 vanligaste problemen ska vi nu fokusera på de frågorna och hur du använder verktyg som löser problemen.

Flera verktyg används i matrisen nedan, där så är möjligt. Om du inte redan har installerat dem finns det länkar till installationsplatserna. Listan innehåller vanliga spårningsverktyg för nätverk som Netmon och Wireshark, men använd de spårningsverktyg du är bekväm med och som du är van att filtrera nätverkstrafik med. När du testar, kom ihåg:

  • Close your browsers, and test with only one browser running - This will reduce the overall traffic you capture. It makes for a less busy trace.

  • Rensa DNS-resolverns cache på klientdatorn – då kan du börja från grunden när du fångar in information vilket ger en renare spårning.

Några vanliga problem

Några vanliga problem du kan stöta på och hur du hittar dem i din nätverksspårning.

Problem

Verktyg

Vad du ska leta efter

TCP-fönsterskalning

  • Finns i SYN - SYN/ACK.

  • Äldre maskinvara kan inte dra fördel av TCP-fönsterskalning.

  • Utan rätt inställningar för TCP-fönsterskalning, fylls standardinställningen 16-bitars buffert i TCP-huvudena på några millisekunder.

  • Trafik kan inte fortsätta att skickas förrän klienten får en bekräftelse på att den ursprungliga datan har tagits emot, vilket orsakar förseningar.

Netmon

Wireshark

Leta efter SYN – SYN/ACK-trafiken i din nätverksspårning.

In Netmon, use a filter like tcp.flags.syn == 1. This filter is the same in Wireshark.

Filter i Netmon eller Wireshark för Syn-paket för båda verktygen: TCP.Flags.Syn == 1.

Observera att för varje SYN finns det ett källportsnummer (SrcPort) som matchas i målporten (DstPort) i den relaterade Bekräftelsen (SYN/ACK).

För att se fönsterskalningsvärdet som används av din nätverksanslutning, ska du först expandera SYN, och sedan den relaterade SYN/ACK.

Bild som visar hur du matchar SrcPort till DstPort i en spårning för att få tid att delta.

Inställningar för TCP-inaktivitet

  • Historiskt sett är de flesta perimeternätverk konfigurerade för tillfälliga anslutningar, vilket innebär att inaktiva anslutningar i allmänhet avslutas.

  • Inaktiva TCP-sessioner kan avslutas av proxyservrar och brandväggar på mer än 100 till 300 sekunder.

  • Det är problematiskt för Outlook Online som skapar och använder långsiktiga anslutningar, oavsett om de är inaktiva eller inte.

  • När anslutningar avslutas av en proxyserver eller brandvägg informeras inte klienten. Ett försök att använda Outlook Online innebär då att en klientdator kommer att försöka att återuppliva anslutningen flera gånger innan en ny görs.

  • Produkten kan hänga sig, visa ett meddelande, eller läsa in sidan långsamt.

Netmon

Wireshark

I Netmon, titta i fältet Tidsförskjutning för tidsfördröjningen. Tidsfördröjning är tiden mellan att klienten skickar en förfrågan till servern och tar emot ett svar. Kontrollera mellan klienten och den utgående punkten (ex. Klienten --> Proxyserver), eller klient till Office 365 (Klient –> Office 365). Du kan se detta i många typer av paket.

As an example, the filter in Netmon may look like .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12, or, in Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12.

Tips: 

  • Vet du inte om IP-adressen i din spårning hör till din DNS-server? Försök leta upp det i kommandoraden. Klicka på Start >; Kör > och skriv in cmd, eller tryck på Windows-tangenten > och skriv in cmd. Skriv nslookup <the IP address from the network trace>när du uppmanas att göra det. För att testa, använd nslookup mot din egen dators IP-adress.

  • För att visa en lista med Microsofts IP-intervall gå till Office 365 URL:er och IP-adressintervall.

If there is a problem, expect long Time Offsets to appear, in this case (Outlook Online), particularly in TLS:TLS packets that show the passage of Application Data (for example, in Netmon you can find application data packets via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). You should see a smooth progression in the time across the session. If you see long delays when refreshing your Outlook Online, this could be caused by a high degree of resets being sent.

Svarstid/Tidsfördröjning

  • Latency is a measure that can change a lot depending on many variables, such upgrading aging devices, adding a large number of users to a network, and the percentage of overall bandwidth consumed by other tasks on a network connection.

  • Det finns bandbreddskalkylatorer för Office 365 tillgängliga på den här sidan för nätverksplanering och prestandajustering för Office 365.

  • Vill du mäta hastigheten på din anslutning, eller bandbredden på din ISP-anslutning? Prova den här webbplatsen (eller webbplatser som den): Speedtest, eller Pingtest.

Ping

PsPing

Netmon

Wireshark

För att se svarstiden i en spårning, har du en fördel av att ha registrerat klientdatorns IP-adress och IP-adressen för DNS-servern i Office 365. Det här är för att enklare kunna spåra filtrering. Om du ansluter via en proxyserver, behöver du ha klientdatorns IP-adress, IP-adress till proxy/utgående server och Office 365 DNS IP-adress, för att underlätta arbetet.

Från den ping-begäran som skickas till outlook.office365.com får du veta namnet på datacentret som tog emot begäran, även om ping kanske inte kunde ansluta för att skicka de sammanhängande ICMP-paketen. Om du använder PsPing (ett gratisverktyg som finns för nedladdning), och den specifika porten (443) och kanske använder IPv4 (-4) får du ett medelvärde för tidsfördröjningen för paketen som skickats. Detta fungerar för andra URL:er i Office 365-tjänsterna t.ex. psping -4 yourSite.sharepoint.com:443. Du kan ange ett antal pingar för att få ett större underlag för medelvärdet genom att prova något som: psping -4 -n 20 yourSite-my.sharepoint.com:443.

Obs!: PsPing skickar inte ICMP-paket. Programmet pingar med TCP-paket över en specifik port, så du kan använda någon som du vet är öppen. I Office 365, som använder SSL/TLS, kan du prova att ansluta porten 443 till din PsPing.

Skärmbild som visar en ping som matchar outlook.office365.com och en PSPing med 443 som gör samma sak, men som även rapporterar en genomsnittlig RTT på 6,5 ms.

Om du läste in sidan Office 365 långsamt samtidigt som du gjorde en nätverksspårning bör du filtrera en Netmon- eller Wireshark-spårning för DNS. Det här är en av de IP-adresser vi söker.

Här är de åtgärder du kan vidta för att filtrera Netmon och få IP-adressen (och ta en titt på DNS-svarstiden). I det här exemplet används outlook.office365.com, men man kan också använda URL-adressen till en SharePoint Online-innehavare (hithere.sharepoint.com till exempel).

  1. Pinga URL-adressen ping outlook.office365.com och, i resultatet, registrera namn och IP-adress för den DNS-servern som ping-begäran skickades till.

    Ping-begäran till outlook.office365.com som visar DNS- och IP-adressen för namnorthwest.

  2. Network trace opening the page, or doing the action that gives you the performance problem, or, if you see a high latency on the ping, itself, network trace it.

  3. Öppna spårningen i Netmon och filtrera för DNS (det här filtret fungerar också i Wireshark, men är skiftlägeskänsligt -- dns). Eftersom du fått namnet på DNS-servern från pingen kan du också filtrera snabbare i Netmon så här: DNS AND ContainsBin(FrameData, ASCII, "namnorthwest"). Den ser ut så här i Wireshark dns and frame contains "namnorthwest".

    Öppna svarspaketet och, i fönstret Raminformation i Netmon klickar du på DNS för att expandera för mer information. I DNS-informationen hittar du IP-adressen till DNS-servern som begäran gick till i Office 365 -- du behöver IP-adressen för nästa steg (PsPing-verktyget). Ta bort filtret, högerklicka på DNS-svaret i Netmons Ramsammanfattning > Hitta Konversationer > DNS för att se DNS-fråga och DNS-svar sida vid sida.

    En spårning filtrerad efter Hitta konversationer och sedan efter DNS.

  4. Lägg också märke till kolumnen Tidsförskjutning i Netmon, mellan DNS-begäran och Svar.

    Ytterligare Netmon-resultat filtrerade med DNS OCH CONTAINSBIN(Framedata, ASCII, "namnorthwest") visar mycket låg tidsförskjutning mellan begäran och svar.

I nästa steg, enkelt att installera och använda PsPing är verktyget mycket praktiskt, både eftersom ICMP blockeras ofta på brandväggar och eftersom PsPing spårar elegant fördröjningar i millisekunder. PsPing fylls en TCP-anslutning till en adress och port (i vårt tänkbara öppen port 443).

  1. Installera PsPing.

  2. Öppna en kommandotolk (Start &gt; Kör &gt; skriv cmd, eller Windows-tangenten &gt; skriv cmd) och ändra katalog till den katalog där du installerade PsPing för att köra PsPing-kommandot. I mina exempel kan du se att jag har skapat mappen 'Perf' i roten på C. Du kan göra samma sak för snabb åtkomst.

  3. Skriv kommandot så att du gör din PsPing mot IP-adressen för Office 365 DNS-servern från din tidigare Netmon-spårning – kom ihåg att lägga till portnumret. Det vill säga, psping -n 20 132.245.24.82:445. Det här ger dig ett urval av 20 ping och beräknar medelvärdet för svarstiden när PsPing stannar.

    PSPing-kommandot psping -n 20 132.245.24.82:443 returnerar en genomsnittlig svarstid på 25,51 millisekunder.

Om du går till Office 365 via en proxyserver är stegen lite annorlunda. Då skickar du först PsPing till proxyservern för att få ett genomsnittligt värde på svarstiden i millisekunder till proxy/utgång och tillbaka, och sedan kör du antingen PsPing på proxyn eller på en dator med direktanslutning till Internet för att få värdet som saknas (värdet till Office 365 och tillbaka).

Om du väljer att köra PsPing från proxyn har du två millisekundvärden: klientdator till proxyserver eller utgående punkt och proxyserver till Office 365. Och nu är du klar! I alla fall med att registrera värden.

If you run PsPing on another client computer that has a direct connection to the Internet, that is, without a proxy, you will have two millisecond values: Client computer to proxy server or egress point, and client computer to Office 365. In this case, subtract the value of client computer to proxy server or egress point from the value of client computer to Office 365, and you will have the RTT numbers from your client computer to the proxy server or egress point, and from proxy server or egress point to Office 365.

Men om du kan hitta en klientdator på den påverkade platsen som är direkt ansluten, eller som förbigår proxyn, kan du välja att se om problemet återges där till att börja med och därefter testa det.

Svarstid, såsom visas i en Netmon-spårning dessa extra millisekunder kan lägga till, om det finns tillräckligt många av dem i en given session.

Allmän svarstid i Netmon, med Netmons standarkolumn för Tidsspann, läggs till i Ramsammanfattning.

Obs!: Din IP-adress kan vara annorlunda än de IP-adresser som visas här. Ditt ping kan till exempel returnera något i stil med 157.56.0.0/16 eller ett liknande intervall. En lista över intervall som används av Office 365 finns i Office 365 URL:er och IP-adressintervall. Kom ihåg att visa alla noder (det finns en knapp längst upp för det här) om du vill söka efter exempelvis 132.245.

Proxyautentisering

  • Det här gäller endast om du går via en proxyserver. Om du inte gör det kan du hoppa över de här stegen.

  • När allt fungerar som det ska ska proxyautentiseringen inträffa inom millisekunder, konsekvent. Du bör inte se tillfälligt dålig prestanda vid hög arbetsbelastning (till exempel).

  • Om proxyautentisering är aktiverad måste du, varje gång du gör en ny TCP-anslutning till Office 365 för att få information, gå igenom en autentiseringsprocess bakom kulisserna. När du till exempel växlar från kalender till e-post i Outlook Online autentiserar du. Och om en sida i SharePoint Online visar media eller data från flera webbplatser eller platser, autentiserar du för varje TCP-anslutning som behövs för att återge data.

  • I Outlook Online kan du uppleva långsamma inläsningstider när du växlar mellan kalendern och din postlåda, eller långsam sidinläsning i SharePoint Online. Det finns emellertid andra symptom som inte visas här.

    Proxy-autentisering är en inställning på proxyservern utgående. Om den orsakar ett prestandaproblem med Office 365, måste du kontakta teamet nätverk.

Netmon

Wireshark

Proxy sker-autentisering när en ny TCP-session måste spunnits, ofta för att begära filer eller information från servern eller för att tillhandahålla information. Du kan till exempel se proxyautentisering runt HTTP GET eller HTTP POST förfrågningar. Lägga till kolumnen NTLMSSP sammanfattning i Netmon och filter för .property.NTLMSSPSummaryom du vill se ramar där du autentiserar förfrågningar i kurvan. Lägga till kolumnen tidsspann om du vill se hur lång tid tar autentiseringen. Lägga till en kolumn i Netmon:

  1. Högerklicka på en kolumn, t.ex. Beskrivning.

  2. Klicka på Välj kolumner. Leta reda på NTLMSSP-sammanfattning och Tidsspann i listan och klicka på Lägg till.

  3. Flytta de nya kolumnerna och placera dem före eller efter kolumnen Beskrivning så att du kan läsa dem sida vid sida. Klicka på OK.

Även om du inte lägger till kolumnen fungerar Netmon-filter. Men felsökningen är mycket enklare om du kan se vilka scenen autentiseringstyper som du befinner dig i. När letar för instanser av Proxy-autentisering, är det viktigt att undersöka alla ramar där det inte finns en NTLM-anrop eller ett autentisera meddelande finns. Om det behövs, högerklickar du på viss del av trafik och hitta konversationer > TCP. Ta reda på tidsspann värdena i dessa konversationer.

Netmon-spårning visar proxy-autentisering, filtrerat efter konversation.

En fyra sekunders fördröjning i proxyautentisering så som visas i Wireshark. Kolumnen Tidsspann från föregående visad ram skapades genom att högerklicka på fältet med samma namn i raminformationen och välja Lägg till som kolumn.

I Wireshark kan kolumnen "Time delta from previous displayed frame" skapas via högerklick på fältet med samma namn i raminformationen välja Add as Column.

DNS-prestanda

  • Namnmatchning fungerar bäst och snabbast när den sker så nära kundens land som möjligt.

  • Om DNS-namnmatchning sker utomlands kan det lägga till sekunder till sidinläsningen.

  • Under idealiska förhållanden sker namnmatchningen på under 100 ms. Om inte bör du undersöka saken närmare.

Tips: Är du osäker på hur klientanslutningar fungerar i Office 365? Ta en titt på referensdokumentet för klientanslutning här.

Netmon

Wireshark

PsPing

Att analysera DNS-prestanda är vanligtvis ytterligare ett jobb för en nätverksspårning. Men PsPing är också användbart för att bekräfta eller avfärda en möjlig orsak.

DNS-trafiken är baserad på TCP- och UDP-begäranden och svaren är tydligt markerade med ett ID som hjälper till att matcha en specifik begäran med det specifika svaret. Du ser DNS-trafik när exempelvis SharePoint Online använder ett nätverksnamn eller URL:en på en webbsida. Som en tumregel körs den mesta trafiken, förutom vid överföring av zoner, över UDP.

In both Netmon and Wireshark, the most basic filter that will let you look at DNS traffic is simply dns. Be sure to use lower case when specifying the filter. Remember to flush your DNS resolver cache before you begin to reproduce the issue on your client computer. For example, if you have a slow SharePoint Online page load for the Home page, you should close all browsers, open a new browser, start tracing, flush your DNS resolver cache, and browse to your SharePoint Online site. Once the entire page resolves, you should stop and save the trace.

Ett grundläggande filter för DNS i Netmon är DNS.

You want to look at the time offset here. And it may be helpful to add the Time Delta column to Netmon which you can do by completing these steps:

  1. Högerklicka på en kolumn, t.ex. Beskrivning.

  2. Klicka på Välj kolumner.

  3. Leta reda på Tidsspann i listan och klicka på Lägg till.

  4. Flytta den nya kolumnen och placera den före eller efter kolumnen Beskrivning så att du kan läsa dem sida vid sida. Klicka på OK.

Om du hittar en fråga som intresserar dig kan du överväga att isolera genom att högerklicka på frågan i informationsfönstret ram välja Hitta konversationer > DNS. Lägg märke till att panelen Nätverkskonversationer går till höger i specifika konversationen i loggen UDP-trafik.

En Netmon-spårning av inläsning av Outlook Online filtrerad med DNS och som använder Hitta konversationer efter DNS för att begränsa resultaten.

In Wireshark you can make a column for DNS time. Take your trace (or open a trace) in Wireshark and filter by dns, or, more helpfully, dns.time. Click on any DNS query, and, in the panel showing details, expand the Domain Name System (response) details. You'll see a field for time (for example, [Time: 0.001111100 seconds]. Right-click this time and select Apply as Column. This will give you a Time column for quicker sorting of your trace. Click on the new column to sort by descending values to see which DNS call took the longest to resolve.

En del av SharePoint Online filtrerat i Wireshark efter (gemener) dns.time, med tiden från uppgifterna i en kolumn och sorterad i stigande ordning.

Om du vill göra fler undersökningen DNS-upplösning oftast prova en PsPing mot DNS-port som används av TCP (till exempel psping <IP address of DNS server>:53). Se ett prestandaproblem fortfarande? Om du gör är problemet troligare att vara en mer omfattande nätverk utfärda än ett problem för specifika DNS-programmet träffar om du vill göra upplösning. Det är också värt att nämna igen, att en ping till outlook.office365.com talar om var DNS-namnmatchning för Outlook Online tar plats (till exempel outlook-namnorthwest.office365.com).

Om problemet verkar vara DNS-specifikt kan det vara nödvändigt att ta kontakt med IT-avdelningen för att titta på DNS-konfigurationer och DNS-vidarebefordrare för att undersöka problemet ytterligare.

Proxyskalbarhet

  • Tjänster som Outlook Online i Office 365 beviljar klienter flera långsiktiga anslutningar.

  • Därför kan varje användare använda flera anslutningar som kräver en längre livslängd.

Tips: Behöver du planera för bandbreddsanvändning eftersom du ska lägga till en stor mängd användare i Office 365? Prova Planera för bandbreddsanvändning på Internet för Office 365. Där hittar du bandbreddskalkylatorer.

Matematik

Det finns inte någon nätverksspårning eller något felsökningsverktyg specifikt för det här. Istället baseras det på bandbreddsberäkningar med angivna begränsningar och andra variabler.

TCP Max. segmentstorleken

  • Finns i SYN - SYN/ACK.

  • Utför den här kontrollen i alla prestandanätverksspårningar som du har vidtagit för att säkerställa att TCP-paketen är konfigurerade för att innehålla största möjliga mängd data.

  • Målet är att se en MSS på 1 460 byte för överföring av data.

  • Om du sitter bakom en proxy, eller om du använder en NAT, ska du komma ihåg att köra det här testet från klient till proxy/utgång/NAT, och från proxy/utgång/NAT till Office 365 för bästa resultat! Det här är olika TCP-sessioner.

Netmon

TCP Max storlek MSS (Segment) är en annan parameter trevägshandskakning i din nätverksspårning innebär att du hittar de data du behöver i SYN - SYN/ACK-paket. MSS är faktiskt ganska enkelt att se.

Öppna en prestandanätverksspårning som du har och leta reda på den anslutning som du är nyfiken på, eller som visar prestandaproblemet.

Meddelanden: 

  • Om du tittar på en spårning och behöver hitta relevant trafik för din konversation filtrerar du efter IP för klienten, IP för proxyservern eller den utgående punkten, eller båda. Om du går direkt måste du pinga URL-adressen som du testar för IP-adressen för Office 365 i spårningen och filtrera efter den.

  • Visning av spårningen begagnade? Prova att använda filter för att orientera dig själv. Var medveten talets ram i Netmon, kör en sökning baserad på URL-adress, till exempel Containsbin(framedata, ascii, "sphybridExample"). Använd ungefär så frame contains "sphybridExample"i Wireshark. Om du märker att du har hittat Winsock (RW) trafik (det kan visas som en [PSH, ACK] i Wireshark), Kom ihåg att RW ansluter kan förekomma strax före relevanta SYN - SYN/ACK, som vi diskuterat tidigare. Vid den här tidpunkten kan du spela in ram tal, släpp filtret klickar du på All trafik i fönstret Nätverkskonversationer i Netmon igenom närmaste SYN.

  • Det viktiga är att om du inte fick någon IP-adressinformation vid tiden för spårningen så får du IP-adresser att filtrera efter genom att leta reda på din URL-adress i spårningen (en del av sphybridExample-my.sharepoint.com, till exempel).

  1. Leta reda på anslutningen i den spårning som du är intresserad av. Det kan du göra genom att antingen söka i spårningen, genom att filtrera efter IP-adresser eller genom att välja specifika konversations-ID:n i fönstret Nätverkskonversationer i Netmon.

    Filtrera efter konversation.Högerklicka på SYN-ram och klicka på Hitta konversationer, TCP.

  2. När du har hittat SYN-paketet visar du TCP (i Netmon), eller Transmission Control Protocol (i Wireshark) i panelen Raminformation.

  3. Visa TCP-alternativ och Max. segmentstorleken.

  4. Leta reda på relaterad SYN-ACK-ram och visa TCP-alternativ och Max. segmentstorleken.

  5. Det mindre av de två värdena kommer att vara din maximala segmentstorlek.

I den här bilden använder ringer jag den inbyggda kolumnen i Netmon som kallas TCP-felsökning.

Nätverksspårning filtrerad i Netmon med hjälp av de inbyggda kolumnerna.

Den inbyggda kolumnen finns högst upp på panelen Raminformation. (Om du vill växla tillbaka till normal vy klickar du på Kolumner igen och väljer sedan Tidszon.)

Här hittar du rullgardinsmenyn Kolumner för alternativet TCP-felsökning (ovanför Ramsammanfattning).

Här är en filtrerad spårning i Wireshark. Ett filter är specifik för värdet MSS (tcp.options.mss). Ramar i en SYN, SYN/ACK, ACK handshake länkas längst ned i Wireshark motsvarar raminformation (RAM så 47 ACK, länkar till 46 SYN/ACK, länkar till 43 SYN) så att den här typen av arbete blir lättare.

Spårning filtrerad i Wireshark av tcp.option.mss för Max. segmentstorleken (MSS).

Om du behöver kontrollera Selektiv bekräftelse (nästa avsnitt i denna matris) ska du inte stänga kurvan!

Selektiv bekräftelse

  • Finns i SYN - SYN/ACK.

  • Måste rapporteras som Tillåtna i både SYN och SYN/ACK.

  • Selektiv bekräftelse (SACK) möjliggör jämnare återöverföring av data när ett eller flera paket tappas bort.

  • Enheter kan inaktivera den här funktionen, vilket kan leda till prestandaproblem.

  • Om du sitter bakom en proxy, eller om du använder en NAT, ska du komma ihåg att köra det här testet från klient till proxy/utgång/NAT, och från proxy/utgång/NAT till Office 365 för bästa resultat! Det här är olika TCP-sessioner.

Netmon

Selektiv bekräftelse (SACK) är en annan parameter i SYN-SYN-/ACK-handskakning. Du kan filtrera kurvan för SYN – SYN/ACK på många sätt.

  1. Hitta anslutningen som du vill visa i kurvan genom att bläddra igenom kurvan, genom att filtrera efter IP-adresser eller genom att klicka på ett konversations-ID i fönstret Nätverkskonversationer i Netmon.

  2. När du har hittat SYN-paketet expanderar du TCP i Netmon eller Transmission Control Protocol i Wireshark i sektionen raminformation.

  3. Expandera TCP-alternativen och sedan SACK.

  4. Leta reda på den tillhörande SYN-ACK-ramen och Expandera TCP-alternativen och SACK-fältet.

  5. Kontrollera att SACK är tillåtet i både SYN och SYN/ACK.

Så här visas SACK-värdena i både Netmon och Wireshark.

Selektiv bekräftelse (SACK) i Netmon som ett resultat av tcp.flags.syn == 1.

SACK så som det visas i Wireshark med filtret tcp.flaggor.syn == 1.

DNS-geolokalisering

  • Var i världen Office 365 försöker lösa DNS-samtalet påverkar anslutningshastigheten.

  • När den första DNS-sökningen är klar i Outlook Online används den DNS-platsen för att ansluta till det närmsta datacentret. Du ansluts till en Outlook Online CAS-server som använder stamnätverket för att ansluta till datacentret (dc) där dina data lagras. Det är snabbare.

  • En användare som reser utomlands och använder SharePoint Online dirigeras till sitt aktiva datacenter. Det aktiva datacentrets plats beror på var huvudkontoret för användarens SPO ligger (ett datacenter i USA om användaren bor i USA).

  • Lync online har aktiva noder i fler än ett datacenter i taget. När en begäran skickas för Lync online-instanser, avgör Microsoft DNS var i världen begäran kom från och returnera IP-adresser från närmaste regionala datacenter där Lync online är aktivt.

Tips: Vill du veta mer om hur klienter ansluter till Office 365? Ta en titt i referensartikeln Kundanslutningar (och de hjälpsamma bilderna).

Ping

PsPing

Begäranden för namnmatchning från klientens DNS-servrar till Microsofts DNS-servrar ska i de flesta fall resultatet i Microsoft DNS returnerar IP-adressen för en regionala datacenter (domänkontrollant). Vad innebär detta för dig? Om din headquarters in Bangalore, Indien, men du reser i USA, när din webbläsare gör en begäran för Outlook Online, ska Microsofts DNS-servrar lämnar du IP-adresser för datacenter i USA – en regionala datacenter. Om e-post behövs från Outlook, färdas dessa data i Microsofts snabb ryggrad nätverk mellan datacenter.

DNS fungerar snabbast när namnmatchningen görs så nära användarens plats som möjligt. Om du är i Europa är det bäst att ansluta till ett Microsoft DNS i Europa och (helst) arbeta med ett datacenter i Europa. Prestandan från en klient i Europa via en DNS och ett datacenter i Amerika blir långsammare.

Kör Ping-verktyget mot outlook.office365.com för att bestämma till var i världen DNS-begäran vidarekopplas. Om du befinner dig Europa bör du få svar från någonting som liknar outlook-emeawest.office365.com. I Amerika kan du förvänta dig något som outlook-namnorthwest.office365.com.

  1. Öppna kommandotolken på klientdatorn (via Start > Kör > cmd eller Windows-tangenten > skriv cmd).

  2. Skriv ping outlook.office365.com och tryck på Retur.

    Kom ihåg att ange -4 om du vill ange om du vill pinga via IPv4. Du kan misslyckas att få ett svar från ICMP-paket, men du bör se namnet på sidan DNS begäran dirigerades.

Om du vill se svarstiden för den här anslutningen kan du prova med kommandot PsPing till IP-adressen för den server som returneras av ping.

Ping av outlook.office365.com med upplösningen i outlook-namnorthwest.

PSPing till IP-adressen som returneras av ping till outlook.office365.com med genomsnittlig latens på 28 millisekunder.

Felsökning av Office 365-program

Netmon

HTTPWatch

F12-konsol i webbläsaren

I den här nätverksspecifika artikeln diskuterar vi inte verktyg som används i programspecifik felsökning. Men du hittar resurser som du kan använda på den här sidan.

Närliggande avsnitt

Hantera Office 365 slutpunkter
Felsökning av Office 365-anslutning

Utöka dina Office-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.

×