Office 365-prestatieafstemming met behulp van basislijnen en prestatiegeschiedenis
Er zijn enkele eenvoudige manieren om de verbindingsprestaties tussen Office 365 en uw bedrijf te controleren, zodat u een ruwe basislijn van uw connectiviteit kunt vaststellen. Als u de prestatiegeschiedenis van uw clientcomputerverbindingen kent, kunt u nieuwe problemen vroegtijdig detecteren, problemen identificeren en voorspellen.
Als u niet gewend bent aan prestatieproblemen te werken, is dit artikel ontworpen om u te helpen bij het overwegen van enkele veelvoorkomende vragen. Hoe weet u of het probleem dat u ziet een prestatieprobleem is en niet een Office 365 service-incident? Hoe kunt u goede prestaties op lange termijn plannen? Hoe kunt u de prestaties in de gaten houden? Als uw team of klanten trage prestaties zien tijdens het gebruik van Office 365 en u zich afvraagt over een van deze vragen, lees dan verder.
Belangrijk
Hebt u nu een prestatieprobleem tussen uw client en Office 365? Volg de stappen die worden beschreven in het prestatieplan voor Office 365.
Iets wat u moet weten over Office 365 prestaties
Office 365 zich in een toegewezen Microsoft-netwerk met hoge capaciteit bevindt dat wordt bewaakt door automatisering en echte mensen. Onderdeel van het onderhouden van de Office 365 cloud is het afstemmen en stroomlijnen van prestaties waar mogelijk. Omdat clients van de Office 365 cloud verbinding moeten maken via internet, wordt er ook voortdurend gewerkt aan het verfijnen van de prestaties van Office 365 services.
Prestatieverbeteringen stoppen nooit echt in de cloud, dus ook ervaring met het gezond en snel houden van de cloud. Als u een prestatieprobleem hebt met het verbinden van vanaf uw locatie met Office 365, kunt u het beste niet beginnen met of wachten op een ondersteuningsaanvraag. In plaats daarvan moet u beginnen met het onderzoeken van het probleem van 'de binnenkant'. Dat wil gezegd, begin binnen uw netwerk en werk uw weg naar Office 365. Voordat u een aanvraag opent bij Ondersteuning, kunt u gegevens verzamelen en acties ondernemen om het probleem te verkennen en mogelijk op te lossen.
Belangrijk
Houd rekening met capaciteitsplanning en limieten in Office 365. Met deze informatie loopt u voor op de curve wanneer u een prestatieprobleem probeert op te lossen. Hier volgt een koppeling naar de servicebeschrijvingen van Microsoft 365 en Office 365. Dit is een centrale hub en alle services die door Office 365 worden aangeboden, hebben een koppeling naar hun eigen servicebeschrijvingen. Als u bijvoorbeeld de standaardlimieten voor SharePoint wilt zien, klikt u op SharePoint-servicebeschrijving en zoekt u de sectie SharePoint-limieten.
Zorg ervoor dat u bij het oplossen van problemen rekening houdt met het besef dat de prestaties een glijdende schaal zijn. Het gaat niet om het bereiken van een geïdealiseerde waarde en het permanent onderhouden ervan. Af en toe taken met hoge bandbreedte, zoals het instappen van een groot aantal gebruikers of het uitvoeren van grote gegevensmigraties, zijn stressvol, dus plan dan de gevolgen voor de prestaties. U moet een globaal idee hebben van uw prestatiedoelen, maar veel variabelen spelen een rol bij de prestaties, dus de prestaties variëren.
Prestatieproblemen oplossen gaat niet over het behalen van specifieke doelen en het voor onbepaalde tijd behouden van deze getallen, het gaat om het verbeteren van bestaande activiteiten, gezien alle variabelen.
Hoe ziet een prestatieprobleem eruit?
Eerst moet u ervoor zorgen dat wat u ondervindt inderdaad een prestatieprobleem is en geen service-incident. Een prestatieprobleem verschilt van een service-incident in Office 365. U kunt ze als volgt uit elkaar houden.
Service-incidenten treden op wanneer de Office 365-service zelf problemen ondervindt. Mogelijk ziet u rode of gele pictogrammen onder Huidige status in de Microsoft 365-beheercentrum. Mogelijk merkt u dat de prestaties op clientcomputers die verbinding maken met Office 365 traag zijn. Als huidige status bijvoorbeeld een rood pictogram rapporteert en u Onderzoekt ziet naast Exchange, kunt u ook oproepen krijgen van mensen in uw organisatie die klagen dat clientpostvakken met behulp van Exchange Online traag zijn. In dat geval is het redelijk om ervan uit te gaan dat uw Exchange Online prestaties het slachtoffer waren van serviceproblemen.
Op dit moment moet u, de Office 365-beheerder, Huidige status controleren en vervolgens vaak details en geschiedenis weergeven om op de hoogte te blijven van onderhoud aan het systeem. Het huidige statusdashboard is gemaakt om u op de hoogte te houden van wijzigingen in en problemen in de service. De notities en uitleg die zijn geschreven naar de statusgeschiedenis, beheerder naar beheerder, zijn er om u te helpen meten en om u op de hoogte te houden van lopende werkzaamheden.
Een prestatieprobleem is geen service-incident, ook al kunnen incidenten trage prestaties veroorzaken. Een prestatieprobleem ziet er als volgt uit:
Er treedt een prestatieprobleem op, ongeacht wat de huidige status van het beheercentrum rapporteert voor de service.
Een gedrag dat voorheen stroomde, duurt lang of nooit voltooid.
U kunt het probleem ook repliceren of weten dat het gebeurt als u de juiste reeks stappen uitvoert.
Als het probleem af en toe optreedt, kan er nog steeds een patroon zijn. U weet bijvoorbeeld dat u om 10:00 uur wordt gebeld door gebruikers die niet altijd toegang hebben tot Office 365. De oproepen eindigen rond het middaguur.
Deze lijst klinkt waarschijnlijk bekend; misschien te bekend. Zodra u weet dat het een prestatieprobleem is, wordt de vraag: "Wat gaat u nu doen?" De rest van dit artikel helpt u precies dat te bepalen.
Het prestatieprobleem definiëren en testen
Prestatieproblemen treden vaak in de loop van de tijd op, dus het kan lastig zijn om het werkelijke probleem te definiëren. Creatie een goede probleemverklaring met een goed idee van de context van het probleem en vervolgens moet u herhaalbare teststappen uitvoeren. Hier volgen enkele voorbeelden van probleeminstructies die onvoldoende informatie bieden:
Het overschakelen van mijn Postvak IN naar mijn agenda was iets wat ik niet zag, en nu is het een koffiepauze. Kun je het laten doen zoals het vroeger was?
Het uploaden van mijn bestanden naar SharePoint duurt eeuwig. Waarom is het 's middags traag, maar op een andere keer is het snel? Kan het niet gewoon snel zijn?
De bovenstaande probleeminstructies bieden verschillende grote uitdagingen. Met name te veel dubbelzinnigheden om mee om te gaan. Bijvoorbeeld:
Het is onduidelijk hoe het schakelen tussen Postvak IN en Agenda vroeger op de laptop deed.
Wanneer de gebruiker zegt: 'Kan het niet gewoon snel zijn', wat is dan 'snel'?
Hoe lang is 'forever'? Is dat een paar seconden? Of veel minuten? Of kan de gebruiker lunchen en de actie zou 10 minuten na teruggaan zijn voltooid?
De beheerder en probleemoplosser kunnen niet op de hoogte zijn van de details van het probleem uit algemene instructies zoals deze. Ze weten bijvoorbeeld niet wanneer het probleem is begonnen. De probleemoplosser weet mogelijk niet dat de gebruiker thuis werkt en ziet alleen traag schakelen terwijl hij of zij zich op het thuisnetwerk bevindt. Of dat de gebruiker andere RAM-intensieve toepassingen uitvoert op de lokale client. Beheerders weten mogelijk niet dat de gebruiker een ouder besturingssysteem uitvoert of geen recente updates heeft uitgevoerd.
Wanneer gebruikers een prestatieprobleem melden, is er veel informatie te verzamelen. Het ophalen en opnemen van informatie wordt het probleem verkennen genoemd. Hier volgt een eenvoudige bereiklijst die u kunt gebruiken om informatie te verzamelen over prestatieproblemen. Deze lijst is niet volledig, maar het is een plek om te beginnen:
Op welke datum is het probleem opgetreden en rond welk tijdstip van de dag of nacht?
Welk type clientcomputer gebruikte u en hoe maakt deze verbinding met het bedrijfsnetwerk (VPN, bekabeld, draadloos)?
Werkte u op afstand of was u op kantoor?
Hebt u dezelfde acties op een andere computer geprobeerd en hetzelfde gedrag gezien?
Doorloop de stappen die u de moeite geven, zodat u de acties kunt schrijven die u onderneemt.
Hoe traag in seconden of minuten zijn de prestaties?
Waar in de wereld ben je gevestigd?
Sommige van deze vragen zijn duidelijker dan andere. De meeste mensen zullen begrijpen dat een probleemoplosser de exacte stappen nodig heeft om het probleem te reproduceren. Hoe kunt u immers anders vastleggen wat er mis is en hoe kunt u anders testen of het probleem is opgelost? Minder voor de hand liggend zijn zaken als 'Welke datum en tijd hebt u het probleem gezien?' en 'Waar ter wereld bevindt u zich?', informatie die gelijktijdig kan worden gebruikt. Afhankelijk van wanneer de gebruiker werkte, kan een paar uur tijdsverschil betekenen dat er al onderhoud wordt uitgevoerd op delen van het netwerk van uw bedrijf. Uw bedrijf heeft bijvoorbeeld een hybride implementatie, zoals een hybride SharePoint-Search, waarmee zoekindexen in zowel SharePoint in Microsoft 365 als een on-premises SharePoint Server 2013-exemplaar kunnen worden opgevraagd. Er worden mogelijk updates uitgevoerd in de on-premises farm. Als uw bedrijf zich helemaal in de cloud bevindt, kan systeemonderhoud bestaan uit het toevoegen of verwijderen van netwerkhardware, het implementeren van updates voor het hele bedrijf of het aanbrengen van wijzigingen in DNS of een andere kerninfrastructuur.
Wanneer u een prestatieprobleem wilt oplossen, lijkt het een beetje op een plaats delict. U moet nauwkeurig en oplettend zijn om conclusies te trekken uit het bewijs. Om dit te doen, moet u een goede probleemstelling krijgen door bewijs te verzamelen. Dit moet de context van de computer, de context van de gebruiker, het moment waarop het probleem is begonnen en de exacte stappen die het prestatieprobleem hebben blootgelegd, bevatten. Deze probleemverklaring moet de bovenste pagina in uw notities zijn en blijven. Door de probleemverklaring opnieuw te doorlopen nadat u aan de oplossing hebt gewerkt, voert u de stappen uit om te testen en te bewijzen of de acties die u uitvoert het probleem hebben opgelost. Dit is essentieel om te weten wanneer uw werk, daar, is voltooid.
Weet u hoe prestaties er vroeger uitzagen als het goed was?
Als je pech hebt, weet niemand het. Niemand had cijfers. Dat betekent dat niemand een antwoord kan geven op de eenvoudige vraag 'Hoeveel seconden duurde het om een Postvak IN in Office 365 te openen?', of 'Hoe lang duurde het toen de leidinggevenden een Lync Online-vergadering hadden?'. Dit is een veelvoorkomend scenario voor veel bedrijven.
Wat hier ontbreekt, is een prestatiebasislijn.
Basislijnen bieden u een context voor uw prestaties. U moet van tijd tot tijd een basislijn nemen, afhankelijk van de behoeften van uw bedrijf. Als u een groter bedrijf bent, kan uw Operations-team al basislijnen gebruiken voor uw on-premises omgeving. Als u bijvoorbeeld alle Exchange-servers op de eerste maandag van de maand patcht en al uw SharePoint-servers op de derde maandag, heeft uw Operations-team waarschijnlijk een lijst met taken en scenario's die na het patchen worden uitgevoerd om te bewijzen dat kritieke functies operationeel zijn. Bijvoorbeeld door het Postvak IN te openen, op Verzenden/ontvangen te klikken en ervoor te zorgen dat de mappen worden bijgewerkt, of in SharePoint door de hoofdpagina van de site te bladeren, naar de ondernemingspagina Search pagina te gaan en een zoekopdracht uit te voeren die resultaten retourneert.
Als uw toepassingen zich in Office 365 bevinden, kunt u enkele van de meest fundamentele basislijnen meten van de tijd (in milliseconden) van een clientcomputer in uw netwerk naar een uitgaand punt of het punt waar u uw netwerk verlaat en naar Office 365 gaat. Hier volgen enkele nuttige basislijnen die u kunt onderzoeken en vastleggen:
Identificeer de apparaten tussen uw clientcomputer en uw uitgaand punt, bijvoorbeeld uw proxyserver.
U moet uw apparaten kennen, zodat u context (IP-adressen, type apparaat, enzovoort) hebt voor prestatieproblemen die zich voordoen.
Proxyservers zijn algemene uitgangspunten, dus u kunt uw webbrowser controleren om te zien welke proxyserver deze moet gebruiken, indien van toepassing.
Er zijn hulpprogramma's van derden die uw netwerk kunnen detecteren en toewijzen, maar de veiligste manier om uw apparaten te kennen, is door een lid van uw netwerkteam te vragen.
Identificeer uw internetprovider (ISP), noteer hun contactgegevens en vraag hoeveel circuits u hebt hoeveel bandbreedte u hebt.
Identificeer binnen uw bedrijf resources voor de apparaten tussen uw client en het uitgaand punt, of identificeer een contactpersoon voor noodgevallen om te praten over netwerkproblemen.
Hier volgen enkele basislijnen die eenvoudig testen met hulpprogramma's voor u kunnen berekenen:
Tijd van uw clientcomputer naar uw uitgaand punt in milliseconden
Tijd van uw uitgaand punt naar Office 365 in milliseconden
Locatie in de wereld van de server die de URL's voor Office 365 oplost wanneer u bladert
De snelheid van de DNS-resolutie van uw internetprovider in milliseconden, inconsistenties in de aankomst van pakketten (netwerk-jitter), upload- en downloadtijden in milliseconden
Als u niet bekend bent met het uitvoeren van deze stappen, gaan we dieper in op dit artikel.
Wat is een basislijn?
U weet wat de impact is wanneer het slecht gaat, maar als u uw historische prestatiegegevens niet kent, is het niet mogelijk om een context te hebben voor hoe slecht het kan zijn geworden en wanneer. Dus zonder basislijn mist u de belangrijkste aanwijzing om de puzzel op te lossen: de afbeelding op de puzzeldoos. Bij het oplossen van prestatieproblemen hebt u een vergelijkingspunt nodig. Eenvoudige prestatiebasislijnen zijn niet moeilijk te nemen. Uw Operations-team kan worden belast met het uitvoeren van deze taken volgens een schema. Stel dat uw verbinding er als volgt uitziet:
Dit betekent dat u uw netwerkteam hebt gecontroleerd en erachter bent gekomen dat u uw bedrijf verlaat voor internet via een proxyserver en dat deze proxy alle aanvragen verwerkt die uw clientcomputer naar de cloud verzendt. In dit geval moet u een vereenvoudigde versie van uw verbinding tekenen waarin alle tussenliggende apparaten worden vermeld. Voeg nu hulpprogramma's in waarmee u de prestaties kunt testen tussen de client, het uitgaand punt (waar u uw netwerk verlaat voor internet) en de Office 365 cloud.
De opties worden weergegeven als Eenvoudig en Geavanceerd vanwege de hoeveelheid expertise die u nodig hebt om de prestatiegegevens te vinden. Een netwerktracering kost veel tijd in vergelijking met het uitvoeren van opdrachtregelprogramma's zoals PsPing en TraceTCP. Deze twee opdrachtregelprogramma's zijn gekozen omdat ze geen ICMP-pakketten gebruiken, die worden geblokkeerd door Office 365, en omdat ze de tijd in milliseconden geven die nodig is om de clientcomputer of proxyserver (als u toegang hebt) te verlaten en op Office 365 te komen. Elke afzonderlijke hop van de ene computer naar de andere krijgt uiteindelijk een tijdwaarde en dat is handig voor basislijnen! Net zo belangrijk is dat u met deze opdrachtregelprogramma's een poortnummer aan de opdracht kunt toevoegen. Dit is handig omdat Office 365 communiceert via poort 443, de poort die wordt gebruikt door Secure Sockets Layer en Transport Layer Security (SSL en TLS). Andere hulpprogramma's van derden kunnen echter betere oplossingen zijn voor uw situatie. Microsoft biedt geen ondersteuning voor al deze hulpprogramma's, dus als u psPing en TraceTCP om de een of andere reden niet kunt laten werken, gaat u verder met een netwerktracering met een hulpprogramma zoals Netmon.
U kunt een basislijn nemen voor kantooruren, opnieuw tijdens intensief gebruik en vervolgens opnieuw na kantooruren. Dit betekent dat u mogelijk een mapstructuur hebt die er uiteindelijk ongeveer als volgt uitziet:
U moet ook een naamconventie voor uw bestanden kiezen. Dit zijn enkele voorbeelden:
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
Er zijn veel verschillende manieren om dit te doen, maar met behulp van de notatie <dateTime><is wat er in de test> gebeurt een goede plek om te beginnen. Dit helpt veel als u later problemen probeert op te lossen. Later kun je zeggen: "Ik heb twee traceringen genomen op 8 februari, één toonde goede prestaties en één slechte, zodat we ze kunnen vergelijken". Dit is handig voor het oplossen van problemen.
U moet een georganiseerde manier hebben om uw historische basislijnen te behouden. In dit voorbeeld hebben de eenvoudige methoden drie opdrachtregeluitvoer geproduceerd en zijn de resultaten verzameld als schermopnamen, maar mogelijk hebt u in plaats daarvan netwerkopnamebestanden. Gebruik de methode die het beste bij u past. Sla uw historische basislijnen op en verwijs ernaar op punten waarop u wijzigingen in het gedrag van onlineservices ziet.
Waarom prestatiegegevens verzamelen tijdens een testfase?
Er is geen betere tijd om te beginnen met het maken van basislijnen dan tijdens een testfase van de Office 365-service. Uw kantoor kan duizenden, honderdduizenden of vijf gebruikers hebben, maar zelfs met een paar gebruikers kunt u tests uitvoeren om prestatiefluctuaties te meten. In het geval van een groot bedrijf kan een representatieve steekproef van enkele honderden gebruikers die Office 365 uitvoeren, worden geprojecteerd naar enkele duizenden, zodat u weet waar zich problemen kunnen voordoen voordat ze zich voordoen.
In het geval van een klein bedrijf, waarbij onboarding betekent dat alle gebruikers tegelijkertijd naar de service gaan en er geen testfase is, behoudt u prestatiemetingen, zodat u gegevens hebt die moeten worden weergegeven aan iedereen die mogelijk een slecht uitgevoerde bewerking moet oplossen. Als u bijvoorbeeld merkt dat u plotseling door uw gebouw kunt lopen in de tijd die nodig is om een middelgrote afbeelding te uploaden waar het vroeger snel gebeurde.
Basislijnen verzamelen
Voor alle probleemoplossingsplannen moet u minimaal deze dingen identificeren:
De clientcomputer die u gebruikt (het type computer of apparaat, een IP-adres en de acties die het probleem hebben veroorzaakt)
Waar de clientcomputer zich in de wereld bevindt (bijvoorbeeld of deze gebruiker op een VPN naar het netwerk werkt, op afstand werkt of op het bedrijfsintranet)
Het uitgaand punt dat de clientcomputer gebruikt vanuit uw netwerk (het punt waarop verkeer uw bedrijf verlaat voor een internetprovider of internet)
U kunt de indeling van uw netwerk vinden bij de netwerkbeheerder. Als u zich in een klein netwerk bevindt, bekijkt u de apparaten die verbinding maken met internet en neemt u contact op met uw internetprovider als u vragen hebt over de indeling. Creatie een afbeelding van de uiteindelijke indeling ter referentie.
Deze sectie is onderverdeeld in eenvoudige opdrachtregelprogramma's en -methoden en meer geavanceerde hulpprogramma's. We behandelen eerst eenvoudige methoden. Maar als u nu een prestatieprobleem hebt, moet u naar geavanceerde methoden gaan en het voorbeeld van een actieplan voor prestatieproblemen uitproberen.
Eenvoudige methoden
Het doel van deze eenvoudige methoden is om eenvoudige prestatiebasislijnen in de loop van de tijd te leren nemen, begrijpen en op de juiste manier op te slaan, zodat u op de hoogte bent van Office 365 prestaties. Dit is het eenvoudige diagram voor simple, zoals u eerder hebt gezien:
Opmerking
TraceTCP is opgenomen in deze schermafbeelding omdat het een handig hulpmiddel is om in milliseconden aan te geven hoe lang een aanvraag duurt om te verwerken en hoeveel netwerkhops of verbindingen van de ene computer naar de volgende, die de aanvraag nodig heeft om een bestemming te bereiken. TraceTCP kan ook de namen van servers geven die tijdens hops worden gebruikt. Dit kan handig zijn voor een Microsoft Office 365 probleemoplosser in Ondersteuning. > TraceTCP-opdrachten kunnen heel eenvoudig zijn, zoals: >tracetcp.exe outlook.office365.com:443> Vergeet niet om het poortnummer op te nemen in de opdracht! >TraceTCP is gratis te downloaden, maar is afhankelijk van Wincap. Wincap is een hulpprogramma dat ook wordt gebruikt en geïnstalleerd door Netmon. We gebruiken Netmon ook in de sectie geavanceerde methoden.
Als u meerdere kantoren hebt, moet u ook een set gegevens van een client op elk van deze locaties bewaren. Deze test meet latentie, in dit geval een getalwaarde die de hoeveelheid tijd beschrijft tussen het verzenden van een aanvraag naar Office 365 en Office 365 reageert op de aanvraag. De test vindt zijn oorsprong in uw domein op een clientcomputer en kijkt naar het meten van een retour vanuit uw netwerk, via een uitgaand punt, via internet naar Office 365 en terug.
Er zijn een aantal manieren om met het uitgaand punt om te gaan, in dit geval de proxyserver. U kunt traceren van 1 tot 2 en vervolgens 2 tot 3 en vervolgens de getallen in milliseconden optellen om een definitief totaal aan de rand van uw netwerk te krijgen. U kunt ook de verbinding configureren om de proxy voor Office 365-adressen te omzeilen. In een groter netwerk met een firewall, omgekeerde proxy of een combinatie van de twee moet u mogelijk uitzonderingen maken op de proxyserver waardoor verkeer voor veel URL's kan worden doorgegeven. Zie OFFICE 365 URL's en IP-adresbereiken voor de lijst met eindpunten die door Office 365 worden gebruikt. Als u een verificatieproxy hebt, test u eerst uitzonderingen voor het volgende:
Poorten 80 en 443
TCP en HTTPs
Connections die uitgaand zijn naar een van deze URL's:
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
Alle gebruikers moeten toegang krijgen tot deze adressen zonder tussenkomst van proxy's of verificatie. In een kleiner netwerk moet u deze toevoegen aan de lijst voor het omzeilen van proxy's in uw webbrowser.
Als u deze wilt toevoegen aan de lijst voor het omzeilen van proxy's in Internet Explorer, gaat u naar Extra>Internetopties>Connections>LAN-instellingen>Geavanceerd. Op het tabblad Geavanceerd vindt u ook uw proxyserver en proxyserverpoort. Mogelijk moet u het selectievakje Een proxyserver voor uw LAN gebruiken inschakelen om toegang te krijgen tot de knop Geavanceerd . Zorg ervoor dat Proxyserver voor lokale adressen overslaan is ingeschakeld. Zodra u Geavanceerd hebt geselecteerd, ziet u een tekstvak waarin u uitzonderingen kunt invoeren. Scheid de url's met jokertekens die hierboven worden vermeld met puntkomma's, bijvoorbeeld:
*.microsoftonline.com; *.sharepoint.com
Zodra u uw proxy hebt omzeild, moet u ping of PsPing rechtstreeks op een Office 365 URL kunnen gebruiken. De volgende stap is het testen van ping outlook.office365.com. Of, als u PsPing of een ander hulpprogramma gebruikt waarmee u een poortnummer kunt opgeven voor de opdracht, psPing tegen portal.microsoftonline.com:443 om de gemiddelde retourtijd in milliseconden te bekijken.
De retourtijd, of RTT, is een getalwaarde die meet hoe lang het duurt om een HTTP-aanvraag te verzenden naar een server zoals outlook.office365.com en een antwoord terug te krijgen dat bevestigt dat de server weet dat u het hebt gedaan. U ziet dit soms afgekort als RTT. Dit moet een relatief korte tijd zijn.
U moet PSPing of een ander hulpprogramma gebruiken dat geen ICMP-pakketten gebruikt die worden geblokkeerd door Office 365 om deze test uit te voeren.
PsPing gebruiken om een totale retourtijd in milliseconden rechtstreeks vanuit een Office 365 URL op te halen
Voer een opdrachtprompt met verhoogde bevoegdheid uit door deze stappen uit te voeren:
Klik op Start.
Typ cmd in het vak Start Search en druk op Ctrl+Shift+Enter.
Als het dialoogvenster Gebruikersaccountbeheer wordt weergegeven, controleert u of de actie die wordt weergegeven, is wat u wilt en klikt u vervolgens op Doorgaan.
Navigeer naar de map waarin het hulpprogramma (in dit geval PsPing) is geïnstalleerd en test deze Office 365 URL's:
psping admin.microsoft.com:443
psping microsoft-my.sharepoint.com:443
psping outlook.office365.com:443
psping www.yammer.com:443
Zorg ervoor dat u het poortnummer 443 opneemt. Houd er rekening mee dat Office 365 werkt op een versleuteld kanaal. Als u PsPing zonder het poortnummer hebt, mislukt uw aanvraag. Zodra u uw korte lijst hebt gepingt, zoekt u naar de gemiddelde tijd in milliseconden (ms). Dat is wat u wilt opnemen!
Als u niet bekend bent met het omzeilen van proxy's en het liever stap voor stap doet, moet u eerst de naam van uw proxyserver achterhalen. Ga in Internet Explorer naar Extra>Internetopties>Connections>LAN-instellingen>Geavanceerd. Op het tabblad Geavanceerd ziet u de proxyserver. Ping die proxyserver bij een opdrachtprompt door deze taak te voltooien:
De proxyserver pingen en een retourwaarde in milliseconden ophalen voor fase 1 tot en met 2
Voer een opdrachtprompt met verhoogde bevoegdheid uit door deze stappen uit te voeren:
Klik op Start.
Typ cmd in het vak Start Search en druk op Ctrl+Shift+Enter.
Als het dialoogvenster Gebruikersaccountbeheer wordt weergegeven, controleert u of de actie die wordt weergegeven, is wat u wilt en klikt u vervolgens op Doorgaan.
Typ ping <de naam van de proxyserver die uw browser gebruikt, of het IP-adres van de proxyserver> en druk vervolgens op Enter. Als u PsPing of een ander hulpprogramma hebt geïnstalleerd, kunt u ervoor kiezen om dat hulpprogramma in plaats daarvan te gebruiken.
Uw opdracht kan eruitzien als een van deze voorbeelden:
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
- Wanneer de tracering stopt met het verzenden van testpakketten, krijgt u een kleine samenvatting met een gemiddelde, in milliseconden, en dat is de waarde die u zoekt. Maak een schermopname van de prompt en sla deze op met uw naamconventie. Op dit punt kan het ook helpen om het diagram in te vullen met de waarde.
Misschien hebt u in de vroege ochtend een tracering uitgevoerd en heeft uw client snel toegang tot de proxy (of een andere uitgaande server die naar internet wordt afgesloten). In dit geval kunnen uw getallen er als volgt uitzien:
Als uw clientcomputer een van de weinige is met toegang tot de proxyserver (of uitgaande server), kunt u de volgende stap van de test uitvoeren door op afstand verbinding te maken met die computer en de opdrachtprompt uit te voeren naar PsPing naar een Office 365 URL van daaruit. Als u geen toegang hebt tot die computer, kunt u contact opnemen met uw netwerkbronnen voor hulp bij de volgende stap en exacte nummers op die manier verkrijgen. Als dat niet mogelijk is, neemt u een PsPing op basis van de Office 365 URL in kwestie en vergelijkt u deze met de PsPing- of Ping-tijd op uw proxyserver.
Als u bijvoorbeeld 51,84 milliseconden van de client naar de Office 365 URL hebt en u 2,8 milliseconden van de client naar de proxy (of uitgaand punt) hebt, hebt u 49,04 milliseconden van de uitgaande naar Office 365. Als u een PsPing hebt van 12,25 milliseconden van de client naar de proxy tijdens de hoogte van de dag en 62,01 milliseconden van de client naar de Office 365 URL, is uw gemiddelde waarde voor de proxy-uitgang naar de Office 365 URL 49,76 milliseconden.
Wat betreft het oplossen van problemen vindt u misschien iets interessants door deze basislijnen te bewaren. Als u bijvoorbeeld merkt dat u over het algemeen ongeveer 40 milliseconden tot 59 milliseconden latentie hebt van de proxy of uitgaand verkeer naar de url van de Office 365, en een client naar proxy of uitgaand punt latentie van ongeveer 3 milliseconden tot 7 milliseconden hebben (afhankelijk van de hoeveelheid netwerkverkeer dat u op dat moment van de dag ziet) dan weet u zeker dat er iets problematisch is als uw laatste drie client naar proxy of uitgaande basislijnen een latentie van 45 milliseconden.
Geavanceerde methoden
Als u echt wilt weten wat er gebeurt met uw internetaanvragen om te Office 365, moet u vertrouwd raken met netwerktraceringen. Het maakt niet uit welke hulpprogramma's u wilt gebruiken voor deze traceringen, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard-hulpprogramma of andere hulpprogramma's, zolang dat hulpprogramma netwerkverkeer kan vastleggen en filteren. In deze sectie ziet u dat het handig is om meer dan een van deze hulpprogramma's uit te voeren om een vollediger beeld van het probleem te krijgen. Tijdens het testen fungeren sommige van deze hulpprogramma's ook als proxy's. Hulpprogramma's die worden gebruikt in het begeleidende artikel Prestatieplan voor Office 365, zijn Netmon 3.4, HTTPWatch of WireShark.
Het nemen van een prestatiebasislijn is het eenvoudige onderdeel van deze methode en veel van de stappen zijn hetzelfde als wanneer u een prestatieprobleem oplost. Voor de geavanceerdere methoden voor het maken van basislijnen voor prestaties moet u netwerktraceringen nemen en opslaan. De meeste voorbeelden in dit artikel maken gebruik van SharePoint, maar u moet een lijst met veelvoorkomende acties ontwikkelen in de Office 365 services waarop u zich abonneert om te testen en vast te leggen. Hier volgt een voorbeeld van een basislijn:
Basislijnlijst voor SPO - ** Stap 1: ** Blader door de startpagina van de SPO-website en voer een netwerktracering uit. Sla de tracering op.
Basislijnlijst voor SPO: stap 2: Search voor een term (zoals uw bedrijfsnaam) via Enterprise Search en voer een netwerktracering uit. Sla de tracering op.
Basislijnlijst voor SPO- Stap 3: upload een groot bestand naar een SharePoint-documentbibliotheek en voer een netwerktracering uit. Sla de tracering op.
Basislijnlijst voor SPO- Stap 4: Blader door de startpagina van de OneDrive-website en voer een netwerktracering uit. Sla de tracering op.
Deze lijst moet de belangrijkste veelvoorkomende acties bevatten die gebruikers uitvoeren tegen SharePoint. U ziet dat in de laatste stap, om naar OneDrive te gaan, een vergelijking wordt gemaakt tussen de belasting van de SharePoint-startpagina (die vaak wordt aangepast door bedrijven) en de startpagina van OneDrive, die zelden wordt aangepast. Dit is een eenvoudige test als het gaat om een SharePoint-site die langzaam wordt geladen. U kunt een record van dit verschil maken in uw tests.
Als u midden in een prestatieprobleem zit, zijn veel van de stappen hetzelfde als bij het maken van een basislijn. Netwerktraceringen worden kritiek, dus we regelen hoe we de belangrijke traceringen vervolgens moeten gebruiken.
Als u een prestatieprobleem wilt oplossen, moet u nu een tracering uitvoeren op het moment dat u het prestatieprobleem ondervindt. U moet over de juiste hulpprogramma's beschikken om logboeken te verzamelen en u hebt een actieplan nodig, dat wil weten een lijst met probleemoplossingsacties die u moet ondernemen om de beste informatie te verzamelen die u kunt. Het eerste wat u moet doen, is de datum en tijd van de test vastleggen, zodat de bestanden kunnen worden opgeslagen in een map die de timing weerspiegelt. Vervolgens beperkt u zich tot de stappen van het probleem zelf. Dit zijn de exacte stappen die u gaat gebruiken voor het testen. Vergeet de basisbeginselen niet: als het probleem zich alleen bij Outlook voordoet, moet u registreren dat het probleem zich slechts in één Office 365 service voordoet. Als u het bereik van dit probleem beperkt, kunt u zich concentreren op iets dat u kunt oplossen.