Office 365 ladění výkonu pomocí standardních hodnot a historie výkonu
Existuje několik jednoduchých způsobů, jak zkontrolovat výkon připojení mezi Office 365 a vaší firmou, které vám umožní vytvořit hrubý směrný plán připojení. Znalost historie výkonu připojení ke klientským počítačům vám může pomoct včas odhalit nově vznikající problémy, identifikovat je a předvídat je.
Pokud nejste zvyklí na problémy s výkonem pracovat, je tento článek navržený tak, aby vám pomohl zvážit některé běžné otázky. Jak poznáte, že váš problém je problém s výkonem, a ne incident služby Office 365? Jak můžete dlouhodobě plánovat dobrý výkon? Jak můžete sledovat výkon? Pokud váš tým nebo klienti pozorují nízký výkon při používání Office 365 a zajímá vás některá z těchto otázek, čtěte dál.
Důležité
Máte právě teď problém s výkonem mezi klientem a Office 365? Postupujte podle kroků uvedených v plánu řešení potíží s výkonem pro Office 365.
Něco, co byste měli vědět o výkonu Office 365
Office 365 žije ve vysokokapacitní vyhrazené síti Microsoftu, kterou monitoruje automatizace a skuteční lidé. Součástí údržby Office 365 cloudu je optimalizace výkonu a jeho zjednodušení tam, kde je to možné. Vzhledem k tomu, že se klienti Office 365 cloudu musí připojovat přes internet, neustále probíhá úsilí o vyladění výkonu napříč Office 365 službami.
Vylepšení výkonu se v cloudu nikdy nezastaví, takže ani zkušenosti s udržováním cloudu v dobrém a rychlém stavu. Pokud máte problém s výkonem připojení z vaší lokality k Office 365, je nejlepší nezačínat s případem podpory nebo čekat na případ podpory. Místo toho byste měli začít zkoumat problém zevnitř. To znamená, že začnete v síti a vypracujte cestu k Office 365. Než otevřete případ s podporou, můžete shromáždit data a provést akce, které zkoumají a můžou problém vyřešit.
Důležité
Mějte na paměti plánování kapacity a omezení v Office 365. Tyto informace vás při pokusu o vyřešení problému s výkonem dostanou před křivku. Tady je odkaz na popisy služeb Microsoft 365 a Office 365. Toto je centrální centrum a všechny služby nabízené Office 365 mají odkaz, který odtud směřuje na jejich vlastní popisy služeb. To znamená, že pokud byste například potřebovali zobrazit standardní limity pro SharePoint, klikněte na Popis služby SharePoint a vyhledejte její oddíl Limity SharePointu.
Nezapomeňte se pustit do řešení potíží s pochopením, že výkon je posuvné měřítko. Nejde o dosažení idealizované hodnoty a její trvalé udržování. Občasné úlohy s velkou šířkou pásma, jako je nasazení velkého počtu uživatelů nebo provádění rozsáhlých migrací dat, budou stresující, proto naplánujte dopad na výkon. Měli byste mít hrubou představu o svých výkonnostních cílech, ale s výkonem hraje roli mnoho proměnných, takže se výkon liší.
Řešení potíží s výkonem nespočívá v plnění konkrétních cílů a udržování těchto čísel po neomezenou dobu, ale o vylepšování stávajících aktivit s ohledem na všechny proměnné.
Jak vypadá problém s výkonem?
Nejprve se musíte ujistit, že to, k čemu dochází, je skutečně problém s výkonem, a ne servisní incident. Problém s výkonem se liší od servisního incidentu v Office 365. Tady je postup, jak je oddělit.
K incidentům služby dochází, když má problémy samotná služba Office 365. V části Aktuální stav se v Centrum pro správu Microsoftu 365 můžou zobrazit červené nebo žluté ikony. Můžete si všimnout, že výkon klientských počítačů, které se připojují k Office 365 je pomalý. Pokud například Aktuální stav hlásí červenou ikonu a vedle Exchange se zobrazí Prošetřování, můžou vám taky volat lidé z vaší organizace, kteří si stěžují, že poštovní schránky klientů používající Exchange Online jsou pomalé. V takovém případě lze předpokládat, že se váš výkon Exchange Online stal obětí problémů se službou.
V tomto okamžiku byste jako správce Office 365 měli zkontrolovat Aktuální stav a pak často zobrazit podrobnosti a historii, abyste měli přehled o údržbě systému. Řídicí panel Aktuální stav byl proveden tak, aby vás aktualizoval o změnách a problémech ve službě. Poznámky a vysvětlení zapsané do historie stavu, od správce k správci, jsou k dispozici, aby vám pomohly měřit a udržovat informace o probíhající práci.
Problém s výkonem není servisní incident, i když incidenty můžou způsobit nízký výkon. Problém s výkonem vypadá takto:
K problému s výkonem dochází bez ohledu na to, co centrum pro správu Aktuální stav služby hlásí.
Chování, které se používalo k toku, trvá dlouho, než se dokončí, nebo se nikdy nedokončí.
Můžete také replikovat problém nebo vědět, že k němu dochází, pokud provedete správnou řadu kroků.
Pokud je problém přerušovaný, stále může existovat vzor. Víte například, že do 10:00 budete mít hovory od uživatelů, kteří nemají vždy přístup k Office 365. Volání skončí kolem poledne.
Tento seznam asi zní povědomě; možná až moc povědomé. Jakmile zjistíte, že se jedná o problém s výkonem, zobrazí se otázka: "Co děláte dál?" Zbytek tohoto článku vám pomůže přesně to určit.
Jak definovat a otestovat problém s výkonem
Problémy s výkonem se často objevují v průběhu času, takže může být obtížné definovat skutečný problém. Create dobré prohlášení o problému s dobrou představu o kontextu problému a pak potřebujete opakovatelné kroky testování. Tady je několik příkladů příkazů k problémům, které neposkytují dostatek informací:
Přechod ze složky Doručená pošta do kalendáře dřív byl něco, čeho jsem si nevšiml, a teď je to přestávka na kávu. Můžeš to dovést k tomu, aby se choval jako dřív?
Nahrávání souborů na SharePoint trvá věčně. Proč je to pomalé odpoledne, ale kdykoli jindy, je to rychlé? Nemůže to být jen rychlé?
Výše uvedená prohlášení o problému představují několik velkých problémů. Konkrétně příliš mnoho nejednoznačností, se kterými je třeba se vypořádat. Příklady:
Není jasné, jak na přenosném počítači fungovalo přepínání mezi doručenou poštou a kalendářem.
Když uživatel řekne " Nemůže to být jen rychlé", co je "rychlé"?
Jak dlouho je "navždy"? Je to několik sekund? Nebo mnoho minut? Nebo by si uživatel mohl vzít oběd a akce by se dokončila 10 minut po návratu?
Správce a poradce při potížích nemohou znát podrobnosti o problému z obecných prohlášení, jako jsou tato. Například nevědí, kdy k problému začalo docházet. Poradce při potížích nemusí vědět, že uživatel pracuje z domova, a pouze v domácí síti uvidí pomalé přepínání. Nebo že uživatel spustí na místním klientovi jiné aplikace náročné na paměť RAM. Správci nemusí vědět, že uživatel používá starší operační systém nebo nespustil nedávné aktualizace.
Když uživatelé nahlásí problém s výkonem, je potřeba shromáždit mnoho informací. Získání a záznam informací se označuje jako vymezení rozsahu problému. Tady je základní seznam oborů, který můžete použít ke shromažďování informací o problémech s výkonem. Tento seznam není vyčerpávající, ale je to místo, kde můžete začít:
Kdy k problému došlo a v jakou denní nebo noční dobu?
Jaký typ klientského počítače jste používali a jak se připojuje k podnikové síti (VPN, kabelové připojení, bezdrátové připojení)?
Pracoval(a) jste na dálku, nebo jste byl v kanceláři?
Vyzkoušeli jste stejné akce na jiném počítači a viděli jste stejné chování?
Projděte si kroky, které vám můžou dělat potíže, abyste si mohli zapsat akce, které provedete.
Jak pomalý je výkon v sekundách nebo minutách?
Kde na světě se nacházíte?
Některé z těchto otázek jsou zřetelnější než jiné. Většina lidí pochopí, že poradce při potížích potřebuje přesné kroky k reprodukci problému. Koneckonců, jak jinak můžete zaznamenat, co je špatně, a jak jinak můžete otestovat, jestli je problém opravený? Méně zřejmé jsou informace jako "What date and time you see the issue?" a "Where in the world are you located?" (Kde na světě se nacházíte?", což jsou informace, které se dají použít společně. V závislosti na tom, kdy uživatel pracoval, může několikahodinový časový rozdíl znamenat, že už probíhá údržba částí firemní sítě. Vaše společnost má například hybridní implementaci, jako je hybridní SharePoint Search, která může dotazovat indexy vyhledávání v SharePointu v Microsoft 365 i místní instanci SharePoint Serveru 2013. Aktualizace můžou v místní farmě právě probíhá. Pokud je vaše společnost v cloudu, může údržba systému zahrnovat přidání nebo odebrání síťového hardwaru, zavádění aktualizací, které jsou pro celou společnost, nebo provádění změn v DNS nebo jiné základní infrastruktuře.
Když řešíte problém s výkonem, je to trochu jako místo činu, musíte být přesný a pozorný, abyste z důkazů vyvozovali nějaké závěry. Abyste to mohli udělat, musíte získat dobré prohlášení o problému tím, že shromáždíte důkazy. Měl by obsahovat kontext počítače, kontext uživatele, kdy problém začal, a přesné kroky, které odhalily problém s výkonem. Toto prohlášení o problému by mělo být a mělo by zůstat nejvyšší stránkou v poznámkách. Když po práci na řešení znovu projdete prohlášení o problému, provedete kroky k otestování a ověření, jestli provedené akce problém vyřešily. To je důležité pro to, abyste věděli, kdy je vaše práce hotová.
Víte, jak vypadal výkon, když byl dobrý?
Jestli máš smůlu, nikdo to neví. Nikdo neměl čísla. To znamená, že nikdo nemůže odpovědět na jednoduchou otázku "Kolik sekund trvalo vyvolání doručené pošty v Office 365?", nebo "Jak dlouho to trvalo, když vedoucí pracovníci měli schůzku Lyncu Online?", což je běžný scénář pro mnoho společností.
Chybí zde standardní hodnoty výkonu.
Standardní hodnoty poskytují kontext pro váš výkon. V závislosti na potřebách vaší společnosti byste měli pravidelně používat směrný plán. Pokud jste větší společnost, váš provozní tým už může použít směrné plány pro vaše místní prostředí. Pokud například opravíte všechny servery Exchange první pondělí v měsíci a všechny sharepointové servery třetí pondělí, má váš provozní tým pravděpodobně seznam úkolů a scénářů, které po opravě spustí, aby dokázal, že jsou důležité funkce funkční. Můžete například otevřít složku Doručená pošta, kliknout na Odeslat a přijmout a ujistit se, že se složky aktualizují, nebo v SharePointu přejdete na hlavní stránku webu, přejdete na podnikovou Search stránku a provedete hledání, které vrátí výsledky.
Pokud jsou vaše aplikace v Office 365, některé z nejzákladnějších směrných plánů můžete měřit čas (v milisekundách) z klientského počítače ve vaší síti do výchozího bodu nebo bodu, kde opustíte síť a přejdete do Office 365. Tady je několik užitečných směrných plánů, které můžete prozkoumat a zaznamenat:
Identifikujte zařízení mezi klientským počítačem a výchozím bodem, například proxy serverem.
Musíte znát svá zařízení, abyste měli kontext (IP adresy, typ zařízení atd.) pro problémy s výkonem, které nastanou.
Proxy servery jsou běžné výchozí body, takže můžete zkontrolovat webový prohlížeč a zjistit, jaký proxy server je nastavený tak, aby používal (pokud nějaký).
Existují nástroje třetích stran, které můžou zjistit a mapovat vaši síť, ale nejbezpečnější způsob, jak poznat vaše zařízení, je požádat člena síťového týmu.
Identifikujte svého poskytovatele internetových služeb, zapište si jeho kontaktní informace a zeptejte se, kolik okruhů a kolik máte šířku pásma.
Ve vaší společnosti identifikujte prostředky pro zařízení mezi vaším klientem a výchozím bodem nebo identifikujte nouzový kontakt, se kterým chcete mluvit o problémech se sítí.
Tady je několik směrných plánů, které můžete vypočítat jednoduchým testováním pomocí nástrojů:
Doba od klientského počítače do výchozího bodu v milisekundách
Doba od výchozího bodu do Office 365 v milisekundách
Umístění ve světě serveru, který při procházení překládá adresy URL pro Office 365
Rychlost překladu DNS poskytovatele internetových služeb v milisekundách, nekonzistence při doručování paketů (chvění sítě), nahrávání a stahování v milisekundách
Pokud nevíte, jak tyto kroky provést, podrobněji se podíváme v tomto článku.
Co je směrný plán?
Když se to nepokazí, budete vědět, jaký to bude mít dopad, ale pokud neznáte historická data o výkonu, není možné mít kontext pro to, jak špatně se to mohlo stát a kdy. Takže bez účaří, chybí vám klíčové vodítko k vyřešení hádanky: obrázek na krabici puzzle. Při řešení potíží s výkonem potřebujete bod porovnání. Jednoduché standardní hodnoty výkonu nejsou obtížné. Váš provozní tým může mít za úkol provést je podle plánu. Řekněme například, že vaše připojení vypadá takto:
To znamená, že jste se spojili se svým síťovým týmem a zjistili jste, že odcházíte ze společnosti na internet prostřednictvím proxy serveru a že proxy server zpracovává všechny požadavky, které klientský počítač odesílá do cloudu. V takovém případě byste měli nakreslit zjednodušenou verzi připojení, která obsahuje seznam všech zařízení, která zasahují. Teď vložte nástroje, které můžete použít k otestování výkonu mezi klientem, výchozím bodem (kde opustíte síť pro internet) a Office 365 cloudem.
Možnosti jsou uvedené jako Jednoduché a Pokročilé kvůli množství odborných znalostí, které potřebujete k vyhledání dat o výkonu. Trasování sítě bude trvat hodně času v porovnání se spouštěním nástrojů příkazového řádku, jako jsou PsPing a TraceTCP. Tyto dva nástroje příkazového řádku byly zvoleny, protože nepoužívají pakety ICMP, které budou blokovány Office 365, a protože poskytují čas v milisekundách, který trvá opuštění klientského počítače nebo proxy serveru (pokud máte přístup) a doručení Office 365. Každý jednotlivý směrování z jednoho počítače do druhého bude mít časovou hodnotu, což je skvělé pro směrné plány. Stejně důležité je, že tyto nástroje příkazového řádku umožňují přidat do příkazu číslo portu. To je užitečné, protože Office 365 komunikuje přes port 443, což je port používaný protokolem SSL a TLS (Secure Sockets Layer). Lepším řešením pro vaši situaci ale můžou být jiné nástroje třetích stran. Microsoft nepodporuje všechny tyto nástroje, takže pokud z nějakého důvodu nemůžete z nějakého důvodu zpracovat PsPing a TraceTCP, přejděte k trasování sítě pomocí nástroje, jako je Netmon.
Směrný plán si můžete vzít před pracovní dobou, znovu při intenzivním používání a pak znovu po hodinách. To znamená, že můžete mít strukturu složek, která na konci vypadá trochu takto:
Měli byste také vybrat zásady vytváření názvů pro vaše soubory. Tady je pár příkladů:
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
Existuje mnoho různých způsobů, jak to udělat, ale použití formátu <dateTime><, co se děje v testu> , je vhodné začít. Když se budete později pokoušet o řešení potíží, bude vám to hodně pomoct. Později budete moct říct: "Vzal jsem dvě stopy 8. února, jedna ukázala dobrý výkon a druhá ukázala špatný, takže je můžeme porovnat". To je užitečné při řešení potíží.
Musíte mít uspořádaný způsob, jak zachovat historické směrné hodnoty. V tomto příkladu jednoduché metody vytvořily tři výstupy příkazového řádku a výsledky byly shromážděny jako snímky obrazovky, ale místo toho můžete mít soubory síťového záznamu. Použijte metodu, která vám nejlépe vyhovuje. Uložte si historické směrné plány a odkazujte na ně v bodech, kdy si všimnete změn v chování online služby.
Proč shromažďovat data o výkonu během pilotního nasazení?
Není lepší čas začít vytvářet směrné plány než během pilotního nasazení služby Office 365. Vaše kancelář může mít tisíce uživatelů, stovky tisíc nebo pět, ale i s několika uživateli můžete provádět testy a měřit kolísání výkonu. V případě velké společnosti lze reprezentativní vzorek několika stovek uživatelů pilotních Office 365 promítnout do několika tisíc, abyste věděli, kde může dojít k problémům dříve, než k nim dojde.
V případě malé společnosti, kde onboarding znamená, že všichni uživatelé přejdou do služby najednou a není k dispozici žádný pilotní projekt, udržujte míry výkonu, abyste měli data, která můžete ukázat komukoli, kdo by mohl muset řešit potíže s chybnou operací. Pokud si například všimnete, že najednou můžete procházet budovu v době, za kterou je potřeba nahrát středně velkou grafiku tam, kam se to dřív rychle dělo.
Shromažďování směrných plánů
U všech plánů řešení potíží je potřeba identifikovat minimálně tyto věci:
Klientský počítač, který používáte (typ počítače nebo zařízení, IP adresa a akce, které způsobily problém)
Kde se klientský počítač nachází na světě (například jestli je tento uživatel na síti VPN, pracuje vzdáleně nebo na podnikovém intranetu)
Výchozí bod, který klientský počítač používá z vaší sítě (bod, ve kterém provoz odchází z vaší firmy pro isp nebo internet)
Rozložení sítě můžete zjistit od správce sítě. Pokud jste v malé síti, podívejte se na zařízení, která vás připojují k internetu, a pokud máte dotazy týkající se rozložení, zavolejte svého isp. Create obrázek konečného rozložení pro referenci.
Tato část je rozdělená na jednoduché nástroje a metody příkazového řádku a pokročilejší možnosti nástrojů. Nejprve si probereme jednoduché metody. Pokud ale máte právě teď problém s výkonem, měli byste přejít na pokročilé metody a vyzkoušet ukázkový akční plán pro řešení potíží s výkonem.
Jednoduché metody
Cílem těchto jednoduchých metod je naučit se přijímat, rozumět a správně ukládat jednoduché standardní hodnoty výkonu v průběhu času, abyste byli informováni o výkonu Office 365. Tady je jednoduchý diagram pro jednoduché, jak jste viděli dříve:
Poznámka
TraceTCP je součástí tohoto snímku obrazovky, protože je to užitečný nástroj, který v milisekundách ukazuje, jak dlouho trvá zpracování požadavku a kolik síťových směrování nebo připojení z jednoho počítače do druhého trvá, než požadavek dosáhne cíle. TraceTCP může také poskytnout názvy serverů používaných během směrování, což může být užitečné pro poradce při potížích s Microsoft Office 365 v části Podpora. > Příkazy TraceTCP můžou být velmi jednoduché, například: >tracetcp.exe outlook.office365.com:443> Nezapomeňte do příkazu zahrnout číslo portu! >TraceTCP je zdarma ke stažení, ale spoléhá na Wincap. Wincap je nástroj, který také používá a instaluje netmon. V části pokročilé metody také používáme Netmon.
Pokud máte více poboček, budete muset uchovávat sadu dat z klienta také v každém z těchto umístění. Tento test měří latenci, což je v tomto případě číselná hodnota, která popisuje dobu mezi tím, než klient odešle požadavek Office 365, a Office 365 na žádost odpoví. Testování pochází z vaší domény na klientském počítači a má změřit dobu odezvy z vaší sítě, přes výchozí bod, přes internet, Office 365 a zpět.
Existuje několik způsobů, jak se vypořádat s výchozím bodem, v tomto případě proxy serverem. Můžete buď trasovat od 1 do 2 a pak od 2 do 3 a pak sečíst čísla v milisekundách, abyste získali konečný součet na hranici sítě. Nebo můžete nakonfigurovat připojení tak, aby obešla proxy server pro Office 365 adresy. Ve větší síti s bránou firewall, reverzním proxy serverem nebo nějakou jejich kombinací možná budete muset na proxy serveru udělat výjimky, které umožní průchod provozu pro velké množství adres URL. Seznam koncových bodů používaných Office 365 najdete v tématu Office 365 adresy URL a rozsahy IP adres. Pokud máte ověřovací proxy server, začněte testováním výjimek pro následující:
Porty 80 a 443
TCP a HTTPs
Connections, které jsou odchozí na některou z těchto adres URL:
*.microsoftonline.com
*.microsoftonline-p.com
*.sharepoint.com
*.outlook.com
*.lync.com
osub.microsoft.com
Všem uživatelům musí být povoleno, aby se na tyto adresy dostali bez jakéhokoli rušení nebo ověřování proxy. V menší síti byste je měli přidat do seznamu proxy adres ve webovém prohlížeči.
Pokud je chcete přidat do seznamu obejití proxy serveru v Internet Exploreru, přejděte na Nástroje>Možnosti> Internetu Connections>Nastavení sítěLAN>Upřesnit. Na kartě Upřesnit najdete také svůj proxy server a port proxy serveru. Možná budete muset zaškrtnout políčko Pro přístup k tlačítku Upřesnit použít proxy server pro vaši síť LAN. Ujistěte se, že je zaškrtnuté políčko Vynechat proxy server pro místní adresy . Jakmile vyberete Upřesnit, zobrazí se textové pole, do kterého můžete zadávat výjimky. Výše uvedené adresy URL zástupných znaků oddělte středníky, například:
*.microsoftonline.com; *.sharepoint.com
Po obejití proxy serveru byste měli být schopni použít příkaz ping nebo PsPing přímo na adrese URL Office 365. Dalším krokem bude testování outlook.office365.com příkazem ping. Nebo pokud používáte PsPing nebo jiný nástroj, který vám umožní zadat číslo portu příkazu, PsPing proti portal.microsoftonline.com:443 zobrazit průměrnou dobu odezvy v milisekundách.
Doba odezvy (RTT) je číselná hodnota, která měří, jak dlouho trvá odeslání požadavku HTTP na server, jako je outlook.office365.com, a získání odpovědi, která potvrdí, že jste to udělali. Někdy se zobrazí zkrácený formát RTT. Mělo by to být poměrně krátké časové období.
Abyste mohli provést tento test, musíte použít PSPing nebo jiný nástroj, který nepoužívá pakety ICMP blokované Office 365.
Jak pomocí PsPingu získat celkovou dobu odezvy v milisekundách přímo z adresy URL Office 365
Provedením těchto kroků spusťte příkazový řádek se zvýšenými oprávněními:
Klikněte na tlačítko Start.
Do pole Spustit Search zadejte cmd a stiskněte kombinaci kláves CTRL+SHIFT+ENTER.
Pokud se zobrazí dialogové okno Řízení uživatelských účtů , potvrďte, že zobrazená akce odpovídá tomu, co chcete, a potom klikněte na Pokračovat.
Přejděte do složky, ve které je nástroj (v tomto případě PsPing) nainstalovaný, a otestujte tyto adresy URL Office 365:
psping admin.microsoft.com:443
psping microsoft-my.sharepoint.com:443
psping outlook.office365.com:443
-
Nezapomeňte uvést číslo portu 443. Nezapomeňte, že Office 365 funguje na šifrovaných kanálech. Pokud psPing bez čísla portu, vaše žádost se nezdaří. Jakmile svůj krátký seznam odešlete příkazem ping, vyhledejte průměrnou dobu v milisekundách (ms). To je to, co chcete nahrát!
Pokud nemáte zkušenosti s obejitím proxy serveru a dáváte přednost krokování, musíte nejdřív zjistit název proxy serveru. V Internet Exploreru přejděte na Nástroje>Možnosti> internetu Connections>Upřesnit nastavení >sítěLAN. Na kartě Upřesnit uvidíte seznam proxy serveru. Odesláním příkazu ping na tento proxy server na příkazovém řádku dokončete tuto úlohu:
Příkaz ping proxy serveru a získání hodnoty odezvy v milisekundách pro fázi 1 až 2
Provedením těchto kroků spusťte příkazový řádek se zvýšenými oprávněními:
Klikněte na tlačítko Start.
Do pole Spustit Search zadejte cmd a stiskněte kombinaci kláves CTRL+SHIFT+ENTER.
Pokud se zobrazí dialogové okno Řízení uživatelských účtů , potvrďte, že zobrazená akce odpovídá tomu, co chcete, a potom klikněte na Pokračovat.
Zadejte ping <název proxy serveru používaného prohlížečem nebo IP adresu proxy serveru> a stiskněte enter. Pokud máte nainstalovaný Nástroj PsPing nebo nějaký jiný nástroj, můžete místo toho použít tento nástroj.
Příkaz může vypadat jako některý z těchto příkladů:
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
- Když trasování přestane posílat testovací pakety, získáte malý souhrn, který obsahuje průměr v milisekundách a to je hodnota, za kterou právě stojíte. Pořiďte snímek obrazovky s výzvou a uložte ho podle zásad vytváření názvů. V tomto okamžiku může také pomoct vyplnit diagram hodnotou.
Možná jste provedli trasování brzy ráno a váš klient se může rychle dostat k proxy serveru (nebo k libovolnému výstupnímu serveru, který opustí internet). V tomto případě můžou vaše čísla vypadat takto:
Pokud je váš klientský počítač jedním z vybraných počítačů s přístupem k proxy serveru (nebo serveru výchozího přenosu dat), můžete spustit další část testu vzdáleným připojením k ho počítači a spuštěním příkazového řádku psPing na adresu URL Office 365 odtud. Pokud k počítači nemáte přístup, můžete se obrátit na síťové prostředky a požádat o pomoc s dalším úsekem a získat tak přesná čísla. Pokud to není možné, použijte PsPing pro příslušnou adresu URL Office 365 a porovnejte ji s časem PsPing nebo Ping vůči proxy serveru.
Pokud máte například 51,84 milisekund od klienta k adrese URL Office 365 a máte 2,8 milisekund od klienta k proxy serveru (nebo výchozí bod), pak máte 49,04 milisekund od výchozího přenosu do Office 365. Podobně pokud máte PsPing 12,25 milisekund mezi klientem a proxy serverem ve výšce dne a 62,01 milisekund od klienta k adrese URL Office 365, pak je průměrná hodnota výchozího přenosu proxy serveru na adresu URL Office 365 49,76 milisekund.
Pokud jde o řešení potíží, můžete najít něco zajímavého jen z udržování těchto standardních hodnot. Pokud například zjistíte, že z proxy serveru nebo výchozího přenosu dat na adresu URL Office 365 obvykle máte latenci přibližně 40 až 59 milisekund, a mít klienta na proxy nebo výchozí bod latence přibližně 3 milisekund až 7 milisekund (v závislosti na množství síťového provozu, který během dne vidíte), pak určitě víte, že něco je problematické, pokud vaše poslední tři směrné hodnoty klienta pro proxy nebo výchozí přenos dat ukazují latence 45 milisekund.
Pokročilé metody
Pokud opravdu chcete vědět, co se děje s vašimi internetovými požadavky na Office 365, musíte se seznámit s trasování sítě. Nezáleží na tom, které nástroje dáváte přednost pro tato trasování: HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard nebo jakýkoli jiný nástroj bude dělat tak dlouho, dokud tento nástroj dokáže zachytit a filtrovat síťový provoz. V této části uvidíte, že je výhodné spustit více než jeden z těchto nástrojů, abyste získali úplnější představu o problému. Při testování fungují některé z těchto nástrojů také jako proxy servery. Mezi nástroje použité v doprovodné části Plán řešení potíží s výkonem pro Office 365 patří Netmon 3.4, HTTPWatch nebo WireShark.
Použití standardních hodnot výkonu je jednoduchou součástí této metody a mnoho kroků je stejných jako při řešení potíží s výkonem. Pokročilejší metody vytváření standardních hodnot výkonu vyžadují, abyste posílali a ukládali trasování sítě. Většina příkladů v tomto článku používá SharePoint, ale měli byste vytvořit seznam běžných akcí napříč Office 365 službami, ke kterým se přihlásíte k odběru testování a záznamu. Tady je příklad směrného plánu:
Seznam směrných hodnot pro SPO – ** Krok 1: ** Projděte domovskou stránku webu SPO a proveďte trasování sítě. Uložte trasování.
Seznam směrných plánů pro SPO – krok 2: Search termínu (například název vaší společnosti) prostřednictvím podnikového Search a proveďte trasování sítě. Uložte trasování.
Seznam směrných hodnot pro SPO – krok 3: Nahrajte velký soubor do knihovny dokumentů SharePointu a proveďte trasování v síti. Uložte trasování.
Seznam směrných hodnot pro SPO – krok 4: Projděte domovskou stránku webu OneDrive a proveďte trasování sítě. Uložte trasování.
Tento seznam by měl obsahovat nejdůležitější běžné akce, které uživatelé vůči SharePointu podniknou. Všimněte si, že v posledním kroku, když chcete trasovat přechod na OneDrive, se sestaví porovnání zatížení domovské stránky SharePointu (která je často přizpůsobená společnostmi) a domovské stránky OneDrivu, která se málokdy přizpůsobí. Jedná se o základní test, pokud jde o pomalý sharepointový web. Záznam tohoto rozdílu můžete do testování zabudovat.
Pokud se nacházíte uprostřed problému s výkonem, mnoho kroků je stejných jako při použití standardních hodnot. Trasování sítě se stane kritickým, takže se postaráme o to, jak provést důležitá trasování.
Pokud chcete vyřešit problém s výkonem, musíte v tuto chvíli provést trasování v době, kdy dochází k problému s výkonem. Potřebujete mít k dispozici správné nástroje pro shromažďování protokolů a potřebujete plán akcí, to znamená seznam akcí pro řešení potíží, které je třeba provést, abyste shromáždili nejlepší informace, které můžete. První věc, kterou je třeba udělat, je zaznamenat datum a čas testu, aby se soubory mohly uložit do složky, která odráží časování. Dále zpřesníte jednotlivé kroky problému. Toto jsou přesné kroky, které použijete k testování. Nezapomeňte na základní informace: Pokud se problém týká jenom Outlooku, nezapomeňte zaznamenat, že k problémovým chováním dochází jenom v jedné Office 365 službě. Zúžení rozsahu tohoto problému vám pomůže soustředit se na něco, co můžete vyřešit.