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 opkomende problemen vroegtijdig detecteren, problemen identificeren en voorspellen.

Als u niet gewend bent om aan prestatieproblemen te werken, is dit artikel ontworpen om u te helpen bij het overwegen van enkele veelgestelde vragen. Hoe weet u dat het probleem dat u ziet een prestatieprobleem is en geen 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 clients trage prestaties zien tijdens het gebruik van Office 365 en u zich afvraagt over een van deze vragen, leest u verder.

Belangrijk

Hebt u momenteel een prestatieprobleem tussen uw client en Office 365? Volg de stappen die worden beschreven in het prestatieprobleemplan voor Office 365.

Iets wat u moet weten over Office 365 prestaties

Office 365 bevindt zich in een toegewezen Microsoft-netwerk met hoge capaciteit dat wordt bewaakt door automatisering en echte mensen. Een onderdeel van het onderhouden van de Office 365 cloud is waar mogelijk prestaties afstemmen en stroomlijnen. Omdat clients van de Office 365 cloud verbinding moeten maken via internet, is er voortdurende inspanning om de prestaties van Office 365 services te verfijnen.

Prestatieverbeteringen stoppen nooit echt in de cloud, dus ook geen ervaring met het gezond en snel houden van de cloud. Als er een prestatieprobleem is dat u vanaf uw locatie verbinding maakt 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 'binnen naar buiten'. Begin dus binnen uw netwerk en werk uw weg naar Office 365. Voordat u een case opent met Ondersteuning, kunt u gegevens verzamelen en acties ondernemen waarmee het probleem kan worden verkend en opgelost.

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 vindt u een koppeling naar de servicebeschrijvingen van de Microsoft 365 en Office 365. Dit is een centrale hub en alle services die worden aangeboden door Office 365 hebben een koppeling naar hun eigen servicebeschrijvingen. Als u bijvoorbeeld de standaardlimieten voor SharePoint Online wilt zien, klikt u op SharePoint Beschrijving van onlineservice en zoekt u de sectie SharePoint Onlinelimieten.

Zorg ervoor dat u problemen ondervindt met het inzicht dat de prestaties een sliding scale 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 bij het onboarden van een groot aantal gebruikers of het uitvoeren van grote gegevensmigraties, zullen stressvol zijn, dus plan dan de gevolgen voor de prestaties. U moet een ruw idee hebben van uw prestatiedoelen, maar veel variabelen spelen in op prestaties, zodat de prestaties variëren.

Prestatieproblemen oplossen gaat niet over het voldoen aan specifieke doelen en het voor onbepaalde tijd onderhouden van deze aantallen, maar om het verbeteren van bestaande activiteiten, gezien alle variabelen.

Hoe ziet een prestatieprobleem eruit?

Ten eerste 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. Hier leest u hoe u ze uit elkaar kunt 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 De huidige status bijvoorbeeld een rood pictogram rapporteert en u ziet Onderzoeken naast Exchange, kunt u ook oproepen ontvangen van personen in uw organisatie die klagen dat clientpostvakken die Exchange Online gebruiken, traag zijn. In dat geval is het redelijk om aan te nemen dat uw Exchange Online prestaties het slachtoffer zijn van serviceproblemen.

Het Office 365 Health-dashboard met alle workloads met groen, met uitzondering van Exchange, waarin Service Hersteld wordt weergegeven.

Op dit moment moet u, de Office 365-beheerder, de huidige status controleren en vervolgens vaak details en geschiedenis weergeven om op de hoogte te blijven van het onderhoud aan het systeem. Het dashboard Huidige status is gemaakt om u bij te werken over wijzigingen in en problemen in de service. De notities en uitleg die zijn geschreven naar de statusgeschiedenis, van beheerder naar beheerder, zijn er om u te helpen meten en om u op de hoogte te houden van lopende werkzaamheden.

Een afbeelding van het Office 365 statusdashboard waarin wordt uitgelegd dat de Exchange Online service is hersteld en waarom.

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 voor de service rapporteert.

  • Een gedrag dat wordt gebruikt om te stromen, duurt lang om te voltooien of wordt nooit voltooid.

  • U kunt het probleem ook repliceren of u weet dat dit 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 oproepen krijgt van gebruikers die niet altijd toegang hebben tot Office 365. De oproepen eindigen rond 12.00 uur.

Deze lijst klinkt waarschijnlijk bekend; misschien te bekend. Zodra u zich ervan bewust bent 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 ontstaan vaak na verloop van tijd, dus het kan lastig zijn om het werkelijke probleem te definiëren. Maak een goede probleemverklaring met een goed idee van probleemcontext en vervolgens moet u herhaalbare teststappen uitvoeren. Hier zijn enkele voorbeelden van problemen 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 Online duurt eeuwig. Waarom is het langzaam in de middag, maar op een ander moment is het snel? Kan het niet gewoon snel zijn?

De bovenstaande probleemverklaringen hebben verschillende grote uitdagingen. Er zijn te veel dubbelzinnigheden om mee om te gaan. Bijvoorbeeld:

  • Het is onduidelijk hoe het schakelen tussen Postvak IN en Agenda vroeger op de laptop werkte.

  • Wanneer de gebruiker zegt: 'Kan het niet gewoon snel zijn', wat is dan 'snel'?

  • Hoe lang is 'voor altijd'? Zijn dat enkele seconden? Of veel minuten? Of kan de gebruiker lunchen en zou de actie 10 minuten na terug 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 zich voordeden. De probleemoplosser weet mogelijk niet dat de gebruiker thuis werkt en ziet alleen langzaam schakelen op het thuisnetwerk. Of dat de gebruiker andere RAM-intensieve toepassingen uitvoert op de lokale client. Beheerders weten mogelijk niet dat de gebruiker een ouder besturingssysteem gebruikt of dat er geen recente updates zijn uitgevoerd.

Wanneer gebruikers een prestatieprobleem melden, is er veel informatie te verzamelen. Het ophalen en opnemen van informatie wordt het verkennen van het probleem genoemd. Hier volgt een eenvoudige bereiklijst die u kunt gebruiken om informatie over prestatieproblemen te verzamelen. 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?

  • Wat voor soort 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 problemen geven, zodat u de acties kunt schrijven die u uitvoert.

  • Hoe traag zijn de prestaties in seconden of minuten?

  • Waar bevindt u zich in de wereld?

Sommige van deze vragen zijn duidelijker dan andere. De meeste mensen begrijpen dat een probleemoplosser de exacte stappen nodig heeft om het probleem te reproduceren. Hoe kunt u immers nog meer 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 in de wereld bevindt u zich?', informatie die u samen kunt gebruiken. Afhankelijk van wanneer de gebruiker aan het werk was, kan een paar uur tijdsverschil betekenen dat er al onderhoud wordt uitgevoerd op onderdelen van het netwerk van uw bedrijf. Uw bedrijf heeft bijvoorbeeld een hybride implementatie, zoals een hybride SharePoint Search, waarmee query's kunnen worden uitgevoerd op zoekindexen in zowel SharePoint Online als een on-premises SharePoint Server 2013-exemplaar. Er worden mogelijk updates uitgevoerd in de on-premises farm. Als uw bedrijf zich allemaal in de cloud bevindt, kan systeemonderhoud bestaan uit het toevoegen of verwijderen van netwerkhardware, het implementeren van updates die het hele bedrijf zijn, of het aanbrengen van wijzigingen in DNS of een andere kerninfrastructuur.

Wanneer u een prestatieprobleem oplost, is het een beetje als een plaats delict, moet u nauwkeurig en oplettend zijn om conclusies te trekken uit het bewijs. Om dit te doen, moet u een goede probleemverklaring krijgen door bewijs te verzamelen. Het moet de context van de computer, de context van de gebruiker, het begin van het probleem en de exacte stappen bevatten die het prestatieprobleem hebben blootgelegd. 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 onderneemt het probleem hebben opgelost. Dit is essentieel om te weten wanneer uw werk daar is voltooid.

Weet u hoe prestaties er vroeger uit moesten zien toen het goed was?

Als je pech hebt, weet niemand het. Niemand had cijfers. Dat betekent dat niemand de eenvoudige vraag 'Hoeveel seconden duurde het om een Postvak IN te openen in Office 365?' of 'Hoe lang duurde het toen de leidinggevenden een Lync Online-vergadering hadden?', een veelvoorkomend scenario voor veel bedrijven.

Wat ontbreekt hier, is een prestatiebasislijn?

Basislijnen bieden u een context voor uw prestaties. Afhankelijk van de behoeften van uw bedrijf moet u af en toe een basislijn nemen. Als u een groter bedrijf bent, kan uw Operations-team al basislijnen voor uw on-premises omgeving nemen. 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 de patch worden uitgevoerd, om te bewijzen dat kritieke functies operationeel zijn. U kunt bijvoorbeeld het Postvak IN openen, op Verzenden/ontvangen klikken en ervoor zorgen dat de mappen worden bijgewerkt, of, in SharePoint, door de hoofdpagina van de site bladeren, naar de zoekpagina van het bedrijf gaan en een zoekopdracht uitvoeren die resultaten retourneert.

Als uw toepassingen zich in Office 365 bevinden, kunt u de tijd (in milliseconden) meten van een clientcomputer in uw netwerk, naar een uitgangspunt of naar het punt waar u uw netwerk verlaat en naar Office 365 gaat. Hier zijn enkele nuttige basislijnen die u kunt onderzoeken en vastleggen:

  • Identificeer de apparaten tussen uw clientcomputer en uw uitgangspunt, 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 de contactgegevens en vraag hoeveel circuits u hebt.

  • Identificeer binnen uw bedrijf resources voor de apparaten tussen uw client en het uitgangspunt of identificeer een contactpersoon voor noodgevallen waarmee u wilt praten over netwerkproblemen.

Hier zijn enkele basislijnen die eenvoudig testen met hulpprogramma's voor u kunnen berekenen:

  • Tijd van uw clientcomputer naar het uitgangspunt in milliseconden

  • Tijd van het uitgangspunt 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 deze fout gaat, maar als u uw historische prestatiegegevens niet kent, is het niet mogelijk om een context te hebben voor hoe slecht deze zijn geworden en wanneer. Dus zonder basislijn ontbreekt 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:

Een eenvoudige netwerkafbeelding met client, proxy en Office 365 cloud.

Dit betekent dat u bij uw netwerkteam hebt gecontroleerd en hebt ontdekt dat u uw bedrijf voor internet verlaat via een proxyserver, en dat de 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 die u kunt gebruiken om de prestaties te testen tussen de client, het uitgangspunt (waar u uw netwerk verlaat voor internet) en de Office 365 cloud.

Basisnetwerk met client-, proxy- en cloud- en hulpprogramma's met suggesties voor PSPing, TraceTCP en netwerktraceringen.

De opties worden vermeld als Eenvoudig en Geavanceerd vanwege de hoeveelheid expertise die u nodig hebt om de prestatiegegevens te vinden. Een netwerktracering duurt veel tijd, vergeleken 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 zijn om de clientcomputer of proxyserver te verlaten (als u toegang hebt) en bij Office 365 aankomen. Elke afzonderlijke hop van de ene computer naar de andere zal eindigen met een tijdwaarde en dat is geweldig voor basislijnen! Net zo belangrijk is dat u met deze opdrachtregelprogramma's een poortnummer kunt toevoegen aan de opdracht. Dit is handig omdat Office 365 communiceert via poort 443, de poort die wordt gebruikt door Secure Sockets Layer and Transport Layer Security (SSL en TLS). Andere hulpprogramma's van derden kunnen echter betere oplossingen voor uw situatie zijn. 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 vóór kantooruren maken, opnieuw tijdens intensief gebruik en daarna opnieuw na uren. Dit betekent dat u mogelijk een mapstructuur hebt die er uiteindelijk een beetje als volgt uitziet:

Afbeelding met een manier om uw prestatiegegevens in mappen te ordenen.

U moet ook een naamconventie kiezen voor uw bestanden. 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 het gebruik van de indeling <dateTime><what's happening in the test> is een goede plek om te beginnen. Dit kan veel helpen wanneer u later problemen probeert op te lossen. Later kunt u zeggen: "Ik heb twee sporen genomen op 8 februari, één liet goede prestaties zien en één liet zich slecht zien, dus we kunnen ze 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 opdrachtregeluitvoeren 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 waar u wijzigingen ziet in het gedrag van onlineservices.

Waarom prestatiegegevens verzamelen tijdens een testfase?

Er is geen beter moment om basislijnen te maken dan tijdens een testfase van de Office 365-service. Uw kantoor kan duizenden gebruikers, honderdduizenden of vijf gebruikers hebben, maar zelfs met een paar gebruikers kunt u tests uitvoeren om schommelingen in de prestaties te meten. In het geval van een groot bedrijf kan een representatieve steekproef van enkele honderden gebruikers die Office 365 testen naar buiten worden geprojecteerd naar enkele duizenden, zodat u weet waar problemen zich 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 pilot is, houdt u prestatiemetingen zodat u gegevens hebt om aan iedereen te laten zien die mogelijk problemen moet oplossen met een slecht presterende bewerking. 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 deze vroeger snel gebeurde.

Basislijnen verzamelen

Voor alle probleemoplossingsplannen moet u deze zaken minimaal 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 intranet van het bedrijf)

  • Het uitgangspunt dat de clientcomputer gebruikt vanuit uw netwerk (het punt waarop verkeer uw bedrijf verlaat voor een internetprovider)

U kunt de indeling van uw netwerk achterhalen bij de netwerkbeheerder. Als u zich in een klein netwerk bevindt, bekijkt u de apparaten waarmee u verbinding maakt met internet en belt u uw internetprovider als u vragen hebt over de indeling. Maak een afbeelding van de uiteindelijke indeling ter referentie.

Deze sectie is onderverdeeld in eenvoudige opdrachtregelprogramma's en -methoden en geavanceerdere hulpprogramma's. We behandelen eerst eenvoudige methoden. Maar als u op dit moment een prestatieprobleem hebt, moet u naar geavanceerde methoden gaan en het voorbeeld van het actieplan voor het oplossen van prestatieproblemen uitproberen.

Eenvoudige methoden

Het doel van deze eenvoudige methoden is om na verloop van tijd eenvoudige prestatiebasislijnen te leren gebruiken, 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 eenvoudig, zoals u eerder hebt gezien:

Basisnetwerk met client-, proxy- en cloud- en hulpprogramma's met suggesties voor PSPing, TraceTCP en netwerktraceringen.

Notitie

TraceTCP is opgenomen in deze schermafbeelding omdat het een handig hulpmiddel is om in milliseconden weer te geven hoe lang een aanvraag moet worden verwerkt en hoeveel netwerkhops of verbindingen van de ene computer naar de andere duurt om een bestemming te bereiken. TraceTCP kan ook de namen geven van servers die worden gebruikt tijdens hops, wat handig kan zijn voor een Microsoft Office 365 probleemoplosser in ondersteuning. > TraceTCP-opdrachten kunnen heel eenvoudig zijn, zoals: > tracetcp.exe outlook.office365.com:443> Vergeet niet het poortnummer in de opdracht op te nemen! > TraceTCP is een gratis download, 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 de latentie. In dit geval is dit een getalwaarde die de hoeveelheid tijd beschrijft tussen een client die een aanvraag naar Office 365 verzendt en Office 365 reageert op de aanvraag. Het testen vindt plaats in uw domein op een clientcomputer en er wordt gezocht naar het meten van een retour vanuit uw netwerk, via een uitgangspunt, via internet naar Office 365 en terug.

Er zijn een aantal manieren om om te gaan met het uitgangspunt, in dit geval de proxyserver. U kunt een tracering uitvoeren van 1 tot 2 en vervolgens van 2 naar 3 en vervolgens de getallen in milliseconden toevoegen om een eindtotaal te krijgen aan de rand van uw netwerk. 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 worden gebruikt door Office 365. Als u een verificatieproxy hebt, test u eerst uitzonderingen voor het volgende:

  • Poorten 80 en 443

  • TCP en HTTPs

  • Verbindingen 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 hebben tot deze adressen zonder proxyinterferentie of verificatie. In een kleiner netwerk moet u deze toevoegen aan uw lijst met proxy-bypasss in uw webbrowser.

Als u deze wilt toevoegen aan uw lijst met proxy-bypasss in Internet Explorer, gaat u naar Extra > internetopties > verbindingen > LAN-instellingen > Geavanceerd. Op het tabblad Geavanceerd vindt u ook uw proxyserver en proxyserverpoort. Mogelijk moet u op het selectievakje Een proxyserver gebruiken voor uw LAN klikken om toegang te krijgen tot de knop Geavanceerd . U moet ervoor zorgen dat proxyserver voor lokale adressen overslaan is ingeschakeld. Wanneer u op Geavanceerd klikt, ziet u een tekstvak waarin u uitzonderingen kunt invoeren. Scheid de hierboven vermelde JOKER-URL's met puntkomma's, bijvoorbeeld:

*.microsoftonline.com; *.sharepoint.com

Zodra u uw proxy hebt overgeslagen, 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 naar een server te verzenden, zoals outlook.office365.com en een antwoord terug te krijgen waarin wordt bevestigd dat de server weet dat u dit hebt gedaan. Dit wordt 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

  1. Voer een opdrachtprompt met verhoogde bevoegdheid uit door deze stappen uit te voeren:

  2. Klik op Start.

  3. Typ cmd in het vak Zoeken starten en druk op Ctrl+Shift+Enter.

  4. Als het dialoogvenster Gebruikersaccountbeheer wordt weergegeven, controleert u of de weergegeven actie is wat u wilt en klikt u op Doorgaan.

  5. 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

    De PSPing-opdracht gaat naar microsoft-my.sharepoint.com poort 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, uw aanvraag mislukt. Zodra u uw korte lijst hebt gepingd, zoekt u naar de gemiddelde tijd in milliseconden (ms). Dat is wat u wilt opnemen!

Afbeelding met een afbeelding van client naar proxy PSPing met een retourtijd van 2,8 milliseconden.

Als u niet bekend bent met proxy bypass en liever stap voor stap dingen doet, moet u eerst de naam van uw proxyserver achterhalen. Ga in Internet Explorer naar Extra > internetopties > Verbindingen > LAN-instellingen > Geavanceerd. Op het tabblad Geavanceerd wordt uw proxyserver weergegeven. Ping die proxyserver bij een opdrachtprompt door deze taak te voltooien:

De proxyserver pingen en een retourwaarde ophalen in milliseconden voor fase 1 tot en met 2

  1. Voer een opdrachtprompt met verhoogde bevoegdheid uit door deze stappen uit te voeren:

  2. Klik op Start.

  3. Typ cmd in het vak Zoeken starten en druk op Ctrl+Shift+Enter.

  4. Als het dialoogvenster Gebruikersaccountbeheer wordt weergegeven, controleert u of de weergegeven actie is wat u wilt en klikt u op Doorgaan.

  5. Typ ping <the name of the proxy server your browser uses, or the IP address of the proxy server> en druk op Enter. Als u PsPing of een ander hulpprogramma hebt geïnstalleerd, kunt u ervoor kiezen om dat hulpprogramma te gebruiken.

    Uw opdracht kan eruitzien als een van de volgende 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

  1. Wanneer de tracering stopt met het verzenden van testpakketten, krijgt u een klein overzicht 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 moment kan het ook helpen om het diagram in te vullen met de waarde.

Misschien hebt u in de vroege ochtend een tracering uitgevoerd en kan uw client snel toegang krijgen tot de proxy (of een andere uitgaande server die naar internet wordt afgesloten). In dit geval kunnen uw getallen er als volgende uitzien:

Afbeelding van de retourtijd van een client naar een proxy van 2,8 milliseconden.

Als uw clientcomputer een van de select few is met toegang tot de proxyserver (of uitgaande server), kunt u het volgende deel van de test uitvoeren door op afstand verbinding te maken met die computer en de opdrachtprompt naar PsPing uit te voeren 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 het volgende gedeelte en op die manier exacte nummers ophalen. Als dat niet mogelijk is, neemt u een PsPing op basis van de betreffende Office 365 URL en vergelijkt u deze met de PsPing- of Ping-tijd ten opzichte van 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 uitgangspunt) hebt, hebt u 49,04 milliseconden van het uitgaand verkeer 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 het uitgaand verkeer van de proxy naar de Office 365 URL 49,76 milliseconden.

Aanvullende afbeelding met de ping in milliseconden van client naar proxy naast client naar Office 365 zodat de waarden kunnen worden afgetrokken.

In termen van probleemoplossing vindt u misschien iets interessants, alleen maar om deze basislijnen te behouden. Als u bijvoorbeeld merkt dat u over het algemeen ongeveer 40 milliseconden tot 59 milliseconden latentie hebt van de proxy of uitgaand verkeer verwijst naar de Office 365 URL en een client-naar-proxy- of uitgangspuntlatentie hebt van ongeveer 3 milliseconden tot 7 milliseconden (afhankelijk van de hoeveelheid netwerkverkeer die u op dat moment van de dag ziet), weet u zeker dat er iets problematisch is als uw laatste drie client-naar-proxy- of uitgaande basislijnen worden weergegeven een latentie van 45 milliseconden.

Geavanceerde methoden

Als u echt wilt weten wat er gebeurt met uw internetaanvragen voor 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 tool of een ander hulpprogramma, 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 op zichzelf. Hulpprogramma's die worden gebruikt in het bijbehorende artikel, Prestatieproblemen oplossen voor Office 365, omvatten Netmon 3.4, HTTPWatch of WireShark.

Het maken 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 maken en opslaan. In de meeste voorbeelden in dit artikel wordt SharePoint Online gebruikt, maar u moet een lijst met algemene acties ontwikkelen voor de Office 365 services waarop u zich abonneert om te testen en op te nemen. Hier volgt een voorbeeld van een basislijn:

  • Basislijnlijst voor SPO - ** Stap 1: ** Blader naar de startpagina van de SPO-website en voer een netwerktracering uit. Sla de tracering op.

  • Basislijnlijst voor SPO - Stap 2: zoek 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 Online-documentbibliotheek en voer een netwerktracering uit. Sla de tracering op.

  • Basislijnlijst voor SPO - Stap 4: Blader op de startpagina van de OneDrive website en voer een netwerktracering uit. Sla de tracering op.

Deze lijst moet de belangrijkste algemene acties bevatten die gebruikers uitvoeren tegen SharePoint Online. U ziet dat de laatste stap, om te traceren naar OneDrive voor Bedrijven, een vergelijking maakt tussen de belasting van de startpagina van SharePoint Online (die vaak wordt aangepast door bedrijven) en OneDrive voor Bedrijven startpagina, die zelden wordt aangepast. Dit is een basistest als het gaat om een traag ladende SharePoint Online-site. U kunt een record van dit verschil inbouwen in uw tests.

Als u midden in een prestatieprobleem zit, zijn veel van de stappen hetzelfde als bij het nemen van een basislijn. Netwerktraceringen worden kritiek, dus we gaan nu aan de slag met de belangrijke traceringen.

Als u een prestatieprobleem wilt oplossen, moet u op dit moment 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. Dit is een lijst met probleemoplossingsacties die moeten worden uitgevoerd om de beste informatie te verzamelen die u kunt gebruiken. 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 weergeeft. Beperk vervolgens tot de probleemstappen zelf. Dit zijn de exacte stappen die u gaat gebruiken voor het testen. Vergeet de basisbeginselen niet: als het probleem zich alleen voordoet met Outlook, moet u vastleggen dat het probleem zich in slechts één Office 365 service voordoet. Als u het bereik van dit probleem beperkt, kunt u zich richten op iets dat u kunt oplossen.

Zie ook

Office 365-eindpunten beheren