Office 365 ytelsesjustering ved hjelp av grunnlinjer og ytelseslogg
Det finnes noen enkle måter å kontrollere tilkoblingsytelsen mellom Office 365 og bedriften på, som lar deg etablere en grov grunnlinje for tilkoblingen. Hvis du vet ytelsesloggen for klientdatamaskinens tilkoblinger, kan det hjelpe deg med å oppdage nye problemer tidlig, identifisere og forutse problemer.
Hvis du ikke er vant til å arbeide med ytelsesproblemer, er denne artikkelen utformet for å hjelpe deg med å vurdere noen vanlige spørsmål. Hvordan vet du at problemet du ser er et ytelsesproblem og ikke en Office 365 tjenestehendelse? Hvordan kan du planlegge for god ytelse på lang sikt? Hvordan kan du holde et øye med ytelsen? Hvis teamet eller kundene ser dårlig ytelse mens du bruker Office 365, og du lurer på noen av disse spørsmålene, kan du lese videre.
Viktig
Har du et ytelsesproblem mellom klienten og Office 365 akkurat nå? Følg trinnene som er beskrevet i feilsøkingsplanen for ytelse for Office 365.
Noe du bør vite om Office 365 ytelse
Office 365 bor i et dedikert Microsoft-nettverk med høy kapasitet som overvåkes av automatisering og virkelige mennesker. En del av vedlikehold av Office 365 sky er ytelsesjustering og effektivisering der det er mulig. Siden kunder av Office 365 skyen må koble til over Internett, er det kontinuerlig innsats for å finjustere ytelsen på tvers av Office 365 tjenester også.
Ytelsesforbedringer stopper egentlig aldri i skyen, så det har heller ikke erfaring med å holde skyen sunn og rask. Hvis du har et ytelsesproblem som kobler fra plasseringen din til Office 365, er det best å ikke starte med eller vente på en kundestøttesak. I stedet bør du begynne å undersøke problemet fra innsiden og ut. Det vil se ut som om du starter i nettverket og arbeider deg ut til Office 365. Før du åpner en sak med kundestøtte, kan du samle inn data og utføre handlinger som skal utforske og kanskje løse problemet.
Viktig
Vær oppmerksom på kapasitetsplanlegging og begrensninger i Office 365. Denne informasjonen vil sette deg foran kurven når du prøver å løse et ytelsesproblem. Her er en kobling til tjenestebeskrivelsene for Microsoft 365 og Office 365. Dette er et sentralt knutepunkt, og alle tjenestene som tilbys av Office 365 har en kobling som går til deres egne tjenestebeskrivelser herfra. Det betyr at hvis du trenger å se standardgrensene for SharePoint, for eksempel, klikker du Tjenestebeskrivelse for SharePoint og finner inndelingen SharePoint-begrensninger.
Kontroller at du går inn i feilsøkingen med forståelsen av at ytelsen er en glidende skala. Det handler ikke om å oppnå en idealisert verdi og opprettholde den permanent. Sporadiske oppgaver med høy båndbredde, som å gå om bord i et stort antall brukere, eller å utføre store dataoverføringer, vil være stressende, så planlegg for ytelsespåvirkninger da. Du bør ha en tøff idé om ytelsesmålene dine, men mange variabler spiller inn i ytelsen, så ytelsen varierer.
Feilsøking av ytelse handler ikke om å nå bestemte mål og opprettholde disse tallene på ubestemt tid, det handler om å forbedre eksisterende aktiviteter, gitt alle variablene.
Hvordan ser et ytelsesproblem ut?
Først må du sørge for at det du opplever faktisk er et ytelsesproblem og ikke en tjenestehendelse. Et ytelsesproblem er forskjellig fra en tjenestehendelse i Office 365. Slik skiller du dem fra hverandre:
Tjenestehendelser skjer når selve Office 365-tjenesten har problemer. Du kan se røde eller gule ikoner under Gjeldende tilstand i Administrasjonssenter for Microsoft 365. Du vil kanskje legge merke til at ytelsen på klientdatamaskiner som kobler til Office 365 er treg. Hvis gjeldende tilstand for eksempel rapporterer et rødt ikon og du ser Undersøker ved siden av Exchange, kan du da også få anrop fra personer i organisasjonen som klager over at klientpostbokser ved hjelp av Exchange Online er trege. I så fall er det rimelig å anta at din Exchange Online ytelse var et offer for tjenesteproblemer.
På dette tidspunktet bør du, Office 365 administrator, kontrollere gjeldende tilstand og deretter vise detaljer og logg, ofte, for å holde deg oppdatert om vedlikehold på systemet. Det gjeldende tilstandsinstrumentbordet ble gjort for å oppdatere deg om endringer i og problemer i tjenesten. Notatene og forklaringene som er skrevet til tilstandsloggen, administrator for administrator, er der for å hjelpe deg med å måle og holde deg oppdatert om pågående arbeid.
Et ytelsesproblem er ikke en tjenestehendelse, selv om hendelser kan føre til dårlig ytelse. Et ytelsesproblem ser slik ut:
Det oppstår et ytelsesproblem uansett hva gjeldende tilstand for administrasjonssenteret rapporterer for tjenesten.
En virkemåte som brukes til å flyt, tar lang tid å fullføre eller aldri fullføre.
Du kan replikere problemet også, eller du vet at det skjer hvis du utfører de riktige trinnene.
Hvis problemet er uregelmessig, kan det fremdeles være et mønster. Du vet for eksempel at innen kl. 10:00 får du anrop fra brukere som ikke alltid har tilgang til Office 365. Samtalene avsluttes rundt klokken 12.00.
Denne listen høres sannsynligvis kjent ut. kanskje for kjent. Når du er klar over at det er et ytelsesproblem, blir spørsmålet:«Hva gjør du nå?» Resten av denne artikkelen hjelper deg med å finne ut nøyaktig dette.
Slik definerer og tester du ytelsesproblemet
Ytelsesproblemer oppstår ofte over tid, så det kan være utfordrende å definere det faktiske problemet. Opprett et godt problem med en god idé om problemkontekst, og deretter må du gjentabare testtrinn. Her er noen eksempler på problemutsagn som ikke gir nok informasjon:
Å bytte fra innboksen til kalenderen min pleide å være noe jeg ikke la merke til, og nå er det en kaffepause. Kan du få det til å oppføre seg som før?
Opplasting av filene mine til SharePoint tar evigheter. Hvorfor går det sakte om ettermiddagen, men når som helst, er det raskt? Kan det ikke bare være raskt?
Det er flere store utfordringer i problemutsagnene ovenfor. Spesielt for mange tvetydigheter å håndtere. Eksempel:
Det er uklart hvordan bytte mellom innboks og kalender pleide å fungere på den bærbare datamaskinen.
Når brukeren sier «Kan det ikke bare være raskt», hva er «raskt»?
Hvor lenge er "evig"? Er det flere sekunder? Eller mange minutter? Eller kunne brukeren ta lunsj og handlingen ville ende opp 10 minutter etter at de kom tilbake?
Administratoren og feilsøkingsverktøyet kan ikke være klar over detaljene i problemet fra generelle setninger som disse. De vet for eksempel ikke når problemet startet. Feilsøkingsverktøyet vet kanskje ikke at brukeren jobber hjemmefra, og ser bare treg bytting mens han er på hjemmenettverket. Eller at brukeren kjører andre RAM-intensive programmer på den lokale klienten. Administratorer vet kanskje ikke at brukeren kjører et eldre operativsystem eller ikke har kjørt nylige oppdateringer.
Når brukere rapporterer et ytelsesproblem, er det mye informasjon å samle inn. Det kalles å hente og registrere informasjon for å angi omfang for problemet. Her er en grunnleggende liste over omfang som du kan bruke til å samle inn informasjon om ytelsesproblemer. Denne listen er ikke uttømmende, men det er et sted å starte:
På hvilken dato skjedde problemet, og rundt når på dagen eller natten?
Hva slags klientdatamaskin brukte du, og hvordan kobler den til forretningsnettverket (VPN, Wired, Wireless)?
Jobbet du eksternt eller var du på kontoret?
Prøvde du de samme handlingene på en annen datamaskin og så den samme virkemåten?
Gå gjennom trinnene som gir deg problemer, slik at du kan skrive ned handlingene du utfører.
Hvor langsom i sekunder eller minutter er ytelsen?
Hvor i verden befinner du deg?
Noen av disse spørsmålene er tydeligere enn andre. De fleste vil forstå at et feilsøkingsverktøy trenger de nøyaktige trinnene for å gjenskape problemet. Tross alt, hvordan kan du ellers registrere hva som er galt, og hvordan kan du ellers teste om problemet er løst? Mindre åpenbare er ting som "Hvilken dato og klokkeslett så du problemet?", og "Hvor i verden er du plassert?", informasjon som kan brukes i tandem. Avhengig av når brukeren arbeidet, kan noen timer med tidsforskjell bety at vedlikehold allerede er i gang på deler av firmaets nettverk. Firmaet har for eksempel en hybridimplementering, for eksempel en hybrid SharePoint-Søk, som kan spørre etter søkeindekser i både SharePoint i Microsoft 365 og en lokal SharePoint Server 2013-forekomst, oppdateringer kan være i gang i den lokale farmen. Hvis firmaet er i skyen, kan systemvedlikehold omfatte å legge til eller fjerne nettverksmaskinvare, rulle ut oppdateringer som er for hele firmaet, eller gjøre endringer i DNS eller annen kjerneinfrastruktur.
Når du feilsøker et ytelsesproblem, er det litt som et åsted, du må være presis og observant for å trekke noen konklusjoner fra bevisene. For å gjøre dette, må du få en god problem uttalelse ved å samle bevis. Den bør inkludere datamaskinens kontekst, brukerens kontekst, når problemet startet, og de nøyaktige trinnene som avslørte ytelsesproblemet. Denne problemsetningen bør være, og forbli, den øverste siden i notatene. Ved å gå gjennom problemerklæringen på nytt etter at du har arbeidet med løsningen, utfører du trinnene for å teste og bevise om handlingene du utfører, har løst problemet. Dette er viktig for å vite når arbeidet ditt, der, er gjort.
Vet du hvordan ytelsen pleide å se ut når den var god?
Hvis du er uheldig, vet ingen. Ingen hadde tall. Det betyr at ingen kan svare på det enkle spørsmålet «Om hvor mange sekunder pleide det å ta å hente opp en innboks i Office 365?», eller «Hvor lang tid tok det før lederne hadde et Lync Online-møte?, som er et vanlig scenario for mange bedrifter.
Det som mangler her, er en opprinnelig ytelseslinje.
Opprinnelige planer gir deg en kontekst for ytelsen. Du bør av og til ta en opprinnelig plan til ofte, avhengig av behovene til firmaet. Hvis du er et større firma, kan operasjonsgruppen ta opprinnelige planer for det lokale miljøet ditt allerede. Hvis du for eksempel oppdaterer alle Exchange-serverne den første mandagen i måneden, og alle SharePoint-serverne på den tredje mandagen, har driftsteamet sannsynligvis en liste over oppgaver og scenarier som kjøres etter oppdatering, for å bevise at kritiske funksjoner er operative. Du kan for eksempel åpne innboksen, klikke send og motta og sørge for at mappene oppdateres, eller, i SharePoint, bla gjennom hovedsiden på nettstedet, gå til enterprise-Søk-siden og gjøre et søk som returnerer resultater.
Hvis programmene er i Office 365, kan noen av de mest grunnleggende grunnlinjene du kan måle tiden (i millisekunder) fra en klientdatamaskin i nettverket, til et utgangspunkte eller punktet der du forlater nettverket og går ut til Office 365. Her er noen nyttige opprinnelige planer som du kan undersøke og registrere:
Identifiser enhetene mellom klientdatamaskinen og utgangspunktet, for eksempel proxy-serveren.
Du må kjenne enhetene dine slik at du har kontekst (IP-adresser, enhetstype, et cetera) for ytelsesproblemer som oppstår.
Proxy-servere er vanlige utgående punkter, slik at du kan sjekke nettleseren for å se hvilken proxy-server den er satt til å bruke, hvis aktuelt.
Det finnes tredjepartsverktøy som kan oppdage og tilordne nettverket, men den sikreste måten å kjenne enhetene dine på, er å spørre et medlem av nettverksteamet.
Identifiser Internett-leverandøren ( ISP), skriv ned kontaktinformasjonen deres, og spør hvor mange kretser hvor mye båndbredde du har.
Identifiser ressurser for enhetene mellom klienten og utgangspunktet i firmaet, eller identifiser en nødkontakt å snakke med om nettverksproblemer.
Her er noen opprinnelige planer som enkel testing med verktøy kan beregne for deg:
Tid fra klientdatamaskinen til utgangspunktet i millisekunder
Tid fra utgangspunktet til Office 365 i millisekunder
Plassering i verden av serveren som løser URL-adressene for Office 365 når du blar gjennom
Hastigheten på INTERNETT-leverandørens DNS-oppløsning i millisekunder, inkonsekvenser i pakkeankomst (nettverksjitter), opplastings- og nedlastingstider i millisekunder
Hvis du ikke er kjent med hvordan du utfører disse trinnene, går vi mer i detalj i denne artikkelen.
Hva er en opprinnelig plan?
Du vet virkningen når det går dårlig, men hvis du ikke kjenner de historiske ytelsesdataene, er det ikke mulig å ha en kontekst for hvor ille det kan ha blitt, og når. Så uten en grunnlinje, du mangler nøkkelen ledetråd for å løse puslespillet: bildet på puslespillet boksen. I feilsøking av ytelse trenger du et sammenligningspunkt. Det er ikke vanskelig å ta enkle ytelsesgrunner. Driftsteamet kan få i oppgave å utføre disse etter en tidsplan. La oss for eksempel si at tilkoblingen ser slik ut:
Det betyr at du har sjekket med nettverksteamet og funnet ut at du forlater firmaet for Internett via en proxy-server, og at proxyen håndterer alle forespørslene klientdatamaskinen sender til skyen. I dette tilfellet bør du tegne en forenklet versjon av tilkoblingen som viser alle de mellomliggende enhetene. Nå kan du sette inn verktøy som du kan bruke til å teste ytelsen mellom klienten, utgangspunktet (der du forlater nettverket for Internett) og Office 365 skyen.
Alternativene er oppført som Enkle og Avanserte på grunn av hvor mye ekspertise du trenger for å finne ytelsesdataene. En nettverkssporing vil ta mye tid, sammenlignet med å kjøre kommandolinjeverktøy som PsPing og TraceTCP. Disse to kommandolinjeverktøyene ble valgt fordi de ikke bruker ICMP-pakker, som blokkeres av Office 365, og fordi de gir tid i millisekunder som det tar å forlate klientdatamaskinen, eller proxy-serveren (hvis du har tilgang) og ankommer Office 365. Hvert enkelt hopp fra én datamaskin til en annen vil ende opp med en tidsverdi, og det er flott for grunnlinjer! Like viktig er det at disse kommandolinjeverktøyene lar deg legge til et portnummer på kommandoen, dette er nyttig fordi Office 365 kommuniserer over port 443, som er porten som brukes av Secure Sockets Layer and Transport Layer Security (SSL og TLS). Andre tredjepartsverktøy kan imidlertid være bedre løsninger for din situasjon. Microsoft støtter ikke alle disse verktøyene, så hvis du av en eller annen grunn ikke kan få PsPing og TraceTCP til å fungere, kan du gå videre til en nettverkssporing med et verktøy som Netmon.
Du kan ta en opprinnelig plan før arbeidstiden, på nytt under tung bruk, og deretter på nytt etter arbeidstid. Dette betyr at du kanskje har en mappestruktur som ser litt slik ut til slutt:
Du bør også velge en navnekonvensjon for filene. Her er noen eksempler:
Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal
Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW
Feb_08_2015_2pmEST_PerfBaseline_BADPerf
Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf
Det finnes mange forskjellige måter å gjøre dette på, men det å bruke formatet <dateTime><det som skjer i testen> , er et godt sted å starte. Å være flittig om dette vil hjelpe mye når du prøver å feilsøke problemer senere. Senere kan du si «Jeg tok to spor den 8. februar, én viste god ytelse og én viste dårlig ytelse, slik at vi kan sammenligne dem». Dette er nyttig for feilsøking.
Du må ha en organisert måte å beholde de historiske grunnlinjene på. I dette eksemplet produserte de enkle metodene tre kommandolinjeutdata, og resultatene ble samlet inn som skjermbilder, men du kan ha nettverksopptaksfiler i stedet. Bruk metoden som fungerer best for deg. Lagre de historiske grunnlinjene, og referer til dem på punkter der du legger merke til endringer i virkemåten til onlinetjenester.
Hvorfor samle inn ytelsesdata under en pilot?
Det er ikke bedre tid til å begynne å lage opprinnelige planer enn under en pilot av Office 365-tjenesten. Kontoret kan ha tusenvis av brukere, hundretusener, eller det kan ha fem, men selv med noen få brukere kan du utføre tester for å måle variasjoner i ytelsen. Når det gjelder et stort selskap, kan et representativt utvalg av flere hundre brukere som prøver Office 365 projiseres utover til flere tusen, slik at du vet hvor problemer kan oppstå før de oppstår.
Når det gjelder et lite selskap, hvor ved ombordstigning betyr at alle brukere går til tjenesten samtidig, og det ikke finnes noen pilot, bør du beholde ytelsesmål slik at du har data å vise til alle som kanskje må feilsøke en operasjon med dårlig ytelse. Hvis du for eksempel legger merke til at du plutselig kan gå rundt i bygningen i tiden det tar å laste opp en mellomstor grafikk der det pleide å skje raskt.
Slik samler du inn opprinnelige planer
For alle feilsøkingsplaner må du identifisere disse tingene som et minimum:
Klientdatamaskinen du bruker (typen datamaskin eller enhet, en IP-adresse og handlingene som forårsaket problemet)
Hvor klientdatamaskinen befinner seg i verden (for eksempel om denne brukeren er på et VPN-nettverk, arbeider eksternt eller på firmaets intranett)
Utgående punkt klientdatamaskinen bruker fra nettverket (punktet der trafikken forlater bedriften for en Internett-adresse eller Internett)
Du kan finne ut oppsettet for nettverket fra nettverksadministratoren. Hvis du er på et lite nettverk, kan du ta en titt på enhetene som kobler deg til Internett, og ringe Internett-leverandøren hvis du har spørsmål om oppsettet. Opprett en grafikk av det endelige oppsettet for referansen.
Denne inndelingen er delt inn i enkle kommandolinjeverktøy og -metoder, og mer avanserte verktøyalternativer. Vi tar for oss enkle metoder først. Men hvis du har et ytelsesproblem akkurat nå, bør du hoppe til avanserte metoder og prøve ut handlingsplanen for ytelsesfeilsøking.
Enkle metoder
Målet med disse enkle metodene er å lære å ta, forstå og lagre enkle ytelsesgrunnlinjer over tid, slik at du blir informert om Office 365 ytelse. Her er det enkle diagrammet for enkel, som du har sett før:
Obs!
TraceTCP er inkludert i dette skjermbildet fordi det er et nyttig verktøy for å vise, i millisekunder, hvor lang tid en forespørsel tar å behandle, og hvor mange nettverkshopp, eller tilkoblinger fra én datamaskin til den neste, som forespørselen tar for å nå et mål. TraceTCP kan også gi navnene på servere som brukes under hopp, noe som kan være nyttig for et Microsoft Office 365 feilsøkingsverktøy i kundestøtte. > TraceTCP-kommandoer kan være svært enkle, for eksempel: >tracetcp.exe outlook.office365.com:443> Husk å inkludere portnummeret i kommandoen! >TraceTCP er en gratis nedlasting, men er avhengig av Wincap. Wincap er et verktøy som også brukes og installeres av Netmon. Vi bruker også Netmon i delen avanserte metoder.
Hvis du har flere kontorer, må du også beholde et sett med data fra en klient på hver av disse plasseringene. Denne testen måler ventetid, som i dette tilfellet er en tallverdi som beskriver hvor lang tid det tar mellom en klient som sender en forespørsel til Office 365, og Office 365 å svare på forespørselen. Testingen kommer fra domenet ditt på en klientdatamaskin, og ser ut til å måle en rundtur fra innsiden av nettverket, ut gjennom et utgående punkt, over Internett for å Office 365 og tilbake.
Det finnes flere måter å håndtere utgangspunktet på, i dette tilfellet proxy-serveren. Du kan enten spore fra 1 til 2 og deretter 2 til 3, og deretter legge sammen tallene i millisekunder for å få en endelig totalsum til kanten av nettverket. Du kan også konfigurere tilkoblingen til å omgå proxyen for Office 365 adresser. I et større nettverk med brannmur, omvendt proxy eller en kombinasjon av de to, må du kanskje gjøre unntak på proxy-serveren som tillater trafikk for mange nettadresser. Hvis du vil se listen over endepunkter som brukes av Office 365, kan du se Office 365 URL-adresser og IP-adresseområder. Hvis du har en godkjenningsproxy, begynner du med å teste unntak for følgende:
Port 80 og 443
TCP- og HTTP-er
Connections som er utgående til noen av disse URL-adressene:
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
Alle brukere må ha tillatelse til å få tilgang til disse adressene uten proxy-forstyrrelser eller godkjenning. På et mindre nettverk bør du legge til disse i proxy-forbikoblingslisten i nettleseren.
Hvis du vil legge til disse i listen over proxy-forbikoblinger i Internet Explorer, kan du gå til Verktøy>alternativer>for Internett Connections>LAN-innstillinger>Avansert. Den avanserte fanen er også stedet der du finner proxy-serveren og proxy-serverporten. Det kan hende du må merke av for Bruk en proxy-server for lokalnettet for å få tilgang til Avansert-knappen . Du må kontrollere at Det er merket av for Omgå proxy-server for lokale adresser . Når du velger Avansert, ser du en tekstboks der du kan skrive inn unntak. Skill url-adressene med jokertegn som er oppført ovenfor, med semikolon, for eksempel:
*.microsoftonline.com; *.sharepoint.com
Når du går forbi proxyen, skal du kunne bruke ping eller PsPing direkte på en nettadresse for Office 365. Neste trinn er å teste ping-outlook.office365.com. Eller hvis du bruker PsPing eller et annet verktøy som lar deg angi et portnummer til kommandoen, PsPing mot portal.microsoftonline.com:443 for å se gjennomsnittlig rundturtid i millisekunder.
Rundturtiden, eller RTT, er en tallverdi som måler hvor lang tid det tar å sende en HTTP-forespørsel til en server som outlook.office365.com og få et svar tilbake som bekrefter at serveren vet at du gjorde det. Noen ganger ser du dette forkortet som RTT. Dette bør være en relativt kort tidsperiode.
Du må bruke PSPing eller et annet verktøy som ikke bruker ICMP-pakker som blokkeres av Office 365 for å kunne utføre denne testen.
Slik bruker du PsPing til å få en samlet rundtur i millisekunder direkte fra en nettadresse for Office 365
Kjør en hevet ledetekst ved å fullføre disse trinnene:
Klikk Start.
Skriv inn cmd i boksen Start Søk, og trykk deretter CTRL+SKIFT+ENTER.
Hvis dialogboksen Brukerkontokontroll vises, bekrefter du at handlingen den viser, er den du vil bruke, og deretter klikker du Fortsett.
Gå til mappen der verktøyet (i dette tilfellet PsPing) er installert, og test disse Office 365 URL-adresser:
psping admin.microsoft.com:443
psping microsoft-my.sharepoint.com:443
psping outlook.office365.com:443
psping www.yammer.com:443
Pass på å inkludere portnummeret på 443. Husk at Office 365 fungerer på en kryptert kanal. Hvis du PsPing uten portnummeret, vil forespørselen mislykkes. Når du har pinget den korte listen, kan du se etter gjennomsnittstiden i millisekunder (ms). Det er det du vil spille inn!
Hvis du ikke er kjent med proxy-forbikobling og foretrekker å ta ting trinn for trinn, må du først finne ut navnet på proxy-serveren. Gå til Alternativer for Internett-verktøy>> i Internet Explorer Connections>LAN-innstillinger>Avansert. Avansert-fanen er der du ser proxy-serveren oppført. Ping proxy-serveren ved en ledetekst ved å fullføre denne oppgaven:
Ping proxy-serveren og få en verdi for rundtur i millisekunder for trinn 1 til 2
Kjør en hevet ledetekst ved å fullføre disse trinnene:
Klikk Start.
Skriv inn cmd i boksen Start Søk, og trykk deretter CTRL+SKIFT+ENTER.
Hvis dialogboksen Brukerkontokontroll vises, bekrefter du at handlingen den viser, er den du vil bruke, og deretter klikker du Fortsett.
Skriv inn ping <navnet på proxy-serveren som nettleseren bruker, eller IP-adressen til proxy-serveren> , og trykk deretter ENTER. Hvis du har PsPing eller et annet verktøy installert, kan du velge å bruke dette verktøyet i stedet.
Kommandoen kan se ut som noen av disse eksemplene:
ping ourproxy.ourdomain.industry.business.com
ping 155.55.121.55
ping ourproxy
psping ourproxy.ourdomain.industry.business.com:80
psping 155.55.121.55:80
psping ourproxy:80
- Når sporingen slutter å sende testpakker, får du et lite sammendrag som viser et gjennomsnitt, i millisekunder, og det er verdien du er ute etter. Ta et skjermbilde av ledeteksten og lagre den ved hjelp av navnekonvensjonen. På dette tidspunktet kan det også hjelpe å fylle ut diagrammet med verdien.
Kanskje du har tatt et spor tidlig om morgenen, og klienten kan raskt gå til proxyen (eller hvilken som helst utgående server som går ut til Internett). I dette tilfellet kan tallene se slik ut:
Hvis klientdatamaskinen er en av de få utvalgte med tilgang til proxy-serveren (eller utgående) server, kan du kjøre neste etappe av testen ved å koble til datamaskinen eksternt og kjøre ledeteksten til PsPing til en Office 365 NETTADRESSE derfra. Hvis du ikke har tilgang til datamaskinen, kan du kontakte nettverksressursene for å få hjelp med neste etappe og få nøyaktige tall på den måten. Hvis det ikke er mulig, kan du ta en PsPing mot den aktuelle nettadressen for Office 365 og sammenligne den med PsPing- eller Ping-tiden mot proxy-serveren.
Hvis du for eksempel har 51,84 millisekunder fra klienten til nettadressen for Office 365, og du har 2,8 millisekunder fra klienten til proxyen (eller utgangspunktet), har du 49,04 millisekunder fra utgangspunktet til Office 365. På samme måte, hvis du har en PsPing på 12,25 millisekunder fra klienten til proxyen i løpet av dagens høyde og 62,01 millisekunder fra klienten til nettadressen for Office 365, er gjennomsnittsverdien for proxy-utgående til nettadressen for Office 365 49,76 millisekunder.
Når det gjelder feilsøking, kan det hende du finner noe interessant bare ved å beholde disse grunnlinjene. Hvis du for eksempel finner ut at du vanligvis har omtrent 40 millisekunder til 59 millisekunder ventetid fra proxyen eller utgående punkt til Office 365 NETTADRESSE, og ha en ventetid for klient til proxy eller utgående punkt på ca. 3 millisekunder til 7 millisekunder (avhengig av hvor mye nettverkstrafikk du ser på denne tiden av dagen), vil du sikkert vite at noe er problematisk hvis de tre siste klientene til proxy- eller utgående grunnlinjer viser en ventetid på 45 millisekunder.
Avanserte metoder
Hvis du virkelig vil vite hva som skjer med Internett-forespørslene til Office 365, må du bli kjent med nettverkssporinger. Det spiller ingen rolle hvilke verktøy du foretrekker for disse sporene, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard-verktøyet eller andre, så lenge verktøyet kan registrere og filtrere nettverkstrafikk. I denne delen ser du at det er nyttig å kjøre mer enn ett av disse verktøyene for å få et mer fullstendig bilde av problemet. Når du tester, fungerer noen av disse verktøyene også som proxyer i seg selv. Verktøy som brukes i hjelpeartikkelen, feilsøkingsplan for ytelse for Office 365, omfatter Netmon 3.4, HTTPWatch eller WireShark.
Å ta en grunnlinje for ytelse er den enkle delen av denne metoden, og mange av trinnene er de samme som når du feilsøker et ytelsesproblem. De mer avanserte metodene for å opprette opprinnelige planer for ytelse krever at du tar og lagrer nettverkssporinger. De fleste eksemplene i denne artikkelen bruker SharePoint, men du bør utvikle en liste over vanlige handlinger på tvers av Office 365 tjenester som du abonnerer på for å teste og registrere. Her er et eksempel på en opprinnelig plan:
Opprinnelig liste for SPO - ** Trinn 1: ** Bla gjennom hjemmesiden for SPO-nettstedet, og gjør en nettverkssporing. Lagre sporingen.
Opprinnelig liste for SPO – trinn 2: Søk for en term (for eksempel firmanavnet) via Enterprise Søk og utføre en nettverkssporing. Lagre sporingen.
Opprinnelig liste for SPO – trinn 3: Last opp en stor fil til et SharePoint-dokumentbibliotek og gjør en nettverkssporing. Lagre sporingen.
Opprinnelig liste for SPO – trinn 4: Bla gjennom hjemmesiden for OneDrive-nettstedet, og gjør en nettverkssporing. Lagre sporingen.
Denne listen bør inneholde de viktigste vanlige handlingene som brukere utfører mot SharePoint. Legg merke til at det siste trinnet, for å spore å gå til OneDrive, bygger inn en sammenligning mellom belastningen på SharePoint-hjemmesiden (som ofte tilpasses av firmaer) og OneDrive-hjemmesiden, som sjelden tilpasses. Dette er en grunnleggende test når det gjelder et SharePoint-område som lastes inn sakte. Du kan bygge en oversikt over denne forskjellen i testingen.
Hvis du er midt i et ytelsesproblem, er mange av trinnene de samme som når du utfører en opprinnelig plan. Nettverkssporinger blir kritiske, så vi skal håndtere hvordan du tar de viktige sporene videre.
For å takle et ytelsesproblem, må du nå ta et spor når du opplever ytelsesproblemet. Du må ha de riktige verktøyene tilgjengelig for å samle logger, og du trenger en handlingsplan, det vil si en liste over feilsøkingshandlinger som skal utføres for å samle inn den beste informasjonen du kan. Det første du må gjøre er å registrere datoen og klokkeslettet for testen, slik at filene kan lagres i en mappe som gjenspeiler tidsberegningen. Deretter kan du begrense til selve problemtrinnene. Dette er de nøyaktige trinnene du skal bruke til testing. Ikke glem det grunnleggende: Hvis problemet bare er med Outlook, må du passe på å registrere at problemvirkemåten bare skjer i én Office 365 tjeneste. Hvis du begrenser omfanget av dette problemet, kan du fokusere på noe du kan løse.