Trenger du å vite hva som må gjøres til å identifisere og løse ventetid, henger og dårlig ytelse mellom SharePoint Online, OneDrive for Business, Exchange Online eller Skype for Business Online og klientdatamaskinen? Før du ringer kundestøtten, kan denne artikkelen hjelpe deg med å feilsøke Office 365-ytelsesproblemer og løse noen av de vanligste problemene selv.
Obs!: Vi ønsker å gi deg det nyeste hjelpeinnholdet så raskt som mulig, på ditt eget språk. Denne siden er oversatt gjennom automatisering og kan inneholde grammatiske feil eller unøyaktigheter. Formålet vårt er at innholdet skal være nyttig for deg. Kan du fortelle oss om informasjonen var nyttig for deg nederst på denne siden? Her er den engelske artikkelen for enkel referanse.
Denne artikkelen er egentlig et eksempel på en handlingsplan du kan bruke til å registrere verdifulle data om ytelsesproblemer underveis. Enkelte vanlige problemer er også oppført her.
-
Eksempel på handlingsplan for feilsøking av ytelsesproblemer
-
Kjøre Problem Steps Recorder (PSR.exe) for å registrere arbeidet
Hvis nettverksytelse er nytt for deg og du ønsker å lage en langsiktig plan for å overvåke ytelsen mellom klientmaskinene og Office 365, kan du ta en titt på Ytelsesjustering og feilsøking i Office 365 – Administrator og IT-ekspert.
Eksempel på handlingsplan for feilsøking av ytelsesproblemer
Denne handlingsplanen består av to deler: forberedelsen og loggingen. Hvis du opplever problemer med ytelsen akkurat nå og du må samle inn data, kan du begynne å bruke denne planen umiddelbart.
Gjør klar klientdatamaskinen
-
Finn en klientdatamaskin som kan reprodusere ytelsesproblemene. Den skal brukes i løpet av feilsøkingen.
-
Skriv ned trinnene som gir problemer med ytelsen slik at du er klar til å gjennomføre testen.
-
Installer verktøyene for innsamling og registrering av informasjon:
-
Installer Netmon 3.4 (eller bruk et tilsvarende nettverkssporingsverktøy).
-
Installer gratisversjonen Basic Edition av HTTPWatch (eller bruk et tilsvarende nettverkssporingsverktøy).
-
Bruk et skjerminnspillingsprogram eller kjør trinnregistrereren (PSR.exe) som følger med Windows Vista og nyere, for å holde oversikt over trinnene du utfører ta under testingen.
-
Logg ytelsesproblemet
-
Lukk alle overflødige nettlesere.
-
Start trinnregistrererer eller et annet skjerminnspillingsprogram.
-
Begynn å spille inn med Netmon (eller et nettverkssporingsverktøy).
-
Tøm DNS-bufferen på klientdatamaskinen fra kommandolinjen ved å skrive inn ipconfig /flushdns.
-
Start en ny nettleserøkt, og slå på HTTPWatch.
-
Valgfritt: Hvis du tester Exchange Online, kan du kjøre verktøyet Exchange Client Performance Analyzer i administrasjonskonsollen for Office 365.
-
Reproduser nøyaktig de trinnene som gir ytelsesproblemet.
-
Stopp Netmon eller det andre verktøyets sporing.
-
Kjør en sporingsrute til Office 365-abonnementet på kommandolinjen ved å skrive inn følgende kommando og deretter trykke ENTER:
tracert <abonnementsnavn>.onmicrosoft.com
-
Stopp trinnregistrereren, og lagre videoen. Pass på å ta med dato og klokkeslettet for innspillingen og om den viser god eller dårlig ytelse.
-
Lagre sporingsfilene. Vi gjentar: Pass på å ta med dato og klokkeslettet for innspillingen og om den viser god eller dårlig ytelse.
Hvis du ikke vet hvordan du kjører de verktøyene vi har nevnt i denne artikkelen, så vær litt tålmodig. Vi skal forklare det nå. Hvis du er vant til å kjøre denne typen nettverksregistrering, kan du hoppe til delen Hvordan du leser sporene, som beskriver hvordan du filtrerer og leser logger.
Tøm DNS-bufferen først
Hvorfor? Når du tømmer DNS-bufferen, starter du testene fra et friskt utgangspunkt. Når du tømmer bufferen, tilbakestiller du innholdet i DNS-løseren til de mest oppdaterte oppføringene. Husk at selv om du tømmer bufferen, fjerner du ikke oppføringene til vertsfilen. Hvis du bruker oppføringene i vertsfilen mye, bør du kopiere disse oppføringene til en fil i en annen katalog og deretter tømme vertsfilen.
Tøm DNS resolver-bufferen
-
Åpne ledeteksten (enten Start > Kjør > cmd eller Windows-tasten > cmd).
-
Skriv inn følgende kommando, og trykk ENTER:
ipconfig /flushdns
Netmon
Microsofts nettverket overvåking verktøyet (Netmon) analyserer pakker, som er trafikk som går mellom datamaskiner på nettverk. Ved hjelp av Netmon spor trafikk med Office 365 kan du ta visning, og Les pakke topptekster, identifisere mellomliggende enheter, kontrollerer viktige innstillinger på nettverksmaskinvaren, se etter mislykkede pakker, og følg flyten i trafikk mellom datamaskiner på i firmaet Nettverks- og Office 365. Ettersom faktisk brødteksten trafikken er kryptert, det vil si det (reiser på port 443 via SSL/TLS, du kan ikke lese filer som sendes. I stedet kan få du en ufiltrert sporing av banen i pakke utfører som kan hjelpe deg å spore problemet virkemåten.
Pass på at du ikke bruker et filter på dette tidspunktet. I stedet bør du gjennomføre trinnene og demonstrere problemet før du stopper sporet og lagrer det.
Når du har installert Netmon 3.4, åpner du verktøyet og gjør følgende:
Lag et Netmon-spor og Reproduser problemet
-
Start Netmon 3.4.
Det finnes tre ruter på startsiden: Nylige fanger opp, Velg nettverk og Getting Started with Microsoft nettverket skjerm 3.4. Legg merke til. Velg nettverk-panelet også gir deg en oversikt over standard nettverkene du kan ta. Pass på at nettverkskort velges her.
-
Klikk New Capture øverst på Start-siden. Dette legger til fanen Capture 1 ved siden av Start-fanen.
-
Klikk Start på verktøylinjen for å ta et enkelt bilde.
-
Reprodusere trinnene som leder til et ytelsesproblem.
-
Klikk Stopp > Fil > Lagre som. Husk å oppgi dato og klokkeslett med tidssonen og nevne om den viser dårlig eller god ytelse.
HTTPWatch
HTTPWatch kommer inn belastet, og en gratis utgave. Gratis Basic Edition dekker alt du trenger for denne testen. HTTPWatch skjermer network trafikk og siden innlastingstiden direkte fra nettleservinduet. HTTPWatch er en plugin-modul i Internet Explorer som beskriver grafisk ytelse. Analysen kan lagres og vises i HTTPWatch Studio.
Obs!:
-
Hvis du bruker en annen nettleser, for eksempel Firefox eller Google Chrome, eller hvis du ikke kan installere HTTPWatch i Internet Explorer, åpner du et nytt nettleservindu og trykker F12 på tastaturet. Du skal kunne se utviklerverktøyet i et eget vindu nederst i nettleseren. Hvis du bruker Opera, trykker du CTRL+SKIFT+I for Web Inspector og klikker deretter fanen Nettverk og fullfører testingen som er beskrevet nedenfor. Informasjonen vil være litt forskjellig, men sidelastingstidene vises fremdeles i millisekunder.
-
HTTPWatch er også svært nyttig for problemer med sidelastingstider for SharePoint Online.
Kjøre HTTPWatch og reprodusere problemet
-
HTTPWatch er en plugin-modul, dermed varierer det litt når du bruker verktøyet i nettleseren, avhengig av hvilken versjon av Internet Explorer du har. Vanligvis kan du finne HTTPWatch under kommandolinjen i Internet Explorer-nettleseren.
Hvis du ikke ser HTTPWatch plugin-modulen i nettleservinduet, kontrollerer du versjonen av nettleseren ved å klikke Hjelp > Om. I nyere versjoner av Internet Explorer klikker du tannhjulsymbolet og Om Internet Explorer. Høyreklikk menylinjen i Internet Explorer og klikk feltet Kommandoer for å starte Kommando-feltet. Tidligere har HTTPWatch vært forbundet både med Kommando- og Explorer-feltet. Hvis du ikke umiddelbart ser ikonet når du installerer (også etter omstart), må du kontrollere Verktøy og verktøylinjene for ikonet. Husk at verktøylinjer kan tilpasses, og alternativer kan legges til i dem.
-
Start HTTPWatch i et nettleservindu i Internet Explorer. Det vises forankret til nettleseren nederst i dette vinduet. Klikk Registrer.
-
Reproduser den nøyaktige fremgangsmåten involvert i ytelsesproblemet. Klikk på Stopp-knappen i HTTPWatch.
-
Lagre HTTPWatch-filen eller Send via e-post. Husk å gi filen navn slik at den inneholder dato og klokkeslett og en indikasjon på om Watch-filen din inneholder en demonstrasjon av god eller dårlig ytelse.
Dette skjermbildet er fra Professional-versjonen av HTTPWatch. Du kan åpne sporinger som er gjort i Basic-versjonen på en datamaskin med en Professional-versjon og lese dem der. Ekstra informasjon kan være tilgjengelig fra sporingen med denne metoden.
Problem Steps Recorder
Steps Recorder, eller PSR.exe, lar deg registrere problemer etter hvert som de oppstår. Det er et svært nyttig verktøy og enkelt å kjøre.
Kjøre problemet Trinnregistrereren (PSR.exe) til å registrere arbeidet
-
Bruk enten Start > Kjør > skriv inn PSR.exe > OK, eller klikk Windows-tasten > skriv inn PSR.exe > og trykk deretter ENTER.
-
Når det lille PSR.exe vinduet vises, klikker du Start registrering og reproduserer trinnene som gjenskaper ytelsesproblemet.
Du kan legge til kommentarer etter behov ved å klikke Legg til kommentarer.
-
Klikk Stopp post når du har fullført trinnene. Hvis ytelsesproblemet er en side gjengivelse, venter du til siden for å gjengi før du stopper innspillingen.
-
Klikk Lagre.
Dato og klokkeslett er registrert for deg. Dette koblinger til PSR til Netmon-sporing og HTTPWatch i tid og hjelper med å feilsøke presisjon. Dato og klokkeslett i PSR posten kan vise at et minutt gått mellom påloggingen og søk etter URL-adressen og delvis gjengivelse av admin-området, for eksempel.
Lese sporene dine
Det er ikke mulig å lære alt du trenger å vite om nettverk og feilsøking av ytelse fra en artikkel. Det krever erfaring og kunnskap om hvordan nettverket ditt fungerer og vanligvis yter, for at du skal bli god på ytelse. Men det er mulig å sette opp en liste over de problemene som forekommer oftest og vise hvordan verktøy kan gjøre det enklere for deg å eliminere de vanligste problemene.
Hvis du vil fortsette ferdigheter lese Nettverkssporinger for Office 365-nettsteder, er det ingen bedre læreren enn å opprette spor av sideinnlastingen regelmessig og få erfaring med å lese dem. Hvis du for eksempel når du har muligheten, laste inn en Office 365-tjenesten og spore prosessen. Filtrere sporingen for DNS-trafikk eller søke FrameData for navnet på tjenesten du viste. Skanne sporingen for å få en oversikt over trinnene som oppstår når tjenesten lastes inn. Dermed kan du lære hvilke normal sidelasting skal se ut, og når det gjelder feilsøking, spesielt rundt ytelse, sammenligne lurt å ugyldige sporinger kan lære deg mye.
Netmon bruker Microsoft Intellisense i feltet Vis filter. IntelliSense eller intelligent koden er fullført, er denne stikk der du skriver inn i en periode, og alle tilgjengelige alternativene vises i en rullegardinliste for rullegardinlisten. Hvis du for eksempel er bekymret for skalering av TCP-vinduet, kan du finne frem til et filter (for eksempel .protocol.tcp.window < 100) av det vil si at.
Netmon-spor kan inneholder mye trafikk. Hvis du ikke erfaring med å lese dem, er det sannsynlig du vil være overveldende åpne sporingen første gang. Er det første du vil skille signalet fra bakgrunnsstøy i sporingen. Du har testet mot Office 365, og som er trafikken du vil se. Hvis du brukte til å navigere gjennom sporinger, må du kanskje ikke denne listen.
Trafikk mellom klienten og Office 365 beveger seg via TLS, noe som betyr at hoveddelen av trafikken vil bli kryptert og ikke leselig i en generell Netmon-sporing. Ytelsesanalysen trenger ikke å vite detaljene i informasjonen i pakken. Den er imidlertid veldig interessert i pakkehodene og informasjonen de inneholder.
Tips for å få en god sporing
-
Kjenn verdien av IPv4- eller IPv6-adressene til klientdatamaskinen. Du kan få dette fra ledeteksten ved å skrive inn IPConfig og deretter trykke ENTER. Kjenner du denne adressen, kan du enkelt se om trafikk i sporingen involverer klientdatamaskinen direkte. Hvis det er en kjent proxy, kan du også pinge den og få IP-adressen.
-
Tøm DNS Resolver-bufferen og, hvis mulig, lukk alle nettlesere unntatt den du kjører testene i. Hvis du ikke kan gjøre dette, for eksempel hvis brukerstøtte bruker et nettleserbasert verktøy for å se skrivebordet på klientdatamaskinen, må du være forberedt på å filtrere sporinger.
-
Finn Office 365-tjenesten du bruker i en opptatt sporing. Hvis du har aldri eller sjelden Sett trafikken før, er et nyttig trinn i å skille ytelsesproblemet fra andre nettverk støy. Det finnes noen metoder for å gjøre dette. Direkte før testen, kan du bruke ping eller PsPing til URL-adressen for den bestemte tjenesten (ping outlook.office365.com og/eller psping -4 microsoft-my.sharepoint.com:443, eksempler). Du kan også enkelt finne det PsPing i en Netmon-sporing (etter prosessnavnet). Som gir deg et sted å begynne å se.
Hvis du bare bruker Netmon-sporing på det tidspunktet problemet oppstår, er det også i orden. Du kan bruke et filter, for eksempel ContainsBin(FrameData, ASCII, "office") eller ContainsBin(FrameData, ASCII, "outlook"), for å orientere deg. Du kan registrere rammenummeret fra sporingsfilen. Du vil kanskje også bla gjennom ruten Rammesammendrag helt til høyre og se etter Samtale-ID-kolonnen. Det er angitt et tall for ID-en til denne bestemte samtalen som du også kan ta registrere se nærmere på isolert senere. Husk å fjerne dette filteret før du bruker annen filtrering.
Tips!: Netmon har mange nyttige, innebygde filtre. Prøv knappen Last inn filter øverst på filtreringsruten Vis.
Bli kjent med trafikken din, og lær å finne informasjonen du trenger. Du kan for eksempel lære å finne ut hvilken pakke i sporingen som har den første referansen til Office 365-tjenesten du bruker (for eksempel Outlook).
Bruker vi Office 365 Outlook Online som eksempel, begynner trafikken omtrent slik:
-
DNS standardspørring og DNS-svar for outlook.office365.com med samsvarende spørrings-ID-er. Det er viktig å merke seg tidsforskyvningen for denne omløpstiden, i tillegg til hvor i verden den globale DNS for Office 365 sender forespørselen for navneløsing. Ideelt sett så lokalt som mulig, i stedet for til den andre siden av kloden. (Dette kan være etterfulgt av en viss DNS-trafikk ved pålogging på nettet.)
-
En HTTP GET-forespørsel med statusrapport flyttes permanent (301)
-
RWS-trafikk inkludert RWS-tilkoblingsforespørsler og tilkoblingssvar. (Dette er Remote Winsock, som oppretter en tilkobling for deg.)
-
En TCP SYN og SYN/ACK for TCP-samtale. Mange innstillingene i denne samtalen påvirke ytelsen.
-
Deretter en serie med TLS:TLS-trafikk, som er der hvor TLS-håndtrykket og TLS-sertifikatsamtalene finner sted. (Husk at dataene er kryptert via SSL/TLS.)
Alle delene av trafikken er viktige og koblet til, men små deler av sporingen inneholder informasjon som er spesielt viktig med hensyn til feilsøking av ytelse, så vi skal fokusere på disse områdene. Siden vi har gjort nok feilsøking av ytelse i Office 365 hos Microsoft til å samle en liste over de ti vanligste problemene, vil vi dessuten fokusere på disse problemene og hvordan du bruker verktøyene vi har til å luke dem ut.
Hvis du ikke har installert dem allerede, kan du se forslag til flere verktøy nedenfor. Der det er mulig. Vi gir koblinger til installasjonspunktene. Listen inneholder vanlige nettverkssporingsverktøy som Netmon og Wireshark, men bruk et hvilket som helst sporingsverktøy du er fortrolig med, og som du er vant til å filtrere nettverkstrafikk med. Når du tester, må du huske følgende:
-
Lukk nettlesere, og test med bare én leser kjører - dermed reduseres generell trafikken du ta. Gjør det for en mindre trafikk sporing.
-
Tøm DNS Resolver-bufferen på klientdatamaskinen – Da begynner du helt forfra når du starter å registrere, slik at du får en renere sporing.
Noen vanlige problemer
Noen vanlige problemer som kan oppstå og hvordan du finner dem i nettverkssporingen.
|
Hovedproblem |
Verktøy |
Hva du er ute etter |
|
Skalering av TCP-vinduer
|
Netmon Wireshark |
Se etter SYN-SYN/ACK-trafikk i nettverkssporingen. Bruke et filter som tcp.flags.syn == 1i Netmon. Dette filteret er den samme i Wireshark.
Legg merke til at det er en kildeport for hvert SYN-port (SrcPort)-nummer som samsvarer i målporten (DstPort) til den relaterte godkjenningen (SYN/ACK). Utvid først SYN, og deretter den relaterte SYN/ACK, for å se den Windows-skaleringsverdien som brukes av nettverkstilkoblingen.
|
|
Innstillinger for TCP-tid uten aktivitet
|
Netmon Wireshark |
I Netmon ser du i tidsforskyvningsfeltet etter en rundtur. En rundtur er tiden fra klienten sender en forespørsel til tjeneren og mottar et svar tilbake. Kontroller mellom klienten og grensekontrollerpunktet (f.eks. Klient --> Proxy), eller klienten til Office 365 (klient --> Office 365). Du kan se dette i mange typer pakker. Eksempelvis kan kan filteret i Netmon se som .Protocol.IPv4.Address == 10.102.14.112 AND .Protocol.IPv4.Address == 10.201.114.12, eller, i Wireshark, ip.addr == 10.102.14.112 && ip.addr == 10.201.114.12. Tips!:
Hvis det oppstår et problem, forventer du lang tid forskyver skal vises, i dette tilfellet (Outlook Online), spesielt i TLS:TLS-pakker som viser tekstblokk Application Data (for eksempel i Netmon kan du finne programmet verdien SANN via .Protocol.TLS AND Description == "TLS:TLS Rec Layer-1 SSL Application Data"). En problemfri fremdrift i tiden skal vises på tvers av økten. Hvis du ser forsinkelser når du oppdaterer Outlook Online, kan dette skyldes en stor grad av tilbakestiller sendes. |
|
Ventetid/Rundtur-tid
|
Ping PsPing Netmon Wireshark |
Hvis du vil spore ventetid i en sporing, vil du dra nytte av å ha registrert klientdatamaskinens IP-adresse og IP-adressen til DNS-serveren i Office 365. Dette er for å gjøre det enklere å filtrere sporingene. Hvis du kobler deg til via en proxy, trenger du klientdatamaskinens IP-adresse, proxyens/grensekontrollerens IP-adresse og Office 365 DNS-IP-adresse for å gjøre arbeidet lettere. Sender du en ping-forespørsel til outlook.office365.com, får du vite navnet på datasenteret som mottar forespørselen, selv om ping ikke får koblet seg til for å sende de sammenhengende varemerkede ICMP-pakkene. Hvis du bruker PsPing (et gratis verktøy som kan lastes ned), angir porten (443) og kanskje bruker IPv4 (-4), får du en gjennomsnittstid for rundtur for pakker som er sendt. Dette fungerer for andre nettadresser i Office 365-tjenestene, for eksempel psping -4 yourSite.sharepoint.com:443. Du kan faktisk angi en rekke ping-er for å få et større utvalg for gjennomsnittet ditt, prøv noe slikt som: psping -4 -n 20 yourSite-my.sharepoint.com:443. Obs!: PsPing sender ikke ICMP-pakker. Det ping-er med TCP-pakker over en bestemt port, slik at du kan bruke en du vet er åpen. I Office 365, som bruker SSL/TLS, kan du prøve å feste port :443 til PsPing.
Hvis du lastet den langsomme Office 365-siden mens du foretok en nettverkssporing, bør du filtrere en Netmon- eller Wireshark-sporing for DNS. Dette er én av de IP-adressene vi er ute etter. Her er fremgangsmåten for å filtrere Netmon for å få IP-adressen (og se på DNS-ventetid). Dette eksemplet bruker outlook.office365.com, men kan også bruke nettadressen for en SharePoint Online-leier (for eksempel hithere.sharepoint.com).
I neste trinn, enkel å installere og bruke PsPing er verktøyet svært nyttig, både og fordi ICMP blokkeres ofte på brannmurer og PsPing sporer elegant ventetid i millisekunder. PsPing fullfører en TCP-tilkobling til en adresse og port (i vårt tilfelle åpen port 443).
Hvis du går til Office 365 via en proxy-server, er fremgangsmåten litt annerledes. Du må først kjøre PsPing på proxy-serveren for å få en gjennomsnittlig verdi for ventetid i millisekunder til proxyen/grensekontrolleren og tilbake, og deretter kjøre PsPing på proxyen, eller på en datamaskin med direkte Internett-tilkobling for å få den manglende verdien (den til Office 365 og tilbake). Hvis du velger å kjøre PsPing fra proxyen, vil du ha to millisekund-verdier: klientdatamaskinen til proxy-serveren eller grensekontrollerpunktet, og proxy-serveren til Office 365. Og du er ferdig! I hvert fall med å registrere verdier. Hvis du kjører PsPing på en annen klientdatamaskin som har en direkte tilkobling til Internett, det vil si uten proxy, må du to millisekund verdier: klientdatamaskinen proxyserveren eller utgangspunktet og klientdatamaskinen til Office 365. I dette tilfellet trekke fra verdien til klientdatamaskinen proxy-serveren eller grensekontrolleren punkt fra verdien til klientdatamaskinen til Office 365, må du RTT tallene fra klientdatamaskinen proxy-serveren eller grensekontrolleren punktet og fra proxy-serveren eller grensekontrolleren Pek på Offi CE 365. Hvis du imidlertid kan finne en klientdatamaskin på den påvirkede plasseringen som er direkte tilkoblet, eller omgår proxyen, kan du velge å se om problemet reproduseres der til å begynne med, og deretter tester med det. Som vist i en Netmon-sporing de ekstra millisekundene medføre ventetid, hvis det finnes nok av dem i en gitt økt.
Obs!: IP-adressen din kan være annerledes enn IP-adressene som vises her, for eksempel kan ping returnere noe i likhet med 157.56.0.0/16 eller et lignende område. Hvis du vil ha en liste over områder som brukes av Office 365, kan du se Adresser og IP-adresseområder for Office 365. Husk å utvide alle nodene (det er en knapp øverst for dette) hvis du vil søke etter for eksempel 132,245. |
|
Proxy-godkjenning
|
Netmon Wireshark |
Proxy-godkjenning finner sted når en ny TCP-økt må være spun, ofte for å be om filer eller informasjon fra serveren, eller angi informasjon. Du kan for eksempel se proxy-godkjenning rundt HTTP GET eller HTTP POST forespørsler. Hvis du vil se rammer der du er godkjenne forespørsler i sporingen, legge til sammendrag av NTLMSSP kolonnen Netmon og filter for .property.NTLMSSPSummary. Hvis du vil se hvor lang tid tar godkjenningen, kan du legge til tidsdelta-kolonnen. Legge til en kolonne til Netmon:
Selv om du ikke legge til kolonnen, fungerer Netmon-filteret. Men din feilsøking blir mye enklere hvis du kan se hvilke fase av godkjenning du er i. Når ser for forekomster av Proxy-godkjenning, må du huske å studere alle rammer der det er en utfordring NTLM eller et godkjenne meldingen er til stede. Hvis nødvendig, høyreklikker du bestemte typer trafikk og Finn samtaler og > TCP. Vær oppmerksom på tidsdelta verdiene i disse samtaler.
En fire sekunders forsinkelse i proxy-godkjenning i Wireshark. Kolonnen Tidsdelta fra tidligere vist ramme ble opprettet ved å høyreklikke feltet med samme navn i rammedetaljene og velge Legg til som kolonne.
|
|
DNS-ytelse
Tips!: Er du ikke sikker på hvordan klienttilkobling virker i Office 365? Ta en titt på referansedokumentet for klienttilkobling her. |
Netmon Wireshark PsPing |
Analyse av DNS-ytelse er vanligvis en annen jobb en nettverkssporing gjør. Imidlertid er PsPing også nyttig når det gjelder å bekrefte eller utelukke en mulig årsak. DNS-trafikken er basert på TCP- og UDP-forespørsler, og svar er tydelig merket med en ID som bidrar til å finne hvilket svar som tilhører en bestemt forespørsel. Du ser DNS-trafikk for eksempel når SharePoint Online bruker et nettverksnavn eller en nettadresse på en nettside. Som en tommelfingerregel går mesteparten av denne trafikken over UDP, unntatt når du overfører soner. Mest grunnleggende filteret som lar deg se på DNS-trafikk er ganske enkelt dnsi Netmon og Wireshark. Pass på å bruke små bokstaver når du angir filteret. Husk å Tøm DNS resolver-bufferen før du begynner å gjenskape problemet på klientdatamaskinen. For eksempel hvis du har en treg SharePoint Online sidelasting på startsiden, bør du lukke alle nettlesere, åpne en ny nettleser, starter du sporingen, tøm DNS resolver-bufferen og bla deg frem til SharePoint Online-området. Når hele siden løser, bør du stoppe og lagre sporingen.
Du vil slå på tidspunktet forskyvning her. Og det kan være nyttig å legge til kolonnen Tidsdelta i Netmon som du kan gjøre ved å følge denne fremgangsmåten:
Hvis du finner en spørring interessante, bør du vurdere å isolere den ved å høyreklikke spørringen i panelet ramme detaljer, velge Finn samtaler og > DNS. Legg merke til at panelet Nettverkssamtaler hopper høyre til bestemte samtalen i loggen av UDP-trafikk.
Du kan gjøre en kolonne for DNS-tiden i Wireshark. Ta sporingen (eller åpne en sporing) i Wireshark og filtrere etter dns, eller mer effektiviserer dns.time. Klikk på en DNS-spørring, og Utvid Domain Name System (response) detaljene i panelet som viser detaljer. Ser du et felt for klokkeslett (for eksempel [Time: 0.001111100 seconds]. Høyreklikk nå, og velg Bruk som kolonne. Dette gir deg en kolonne med klokkeslett for raskere sortering av sporingen. Klikk på den nye kolonnen du vil sortere etter synkende verdier for å se hvilke DNS-samtale tok den lengste for å løse.
Hvis du vil gjøre flere undersøkelser av DNS-oppløsning tid, kan du prøve en PsPing mot DNS porten som brukes av TCP (for eksempel psping <IP address of DNS server>:53). Ser du fremdeles et problem med ytelsen? Hvis du gjør, deretter er problemet mest sannsynlig skal være en mer omfattende nettverk utstede enn et problem for bestemt DNS-programmet du er finne målgruppen for å gjøre oppløsning. Det er også verdt å nevne, på nytt, at en ping til outlook.office365.com forteller deg hvor DNS-navneløsing for Outlook Online foregår (for eksempel outlook-namnorthwest.office365.com). Hvis problemet ser ut til å være DNS-spesifikt, kan det være nødvendig å kontakte IT-avdelingen for å se nærmere på DNS-konfigurasjoner og DNS-videresendere for å undersøke dette problemet ytterligere. |
|
Proxy-skalerbarhet
Tips!: Trenger du å planlegge for båndbredde fordi du er i ferd med å legge til mange brukere i Office 365? Prøv Plan for bruk av Internett-båndbredde for Office 365. Der finner du båndbreddekalkulatorer. |
Matematikk |
Det finnes ingen nettverkssporing eller feilsøkingsverktøy spesielt for dette. I stedet er den basert på båndbreddeberegninger med gitte begrensninger og andre variabler. |
|
Maksimal segmentstørrelse for TCP
|
Netmon |
TCP Maks maksimumsstørrelsen for segmentet (MSS) er en annen parameter for tre-veis håndtrykk i Nettverkssporingen, som betyr at du finner dataene du trenger i SYN - SYN/ACK-pakke. MSS er egentlig ganske enkelt å se. Åpne alle nettverkssporingene av ytelse du har og finn forbindelsen du er nysgjerrig på, eller som viser ytelsesproblemet. Obs!:
I dette bildet, kan jeg gjøre bruk av den innebygde kolonnen i Netmon som heter TCP-feilsøking.
Den innebygde kolonnen er øverst i Rammedetaljer-panelet. (Hvis du vil bytte tilbake til normalvisning, klikker du Kolonner på nytt, og velger deretter Tidssone.)
Her er en sporing filtrert i Wireshark. Et filter er spesifikk for MSS-verdien (tcp.options.mss). Rammer av SYN, SYN/ACK, ACK handshake kobles nederst i Wireshark tilsvarer Rammedetaljer (så ramme 47 ACK, koblinger til 46 SYN/ACK, koblinger til 43 SYN) til å gjøre denne typen arbeid enklere.
Hvis du trenger å kontrollere Selektiv bekreftelse (neste emne i denne matrisen), ikke lukk sporingen! |
|
Selektiv bekreftelse
|
Netmon |
Selektiv bekreftelse (SACK) er en annen parameter i SYN-SYN/ACK-håndtrykket. Du kan filtrere sporingen for SYN - SYN/ACK på mange måter.
Her er SACK-verdiene slik de kan sees både i Netmon og Wireshark.
|
|
DNS-geolokasjon
Tips!: Vil du vite mer om hvordan klientene kobler seg til Office 365? Se referanseartikkelen Klienttilkobling (og dens nyttige grafikk). |
Ping PsPing |
Forespørsler om navneløsing fra klientens DNS-serverne til Microsoft DNS-servere bør i de fleste tilfeller, resulterer i Microsoft DNS returnere IP-adressen til datasenteret (datasenter). Hva betyr dette for deg? Hvis din hovedkontoret i Bangalore, India, men du er på reise i USA, når leseren sender en forespørsel for Outlook Online, bør DNS-serverne til Microsoft hånd IP-adresser til datasentre i USA – regionale datasenteret. Hvis det kreves en e-post fra Outlook, reise disse dataene på tvers av Microsofts rask ryggraden nettverket mellom datasentre. DNS fungerer raskest når navneløsing utføres så nær brukerens plassering som mulig. Hvis du er i Europa, du vil gå til et Microsoft-DNS i Europa, og (ideelt sett) forholde deg til et datasenter i Europa. Ytelse fra en klient i Europa som går til DNS og et datasenter i USA, vil være langsommere. Kjør Ping-verktøyet mot outlook.office365.com for å bestemme hvor i verden DNS-forespørselen din blir rutet. Hvis du er i Europa, bør du se et svar fra noe i likhet med outlook-emeawest.office365.com. På det amerikanske kontinentet kan du forvente noe i likhet med outlook-namnorthwest.office365.com.
Hvis du vil se ventetidstall for denne tilkoblingen, kan du prøve PsPing til IP-adressen til serveren som returneres av ping.
|
|
Feilsøking av Office 365-programmer |
Netmon HTTPWatch F12-konsoll i nettleseren |
Vi dekker ikke verktøy som brukes i programspesifikk feilsøking i denne nettverksspesifikke artikkelen. Du finner imidlertid ressurser du kan bruke på denne siden. |
Beslektede emner
Administrere Office 365 endepunktene
Feilsøke Office 365-tilkobling
