Megosztás a következőn keresztül:


A teljesítmény finomhangolásának Office 365 alaptervek és teljesítményelőzmények használatával

A Office 365 és a vállalat közötti kapcsolati teljesítmény ellenőrzésének néhány egyszerű módja lehetővé teszi a kapcsolat alapkonfigurációjának kialakítását. Az ügyfélszámítógép-kapcsolatok teljesítményelőzményeinek ismerete segíthet a felmerülő problémák korai észlelésében, a problémák azonosításában és előrejelzésében.

Ha nincs hozzászokva a teljesítményproblémákhoz, ez a cikk segít megfontolni néhány gyakori kérdést. Honnan tudja, hogy a tapasztalt probléma teljesítménybeli probléma, nem pedig Office 365 szolgáltatási incidens? Hogyan tervezhet jó teljesítményt, hosszú távon? Hogyan lehet szemmel tartani a teljesítményt? Ha csapata vagy ügyfelei lassú teljesítményt tapasztalnak a Office 365 használata során, és kíváncsi ezekre a kérdésekre, olvasson tovább.

Fontos

Jelenleg teljesítményproblémája van az ügyfél és a Office 365 között? Kövesse az Office 365 teljesítményével kapcsolatos hibaelhárítási tervben ismertetett lépéseket.

Valami, amit tudnia kell Office 365 teljesítményről

Office 365 egy nagy kapacitású, dedikált Microsoft-hálózaton belül található, amelyet az automatizálás és a valós személyek figyelnek. A Office 365 felhő karbantartásának része a teljesítmény finomhangolása és ahol lehetséges, a streamelés. Mivel a Office 365 felhő ügyfeleinek az interneten keresztül kell csatlakozniuk, folyamatosan törekszünk arra, hogy finomhangoljuk a teljesítményt Office 365 szolgáltatások között is.

A teljesítménybeli fejlesztések soha nem állnak meg igazán a felhőben, így a felhő kifogástalan állapotának és gyors állapotának megőrzésével sem járnak együtt. Ha teljesítményproblémája van a helyről a Office 365 való csatlakozáskor, a legjobb, ha nem egy támogatási esettel kezd, vagy nem vár. Ehelyett érdemes "kívülről" kezdenie a probléma kivizsgálását. Vagyis kezdje a hálózatán belül, és lépjen ki a Office 365. Mielőtt megnyitna egy esetet a támogatási szolgálatnál, adatokat gyűjthet, és műveleteket hajthat végre, amelyek feltárják és megoldhatják a problémát.

Fontos

Vegye figyelembe a kapacitástervezést és a Office 365 korlátait. Ez az információ a teljesítményprobléma megoldásakor a görbe élére kerül. Íme egy hivatkozás a Microsoft 365 és Office 365 szolgáltatás leírására. Ez egy központi központ, és az Office 365 által kínált összes szolgáltatás rendelkezik egy hivatkozással, amely innen a saját szolgáltatásleírásaikra vezet. Ez azt jelenti, hogy ha meg kell tekintenie például a SharePoint szabványos korlátait, kattintson a SharePoint szolgáltatás leírása elemre, és keresse meg a SharePoint-korlátok szakaszt.

Győződjön meg arról, hogy a hibaelhárítás során tisztában van azzal, hogy a teljesítmény csúszós léptékű. Nem arról van szó, hogy egy idealizált értéket érünk el, és folyamatosan fenntartjuk azt. Az olyan nagy sávszélességű feladatok, mint a nagy számú felhasználó beszállása vagy a nagy adatmigrálások elvégzése stresszesek lesznek, ezért tervezze meg a teljesítményre gyakorolt hatásokat. A teljesítménycélokról hozzávetőleges képet kell adnia, de számos változó játszik szerepet a teljesítményben, így a teljesítmény változó.

A teljesítménnyel kapcsolatos hibaelhárítás nem az adott célok eléréséről és a számok határozatlan időre történő fenntartásáról szól, hanem a meglévő tevékenységek fejlesztéséről, az összes változó figyelembe véve.

Oké, hogyan néz ki egy teljesítményprobam?

Először győződjön meg arról, hogy a tapasztalt problémák valóban teljesítményproblémák, és nem szolgáltatási incidensek. A teljesítményproblémák eltérnek a Office 365 szolgáltatáseseményeitől. Így lehet megkülönböztetni őket egymástól.

Szolgáltatási incidensek akkor fordulnak elő, ha a Office 365 szolgáltatásban problémák lépnek fel. A Microsoft 365 Felügyeleti központ Aktuális állapot területén piros vagy sárga ikonok jelenhetnek meg. Előfordulhat, hogy a Office 365 csatlakozó ügyfélszámítógépek teljesítménye lassú. Ha például az Aktuális állapot egy piros ikont jelent, és a Vizsgálat az Exchange mellett látható, akkor a szervezet azon tagjaitól is kaphat hívásokat, akik arra panaszkodnak, hogy a Exchange Online használó ügyfélpostaládák lassúak. Ebben az esetben ésszerű azt feltételezni, hogy a Exchange Online teljesítménye szolgáltatásproblémák áldozata volt.

Az Office 365 Állapot irányítópultja, amelyen az összes számítási feladat zöld színnel jelenik meg, kivéve az Exchange-et, amely a Szolgáltatás visszaállítása lehetőséget jeleníti meg.

Ekkor a Office 365 rendszergazdájának ellenőriznie kell az Aktuális állapotot, majd gyakran meg kell tekintenie a részleteket és az előzményeket, hogy naprakészen tarthassa a rendszer karbantartását. Az Aktuális állapot irányítópulton frissítheti a szolgáltatás módosításait és problémáit. Az állapotelőzményekbe írt megjegyzések és magyarázatok, a rendszergazda és a rendszergazda, segítenek felmérni, és folyamatosan közzétenni a folyamatban lévő munkát.

Az Office 365 állapot-irányítópultjának képe, amely elmagyarázza, hogy a Exchange Online szolgáltatás helyre lett állítva, és hogy miért.

A teljesítményproblémák nem szolgáltatási incidensek, annak ellenére, hogy az incidensek lassú teljesítményt okozhatnak. A teljesítményproblémák a következőképpen néznek ki:

  • Teljesítményproblémák lépnek fel, függetlenül attól, hogy mit jelent a felügyeleti központ A szolgáltatás aktuális állapota .

  • A folyamathoz használt viselkedés végrehajtása hosszú időt vesz igénybe, vagy soha nem fejeződik be.

  • A problémát replikálhatja is, vagy tudja, hogy ez akkor fordul elő, ha a megfelelő lépéseket hajtja végre.

  • Ha a probléma időszakos, akkor is előfordulhat minta. Tudja például, hogy reggel 10:00-ig olyan felhasználók hívásai lesznek, akik nem mindig férnek hozzá Office 365. A hívások dél körül érnek véget.

Ez a lista valószínűleg ismerősnek hangzik; talán túl ismerős. Ha már tudja, hogy teljesítményproblémáról van szó, a kérdés a következő lesz: "Mi a következő lépés?" A cikk további része segít pontosan meghatározni ezt.

A teljesítményprobléma meghatározása és tesztelése

A teljesítményproblémák gyakran idővel jelentkeznek, ezért nehéz lehet meghatározni a tényleges problémát. Létrehozás egy jó problémaleírást, amely jó képet ad a probléma kontextusáról, majd ismételhető tesztelési lépéseket kell végrehajtania. Íme néhány példa azokra a problémákra vonatkozó utasításokra, amelyek nem biztosítanak elegendő információt:

  • A Beérkezett üzenetek mappáról a naptárra váltás korábban olyan dolog volt, amit nem vettem észre, és most kávészünet van. Meg tudod tenni, hogy úgy viselkedjen, mint régen?

  • A fájlok SharePointba való feltöltése örökké tart. Miért lassú délután, de máskor gyors? Nem lehet gyors?

A fenti problémameghívók számos nagy kihívást jelentenek. Pontosabban, túl sok kétértelműséget kell kezelni. Például:

  • Nem világos, hogyan váltott a Beérkezett üzenetek és a Naptár között a laptopon való működéshez.

  • Amikor a felhasználó azt mondja, "Nem lehet csak gyors", mi a "gyors"?

  • Mennyi ideig tart az "örökké"? Ez több másodperc? Vagy sok percet? Vagy a felhasználó ebédelhet, és a művelet 10 perccel a visszatérés után befejeződik?

A rendszergazda és a hibaelhárító nem tudhatja meg a probléma részleteit az ilyen általános utasításokból. Nem tudják például, hogy mikor jelentkezett a probléma. Előfordulhat, hogy a hibaelhárító nem tudja, hogy a felhasználó otthonról dolgozik, és csak az otthoni hálózatán tapasztal lassú váltást. Vagy azt, hogy a felhasználó más, RAM-igényes alkalmazásokat futtat a helyi ügyfélen. Előfordulhat, hogy a rendszergazdák nem tudják, hogy a felhasználó régebbi operációs rendszert futtat, vagy nem futtatta a legutóbbi frissítéseket.

Amikor a felhasználók teljesítményproblémát jelentenek, sok információt kell összegyűjteni. Az információk lekérését és rögzítését a probléma hatókörkezelésének nevezzük. Íme egy alapszintű hatókörkezelési lista, a segítségével adatokat gyűjthet a teljesítményproblémákról. Ez a lista nem teljes, de érdemes elkezdeni:

  • Mikor jelentkezett a probléma, és milyen időpontban történt a nap vagy az éjszaka?

  • Milyen típusú ügyfélszámítógépet használt, és hogyan csatlakozik az üzleti hálózathoz (VPN, vezetékes, vezeték nélküli)?

  • Távolról dolgozott, vagy az irodában volt?

  • Próbálkozott ugyanezekkel a műveletekkel egy másik számítógépen, és ugyanezt a viselkedést látta?

  • Haladjon végig a problémákat okozó lépéseken, hogy megírhassa a végrehajtott műveleteket.

  • Mennyire lassú másodpercek vagy percek alatt a teljesítmény?

  • Hol van a világon?

Néhány ilyen kérdés nyilvánvalóbb, mint mások. A legtöbben tisztában lesznek azzal, hogy a hibaelhárítónak pontosan meg kell tennie a szükséges lépéseket a probléma reprodukálásához. Végül is, hogyan rögzítheti még a hibát, és hogyan tesztelheti, hogy a probléma megoldódott-e? Kevésbé nyilvánvalóak az olyan dolgok, mint a "Milyen dátum és idő látta a problémát?", és "Hol található a világon?", a tandemben használható információk. Attól függően, hogy a felhasználó mikor dolgozott, néhány órányi időeltérés azt jelentheti, hogy a karbantartás már folyamatban van a vállalati hálózat egyes részein. A vállalat például rendelkezik egy hibrid implementációval, például egy hibrid SharePoint-Keresés, amely a Microsoft 365-beli SharePointban és egy helyszíni SharePoint Server 2013-példányban is le tudja kérdezni a keresési indexeket, előfordulhat, hogy a helyszíni farmon frissítések vannak folyamatban. Ha a vállalata a felhőben van, a rendszerkarbantartás magában foglalhatja a hálózati hardverek hozzáadását vagy eltávolítását, a vállalati szintű frissítések telepítését, a DNS vagy más alapvető infrastruktúra módosítását.

Teljesítményproblémák elhárításakor ez egy kicsit olyan, mint egy bűnügyi helyszín, pontosnak és figyelmesnek kell lennie ahhoz, hogy következtetéseket vonjon le a bizonyítékokból. Ehhez egy jó problémaleírást kell kapnia a bizonyítékok összegyűjtésével. Tartalmaznia kell a számítógép környezetét, a felhasználó környezetét, a probléma kezdetének időpontját, valamint a teljesítményproblémát feltáró pontos lépéseket. Ennek a problémaleírásnak a jegyzetei legfelső oldalának kell lennie, és meg kell maradnia. Miután a megoldáson végzett munka után ismét végiglépked a problémaleíráson, lépéseket tesz annak tesztelésére és bizonyítására, hogy a végrehajtott műveletek megoldották-e a problémát. Ez kritikus fontosságú annak ismerete szempontjából, hogy a munka, ott, befejezve.

Tudja, milyen volt a teljesítmény, amikor jó volt?

Ha szerencsétlen vagy, senki sem tudja. Senkinek sem voltak számai. Ez azt jelenti, hogy senki sem tud válaszolni az egyszerű kérdésre: "Hány másodpercig tartott a Beérkezett üzenetek mappa létrehozása a Office 365?", vagy "Mennyi ideig tartott, amíg a vezetők Lync Online-értekezletet folytattak?", ami sok vállalatnál gyakori forgatókönyv.

Ami hiányzik, az egy teljesítménybeli alapkonfiguráció.

Az alaptervek kontextust biztosítanak a teljesítményhez. Az alapkonfigurációt időnként gyakran kell elvégeznie a vállalat igényeitől függően. Ha Ön nagyobb vállalat, előfordulhat, hogy az üzemeltetési csapat már figyelembe veszi a helyszíni környezet alapterveit. Ha például a hónap első hétfőjén az összes Exchange-kiszolgálót, a harmadik hétfőn pedig az összes SharePoint-kiszolgálót javítja, akkor az üzemeltetési csapat valószínűleg rendelkezik a javítást követően futtatott feladatok és forgatókönyvek listájával, amelyek bizonyítják, hogy a kritikus funkciók működőképesek. Nyissa meg például a Beérkezett üzenetek mappát, kattintson a Küldés/fogadás gombra, és győződjön meg arról, hogy a mappák frissülnek, vagy a SharePointban a webhely főoldalát böngészi, a vállalati Keresés lapra lép, és keresést végez, amely eredményeket ad vissza.

Ha az alkalmazások Office 365 vannak, a legalapvetőbb alapkonfigurációk közül néhányat mérhet a hálózaton belüli ügyfélszámítógéptől a kimenő forgalomig vagy a hálózat elhagyási pontjához és a Office 365. Íme néhány hasznos alapkonfiguráció, amelyeket megvizsgálhat és rögzíthet:

  • Azonosítsa az ügyfélszámítógép és a kimenő forgalmi pont közötti eszközöket, például a proxykiszolgálót.

    • Ismernie kell az eszközöket, hogy a felmerülő teljesítményproblémák kontextusa (IP-címek, eszköz típusa, stb.) legyen.

    • A proxykiszolgálók gyakori kimenő pontok, így ellenőrizheti a webböngészőben, hogy melyik proxykiszolgálót használja, ha van ilyen.

    • Vannak olyan külső eszközök, amelyek képesek felderíteni és leképezni a hálózatot, de az eszközök megismerésének legbiztonságosabb módja, ha megkéri a hálózati csapat egy tagját.

  • Azonosítsa az internetszolgáltatót, jegyezze fel a kapcsolattartási adatait, és kérdezze meg, hogy hány kapcsolatcsoportnak mekkora sávszélessége van.

  • A vállalaton belül azonosítsa az ügyfél és a kilépési pont közötti eszközök erőforrásait, vagy egy vészhelyzeti kapcsolattartót, amellyel hálózatkezelési problémákról beszélhet.

Íme néhány alapkonfiguráció, amelyeket az eszközökkel végzett egyszerű teszteléssel kiszámíthat:

  • Az ügyfélszámítógéptől a kilépési pontig eltelt idő ezredmásodpercben

  • A kilépési pont és a Office 365 közötti idő ezredmásodpercben

  • A tallózáskor Office 365 URL-címeit feloldó kiszolgáló világának helye

  • Az isp DNS-feloldásának sebessége ezredmásodpercben, inkonzisztenciák a csomagérkezésben (hálózati jitter), feltöltési és letöltési idő ezredmásodpercben

Ha nem tudja, hogyan hajthatja végre ezeket a lépéseket, ebben a cikkben részletesebben is bemutatjuk.

Mi az az alapkonfiguráció?

Tudni fogja, hogy milyen hatással jár, ha rosszra fordulnak, de ha nem ismeri az előzmény teljesítményadatait, akkor nem lehet kontextust adni arról, hogy milyen rosszak lettek, és mikor. Tehát alapkonfiguráció nélkül hiányzik a kulcs nyom a puzzle megoldásához: a kép a puzzle dobozán. A teljesítménnyel kapcsolatos hibaelhárításhoz összehasonlítási pontra van szükség. Az egyszerű teljesítménykonfigurációkat nem nehéz elvégezni. Az üzemeltetési csapat feladata, hogy ezeket ütemezés szerint hajtsa végre. Tegyük fel például, hogy a kapcsolat a következőképpen néz ki:

Egy egyszerű hálózati ábra, amely az ügyfelet, a proxyt és a Office 365 felhőt mutatja be.

Ez azt jelenti, hogy ellenőrizte a hálózati csapatát, és megtudta, hogy egy proxykiszolgálón keresztül elhagyja a vállalatot az internetre, és ez a proxy kezeli az ügyfélszámítógép által a felhőbe küldött összes kérést. Ebben az esetben meg kell rajzolnia a kapcsolat egyszerűsített verzióját, amely felsorolja az összes beavatkozó eszközt. Most szúrjon be eszközöket, amelyekkel tesztelheti a teljesítményt az ügyfél, a kimenőforgalom-pont (ahol elhagyja a hálózatot az internetre) és a Office 365 felhő között.

Alapszintű hálózat ügyféllel, proxyval és felhővel, valamint eszközökkel kapcsolatos javaslatok PSPing, TraceTCP és hálózati nyomkövetések.

A beállítások egyszerűként és speciálisként jelennek meg, mivel a teljesítményadatok megkereséséhez szükséges szakértelem szükséges. A hálózati nyomkövetés sok időt vesz igénybe a parancssori eszközök, például a PsPing és a TraceTCP futtatásához képest. Ez a két parancssori eszköz azért lett kiválasztva, mert nem használnak ICMP-csomagokat, amelyeket a Office 365 blokkol, és mivel ezredmásodpercben megadja az időt, hogy elhagyja az ügyfélszámítógépet vagy a proxykiszolgálót (ha van hozzáférése), és megérkezik a Office 365. Minden egyes ugrás az egyik számítógépről a másikra időértékkel végződik, és ez nagyszerű az alapkonfigurációkhoz! Akárcsak fontos, ezek a parancssori eszközök lehetővé teszik, hogy portszámot adjon a parancshoz, ez azért hasznos, mert Office 365 a 443-as porton keresztül kommunikál, amely a Secure Sockets Layer és a Transport Layer Security (SSL és TLS) által használt port. Más külső eszközök azonban jobb megoldást jelenthetnek az Ön helyzetére. A Microsoft nem támogatja ezeket az eszközöket, így ha valamilyen okból nem tudja működésbe léptetni a PsPinget és a TraceTCP-t, lépjen tovább egy hálózati nyomkövetésre egy olyan eszközzel, mint a Netmon.

Az alapkonfigurációt munkaidő előtt, nagy igénybevétel esetén, majd munkaidő után is elvégezheti. Ez azt jelenti, hogy előfordulhat, hogy a mappastruktúra a végén egy kicsit így néz ki:

Ábra, amely módot javasol a teljesítményadatok mappákba rendezésére.

A fájlok elnevezési konvencióját is meg kell adnia. Néhány példa:

  • 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

Ennek számos különböző módja van, de a dateTime><formátum< használata, ami a tesztben> történik, jó kiindulópont. Ha szorgalmasan kezeli ezt a problémát, az sokat segít, ha később megpróbál hibaelhárítást végezni. Később azt fogja mondani, hogy "február 8-án két nyomra bukkantam, az egyik jó teljesítményt mutatott, az egyik rosszat mutatott, így összehasonlíthatjuk őket". Ez hasznos a hibaelhárításhoz.

A korábbi alapkonfigurációk megőrzéséhez szervezett módon kell rendelkeznie. Ebben a példában az egyszerű metódusok három parancssori kimenetet hoztak létre, és az eredményeket képernyőképként gyűjtöttük össze, de előfordulhat, hogy ehelyett hálózati rögzítési fájlokat használunk. Használja az Önnek legmegfelelőbb módszert. Tárolja a korábbi alapterveket, és hivatkozzon rájuk olyan helyeken, ahol változásokat tapasztal a online szolgáltatások viselkedésében.

Miért érdemes teljesítményadatokat gyűjteni próbaüzem közben?

Nincs jobb idő az alapkonfigurációk elkészítésére, mint a Office 365 szolgáltatás próbaüzeme során. Előfordulhat, hogy az irodája több ezer felhasználóval, több százezerrel vagy öttel rendelkezik, de még néhány felhasználó esetén is elvégezhet teszteket a teljesítmény ingadozásának mérésére. Egy nagyvállalat esetében egy több száz felhasználóból álló reprezentatív minta, amely Office 365 próbaüzembe lép, kifelé több ezerre vetítheti, hogy tudja, hol merülhetnek fel problémák, mielőtt bekövetkeznének.

Egy kisvállalat esetében, ahol a beszállás azt jelenti, hogy minden felhasználó egyszerre megy a szolgáltatásba, és nincs próbaüzem, tartsa meg a teljesítménymutatókat, hogy azok az adatok jelenjenek meg, akiknek esetleg egy rosszul teljesítő művelet hibaelhárítására van szükség. Ha például azt veszi észre, hogy hirtelen körbesétálhat az épület körül, amíg feltölt egy közepes méretű ábrát, ahol korábban gyorsan előfordult.

Alaptervek gyűjtése

Az összes hibaelhárítási tervhez legalább az alábbi elemeket kell azonosítania:

  • A használt ügyfélszámítógép (a számítógép vagy eszköz típusa, egy IP-cím és a problémát okozó műveletek)

  • Az ügyfélszámítógép helye a világon (például hogy ez a felhasználó VPN-kapcsolaton keresztül csatlakozik-e a hálózathoz, távolról dolgozik vagy a vállalati intraneten)

  • Az ügyfélszámítógép által a hálózatról használt kimenő forgalmi pont (az a pont, ahol a forgalom elhagyja a vállalatot egy internetszolgáltató vagy az internet számára)

A hálózat elrendezését a hálózati rendszergazdától tudja meg. Ha kis hálózattal rendelkezik, tekintse meg az internethez csatlakozó eszközöket, és hívja fel az internetszolgáltatót, ha kérdése van az elrendezéssel kapcsolatban. Létrehozás a referencia végleges elrendezésének ábráját.

Ez a szakasz egyszerű parancssori eszközökre és metódusokra, valamint speciálisabb eszközökre van felosztva. Először az egyszerű módszerekkel foglalkozunk. Ha azonban jelenleg teljesítményproblémája van, ugorjon a speciális módszerekre, és próbálja ki a teljesítmény-hibaelhárítási minta cselekvési tervet.

Egyszerű metódusok

Ezeknek az egyszerű módszereknek az a célja, hogy megtanulja az egyszerű teljesítménykonfigurációk időbeli értelmezését és megfelelő tárolását, hogy értesüljön Office 365 teljesítményről. Az alábbi egyszerű diagram egyszerű, ahogy azt korábban is láthatta:

Alapszintű hálózat ügyféllel, proxyval és felhővel, valamint eszközökkel kapcsolatos javaslatok PSPing, TraceTCP és hálózati nyomkövetések.

Megjegyzés:

A TraceTCP azért szerepel ebben a képernyőképen, mert ezredmásodpercben mutatja be, hogy mennyi ideig tart egy kérés feldolgozása, és hogy hány hálózati ugrás vagy kapcsolat van az egyik számítógépről a másikra, hogy a kérés elérje a célhelyet. A TraceTCP az ugrások során használt kiszolgálók nevét is megadhatja, ami hasznos lehet egy Microsoft Office 365 hibaelhárító számára a támogatásban. > A TraceTCP-parancsok nagyon egyszerűek lehetnek, például: >tracetcp.exe outlook.office365.com:443> Ne felejtse el belefoglalni a portszámot a parancsba! >A TraceTCP egy ingyenes letöltés, de a Wincapre támaszkodik. A Wincap egy olyan eszköz, amelyet a Netmon is használ és telepít. A Speciális metódusok szakaszban a Netmonot is használjuk.

Ha több irodája is van, az ügyféltől származó adatokat is meg kell őriznie mindegyik helyen. Ez a teszt a késést méri, amely ebben az esetben egy számérték, amely azt az időtartamot írja le, amellyel egy ügyfél kérést küld a Office 365, és Office 365 válaszol a kérésre. A tesztelés egy ügyfélszámítógép tartományán belülről származik, és úgy néz ki, hogy a hálózaton belülről, egy kimenő ponton keresztül, az interneten keresztül a Office 365 és vissza irányuló utazást mér.

Többféleképpen is kezelhető a kimenő forgalom, ebben az esetben a proxykiszolgáló. A nyomkövetést 1 és 2, majd 2 és 3 között végezheti el, majd ezredmásodpercben adja hozzá a számokat, hogy a hálózat széléhez érhesse a végső összeget. Vagy úgy is konfigurálhatja a kapcsolatot, hogy megkerülje a proxyt Office 365 címekhez. Egy tűzfallal, fordított proxyval vagy a kettő valamilyen kombinációjával rendelkező nagyobb hálózaton előfordulhat, hogy kivételeket kell tennie a proxykiszolgálón, amely lehetővé teszi a forgalom áthaladását sok URL-cím esetében. A Office 365 által használt végpontok listájáért lásd: Office 365 URL-címek és IP-címtartományok. Ha hitelesítési proxyval rendelkezik, először tesztelje a következő kivételeket:

  • 80-at és 443-at

  • TCP és HTTP-k

  • Connections, amelyek a következő URL-címek bármelyikére kimenőek:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Minden felhasználónak engedélyeznie kell, hogy proxyinterferencia vagy hitelesítés nélkül érje el ezeket a címeket. Kisebb hálózat esetén ezeket a böngészőben kell hozzáadnia a proxy megkerülő listájához.

Ezeket az Internet Explorerben az Eszközök>Internetbeállítások>Connections>LAN-beállítások>Speciális lapon adhatja hozzá a proxy megkerülési listájához. A speciális lapon található a proxykiszolgáló és a proxykiszolgáló portja is. Előfordulhat, hogy a Speciális gomb eléréséhez be kell jelölnie a Proxykiszolgáló használata a lan-hoz jelölőnégyzetet. Győződjön meg arról, hogy a Proxykiszolgáló megkerülése a helyi címekhez jelölőnégyzet be van jelölve. Ha a Speciális lehetőséget választja, megjelenik egy szövegmező, amelyben kivételeket adhat meg. A fent felsorolt helyettesítő karakteres URL-címeket pontosvesszőkkel válassza el egymástól, például:

*.microsoftonline.com; *.sharepoint.com

Miután megkerülte a proxyt, képesnek kell lennie a ping vagy a PsPing használatára közvetlenül egy Office 365 URL-címen. A következő lépés a pingelési outlook.office365.com tesztelése lesz. Vagy ha a PsPing vagy más olyan eszközt használ, amely lehetővé teszi, hogy portszámot adjon meg a parancsnak, a PsPing a portal.microsoftonline.com:443 az átlagos utazási idő ezredmásodpercben való megtekintéséhez.

A körutazási idő (RTT) egy számérték, amely azt méri, hogy mennyi ideig tart egy HTTP-kérés küldése egy kiszolgálónak, például outlook.office365.com, és olyan választ kap, amely nyugtázza, hogy a kiszolgáló tudja, hogy ön tette. Ezt a rövidítést néha RTT-nek is nevezik. Ennek viszonylag rövid időnek kell lennie.

A teszt elvégzéséhez PSPing vagy más olyan eszközt kell használnia, amely nem használja az Office 365 által blokkolt ICMP-csomagokat.

A PsPing használata a teljes utazási idő ezredmásodpercben történő lekéréséhez közvetlenül egy Office 365 URL-címről

  1. Futtasson rendszergazda jogú parancssort az alábbi lépések végrehajtásával:

  2. Kattintson a Start gombra.

  3. A Start Keresés mezőbe írja be a cmd parancsot, majd nyomja le a CTRL+SHIFT+ENTER billentyűkombinációt.

  4. Ha megjelenik a Felhasználói fiókok felügyelete párbeszédpanel, győződjön meg arról, hogy a megjelenő művelet a kívánt, majd kattintson a Folytatás gombra.

  5. Lépjen arra a mappára, ahová az eszköz (ebben az esetben a PsPing) telepítve van, és tesztelje ezeket a Office 365 URL-címeket:

  • psping admin.microsoft.com:443

  • psping microsoft-my.sharepoint.com:443

  • psping outlook.office365.com:443

  • psping www.yammer.com:443

    A PSPing parancs a 443-microsoft-my.sharepoint.com portot fogja használni.

Ügyeljen arra, hogy a 443-at adja meg. Ne feledje, hogy Office 365 titkosított csatornán működik. Ha a PsPing paramétert a portszám nélkül teszi meg, a kérés sikertelen lesz. Miután pingelte a rövid listát, keresse meg az Átlagos idő ezredmásodpercben (ms) értékeket. Ezt szeretné rögzíteni!

Az ügyfél és a proxy PSPing közötti, 2,8 ezredmásodperces körúti időt ábrázoló ábra.

Ha nem ismeri a proxy megkerülését, és inkább lépésről lépésre halad, először ki kell derítenie a proxykiszolgáló nevét. Az Internet Explorerben válassza az Eszközök>Internetbeállítások>Connections>LAN-beállítások>Speciális lehetőséget. A Speciális lapon láthatja a proxykiszolgálót a listában. Pingelje a proxykiszolgálót egy parancssorban a következő feladat végrehajtásával:

A proxykiszolgáló pingelése és a körutazás értékének lekérése ezredmásodpercben az 1–2. fázishoz

  1. Futtasson rendszergazda jogú parancssort az alábbi lépések végrehajtásával:

  2. Kattintson a Start gombra.

  3. A Start Keresés mezőbe írja be a cmd parancsot, majd nyomja le a CTRL+SHIFT+ENTER billentyűkombinációt.

  4. Ha megjelenik a Felhasználói fiókok felügyelete párbeszédpanel, győződjön meg arról, hogy a megjelenő művelet a kívánt, majd kattintson a Folytatás gombra.

  5. Írja be, hogy pingelje <a böngésző által használt proxykiszolgáló nevét vagy a proxykiszolgáló> IP-címét, majd nyomja le az ENTER billentyűt. Ha telepítve van a PsPing vagy más eszköz, választhat, hogy ezt az eszközt használja.

    A parancs az alábbi példákhoz hasonlóan nézhet ki:

  • ping ourproxy.ourdomain.industry.business.com

  • ping 155.55.121.55

  • ping a miproxy

  • psping ourproxy.ourdomain.industry.business.com:80

  • psping 155.55.121.55:80

  • psping ourproxy:80

  1. Ha a nyomkövetés nem küld tesztcsomagokat, egy kis összegzést kap, amely egy átlagot listáz ezredmásodpercben, és ezt az értéket keresi. Készítsen képernyőképet a kérdésről, és mentse az elnevezési konvencióval. Ezen a ponton az is segíthet, ha a diagramot az értékkel tölti ki.

Lehet, hogy kora reggel nyomkövetést végzett, és az ügyfél gyorsan elérheti a proxyt (vagy bármilyen kimenő kiszolgálót, amely kilép az internetre). Ebben az esetben a számok a következőképpen nézhetnek ki:

Az ügyfél és a proxy közötti 2,8 ezredmásodperces útidőt bemutató ábra.

Ha az ügyfélszámítógép azon kiválasztott kevesek közé tartozik, amelyek hozzáférnek a proxykiszolgálóhoz (vagy a kimenő forgalomhoz), a teszt következő szakaszát futtathatja úgy, hogy távolról csatlakozik az adott számítógéphez, és onnan futtatja a PsPing parancssort egy Office 365 URL-címre. Ha nem fér hozzá a számítógéphez, a következő lépésben segítségért forduljon a hálózati erőforrásokhoz, és így pontos számokat kapjon. Ha ez nem lehetséges, vegyen fel egy PsPing-et a szóban forgó Office 365 URL-címhez, és hasonlítsa össze a proxykiszolgáló psping vagy pingelési idejével.

Ha például 51,84 ezredmásodperc van az ügyféltől a Office 365 URL-címig, és 2,8 ezredmásodperc van az ügyféltől a proxyig (vagy kimenő pontig), akkor a kimenő forgalomtól a Office 365 49,04 ezredmásodpercig tart. Hasonlóképpen, ha a psPing értéke 12,25 ezredmásodperc az ügyféltől a proxyig a nap magasságában, és 62,01 ezredmásodperc az ügyféltől az Office 365 URL-címig, akkor az Office 365 URL-címre irányuló proxykimenet átlagos értéke 49,76 ezredmásodperc.

További ábra, amely az ügyfél és a proxy közötti pingelést jeleníti meg ezredmásodpercben az ügyfél és a Office 365 mellett, hogy az értékek kivonhatók legyenek.

A hibaelhárítás szempontjából érdekes lehet, ha nem tartja meg ezeket az alapterveket. Ha például úgy találja, hogy általában körülbelül 40 ezredmásodperc és 59 ezredmásodperc közötti késés van a proxytól vagy a kimenő forgalom pontjától a Office 365 URL-címig, és az ügyfél és a proxy közötti vagy kimenő pont késése körülbelül 3 ezredmásodperctől 7 ezredmásodpercig (attól függően, hogy mennyi hálózati forgalmat lát az adott nap folyamán), akkor biztosan tudhatja, hogy valami problémás, ha az utolsó három ügyfél–proxy vagy kimenő forgalom alapkonfigurációja egy késése 45 ezredmásodperc.

Speciális metódusok

Ha valóban tudni szeretné, mi történik a Office 365 felé irányuló internetes kéréseivel, ismernie kell a hálózati nyomkövetéseket. Nem számít, hogy milyen eszközöket szeretne használni ezekhez a nyomkövetésekhez, a HTTPWatch, a Netmon, a Message Analyzer, a Wireshark, a Fiddler, a Fejlesztői irányítópult eszköz vagy bármely más eszköz mindaddig, amíg az eszköz képes rögzíteni és szűrni a hálózati forgalmat. Ebben a szakaszban láthatja, hogy érdemes több eszközt futtatni, hogy teljesebb képet kapjon a problémáról. A tesztelés során ezen eszközök némelyike saját jogán proxyként is működik. A Office 365 teljesítményével kapcsolatos hibaelhárítási terv című társcikkben használt eszközök közé tartozik a Netmon 3.4, a HTTPWatch vagy a WireShark.

Ennek a módszernek az egyszerű része a teljesítménykonfiguráció használata, és számos lépés ugyanaz, mint a teljesítményproblémák elhárítása során. Az alapkonfigurációk teljesítménybeli létrehozásának fejlettebb módszereihez hálózati nyomkövetéseket kell készítenie és tárolnia. A jelen cikkben szereplő példák többsége a SharePointot használja, de a teszteléshez és a rögzítéshez előfizetett Office 365 szolgáltatások gyakori műveleteinek listáját is ki kell dolgoznia. Íme egy alapkonfigurációs példa:

  • Az SPO alapkonfigurációs listája – ** 1. lépés: ** Tallózzon az SPO webhely kezdőlapján, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

  • SPO alapkonfigurációs listája – 2. lépés: Keresés egy kifejezéshez (például a vállalat nevéhez) a Vállalati Keresés keresztül, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

  • SPO alapkonfigurációs listája – 3. lépés: Töltsön fel egy nagy fájlt egy SharePoint-dokumentumtárba, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

  • Az SPO alapkonfigurációs listája – 4. lépés: Tallózással keresse meg a OneDrive webhely kezdőlapját, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

Ennek a listának tartalmaznia kell a felhasználók által a SharePointon végzett legfontosabb gyakori műveleteket. Figyelje meg, hogy az utolsó lépés, amely a OneDrive-ra való ugrást követi, összehasonlítja a SharePoint kezdőlapjának terhelését (amelyet gyakran vállalatok szabnak testre) és a OneDrive kezdőlapját, amely ritkán van testre szabva. Ez egy alapszintű teszt, amikor egy SharePoint-webhely lassan töltődik be. Ezt a különbséget rögzítheti a tesztelésben.

Ha teljesítményproblémát tapasztal, a lépések nagy része megegyezik az alapkonfigurációval. A hálózati nyomkövetések kritikus fontosságúak lesznek, ezért a következő lépésben a fontos nyomkövetések követését fogjuk kezelni.

A teljesítményproblémák megoldásához most nyomkövetést kell követnie a teljesítményprobadukta észlelése során. Rendelkeznie kell a megfelelő eszközökkel a naplók gyűjtéséhez, és szüksége van egy művelettervre, azaz a hibaelhárítási műveletek listájára, hogy a lehető legjobb információkat gyűjtse össze. Az első teendő a teszt dátumának és időpontjának rögzítése, hogy a fájlok az időzítést tükröző mappába legyenek mentve. Ezután szűkítse le a probléma lépéseit. Pontosan ezeket a lépéseket fogja használni a teszteléshez. Ne felejtse el az alapokat: ha a probléma csak az Outlookkal kapcsolatos, jegyezze fel, hogy a probléma viselkedése csak egy Office 365 szolgáltatásban fordul elő. Ha leszűkíti a probléma hatókörét, azzal segíthet, hogy a megoldható dolgokra összpontosítson.

Lásd még

Az Office 365-végpontok kezelése