Tento článek pomáhá administrátorům, IT pracovníkům nebo jinému technickému personálu podporujícímu nasazení utility network pochopit, jak interpretovat informace z protokolů specifické pro jeho pracovní postupy. Článek je místy velmi technický a vyžaduje dobré porozumění konceptům a technologiím používaným k popisu utility network.
Úprava: Pokud chcete provádět vlastní analýzu a parsování protokolů, můžete najít příkladové Python nástroje použité k vytvoření grafů v tomto článku zde.
Tento článek byl napsán, aby pomohl administrátorům, IT pracovníkům nebo jinému technickému personálu podporujícímu nasazení utility network pochopit, jak interpretovat informace z protokolů specifické pro jeho pracovní postupy. Článek je místy velmi technický a vyžaduje dobré porozumění konceptům a technologiím používaným k popisu utility network.
Pro pochopení tohoto článku musíte nejprve přečíst a být obeznámeni s článkem Utility Network Diagnostics. Tento článek popisuje, jak zachytit informace z protokolů pro různé operace utility network. Tento článek navazuje na tyto koncepty tím, že poskytuje tipy pro interpretaci těchto protokolů a jak lze extrahovat metriky výkonu pro hodnocení výkonnosti vašeho systému. Tyto protokoly nenahrazují nástroje jako ArcGIS Monitor, ale umožňují vám podrobněji prozkoumat a vyšetřit možné úzká místa ve výkonu.
Proč je to důležité?
Schopnost přesně měřit a hodnotit výkon je důležitá dovednost, protože vám umožní kvantifikovat dopady vašich rozhodnutí o modelování dat nebo architektuře. Sbírku zdrojů diskutujících dopad těchto rozhodnutí najdete v závěru tohoto článku.
Poznámka: Tento článek zobrazuje snímky obrazovky různých grafů a protokolů, ale neobsahuje žádná ukázková data k práci. Grafy používají různé datové sady a škály a neměly by být použity k vyvozování závěrů. Pro vyvození závěrů byste měli provést testování s vlastními daty pomocí technik popsaných v tomto článku. Protokoly uvedené v tomto článku jsou z ArcGIS Enterprise 12.1, takže novější i starší verze mohou zobrazovat jiné zprávy. Konkrétní formulace a struktura souborů protokolů se mění s každým vydáním, proto je důležité rozumět interpretaci protokolů místo pouhého zapamatování konkrétních zpráv.
Dalším důležitým poznatkem z tohoto článku je zamyslet se nad tím, jak jsou protokoly používány. Jsou důležitým nástrojem pro řešení problémů a také mohou ukázat dopad rozhodnutí o modelování dat, konfiguraci nebo dokonce architektuře na výkon a uživatelský zážitek.
Serverové protokoly poskytují podrobné informace, které vám umožní měřit výkon konkrétních operací, a v mnoha případech také umožňují korelovat dopady na výkon s konkrétními podsítěmi nebo počtem prvků ovlivněných danou operací. Pro příklad důležitosti si představte situaci, kdy uživatel stěžuje na příliš pomalou aktualizaci podsítí.
Normální hodnocení výkonu by spustilo operaci aktualizace podsítě u všech podsítí v systému pomocí jednoho procesu, aby vytvořilo graf zobrazující doby odezvy vrácené tímto serverem. Výsledkem je graf jako následující:
I když je zajímavé vidět rozložení dob odezvy, neposkytuje žádný vhled do toho, proč jsou některé odpovědi lepší než jiné nebo co vyžaduje další vyšetřování. Tento přístup totiž považuje každou odpověď za stejnou, což u podsítí neplatí. Parsováním souborů protokolů můžete vytvořit grafy nabízející více akčních poznatků.
Jednoduchá věc, kterou můžete udělat pro identifikaci problematických podsítí k přezkoumání, je vytvořit graf zahrnující název podsítě z protokolů spolu s její dobou odezvy.
To vám umožní najít konkrétní podsíť v datech k vyšetření a zároveň získat představu o tom, jak se celkový systém chová. Usnadňuje to identifikaci vašich nejlepších i nejhorších podsítí i případných odlehlých hodnot.
S trochou více práce můžete také parsovat počet prvků v každé podsíti ze souborů protokolů. To vám umožní vytvořit graf používající počet prvků v každé podsíti na ose X.
Tento graf usnadňuje vidět korelaci mezi velikostí sítě a dobou odezvy. Ukazuje vám, že většinou trvají déle aktualizace větších podsítí. Také vidíte několik menších sítí, které trvají déle než očekáváno, což vám umožní zaměřit pozornost na ně.
Tento přístup můžete posunout ještě dál parsováním podrobnějších informací z protokolů pro zobrazení časování spojeného s konkrétními operacemi v každé podsíti.
Tento graf vám umožní vidět operace a podsítě zabírající nejvíce času. Tyto podrobné informace vám umožní zjistit kroky ke zlepšení časování těchto konkrétních operací.
V tomto článku se naučíte některá klíčová hlediska při interpretaci časů následujících protokolů:
- Tracing používá TraceLog
- Update Subnetwork používá UpdateSubnetworkLog
- Export Subnetwork používá ExportSubnetworkLog
- Enable Network Topology a Validate Network Topology používají BuildLog
Než budeme mluvit o jednotlivých protokolech, pojďme si vysvětlit důležitost použití těchto nástrojů k izolaci a řešení problémů s výkonem.
Izolace výkonu
Při řešení problému s výkonem v ArcGIS Enterprise může být příčina způsobena širokou škálou architektonických, konfiguračních nebo dokonce datových problémů. Pokud se problém týká výkonu jediné operace v utility network bez potřeby verzování, dobrým způsobem ke snížení závislostí a izolaci problému je nejprve zkopírovat utility network do nové mobilní geodatabáze.
Prací s lokální mobilní geodatabází se můžete soustředit na výkon utility network samotné bez dalších proměnných spojených s architekturou nasazení ArcGIS Enterprise. To vám umožní zaměřit se na workflow jednoho uživatele bez verzování.
Výkon utility network v lokálním prostředí není ekvivalentní prostředí enterprise. Nicméně to umožňuje určit, zda je problém s výkonem způsoben daty a konfigurací utility network nebo architekturou a konfigurací prostředí.
Pokud se problém s výkonem nepodaří reprodukovat v lokálním prostředí, můžete stále využít informace získané z lokálních testů k informování vašeho šetření v enterprise. Můžete porovnat časy a kroky podrobných protokolů mezi lokální geodatabází a enterprise geodatabází a zjistit, zda nějaký krok netrvá déle. To může naznačovat problém s databází, který můžete dále analyzovat pomocí plánů výkonu dostupných nástrojů pro váš DBMS.
Můžete také porovnat čas každé operace hlášený logy ArcGIS Serveru s časy odezvy hlášenými klientem. Pokud jsou mezi nimi velké rozdíly nebo nekonzistentní doby odezvy, může to naznačovat komunikační problém mezi klientem a serverem. Níže uvedené obrázky ukazují časování zachycená různými logy.
Měření doby odezvy klienta zahrnuje celkový čas strávený dokončením požadavku na aplikačním serveru i datové vrstvě architektury. Často to není užitečné pro identifikaci základní příčiny problému s výkonem, ale zůstává důležité pro úplné pochopení kontextu a workflow potřebného k reprodukci problému.
Logy ArcGIS Serveru vám umožňují zaměřit se na čas strávený na serveru a datové vrstvě při současném poskytování kontextu každého požadavku kromě času jeho trvání.
Revize výkonu na úrovni databázové vrstvy také poskytuje užitečný vhled do problémů s výkonem, zejména pokud jsou databázově související, ale postrádá kontext klienta nebo aplikační vrstvy.
Kopírování dat do lokální mobilní geodatabáze a zachytávání logů pomocí Diagnostic Monitor v ArcGIS Pro je silný způsob izolace problémů s výkonem. Umožňuje to kontrolovat workflow a kontext každé operace při současném měření jejího výkonu s co nejmenším počtem závislostí. Níže vidíte diagram scénáře.
Nyní když rozumíte tomu jak a proč izolovat problémy s výkonem při testování, podíváme se na to, jak analyzovat logy utility network pro informace o výkonu.
Trace Log
Trace Log má čtyři důležité sekce:
- Prostředí
- Parametry trasování
- Kroky a časy
- Statistiky indexu sítě
Při hodnocení celkového výkonu systému je běžné sledovat celkový čas trvání každého trasování ve vztahu k počtu vrácených prvků. Nejčastější testovací scénář spočívá ve spuštění trasování podsítě pro každou podsíť v utility network a následném měření času trvání trasování vůči počtu prvků v každé podsíti.
Trasování stejné podsítě vrátí různé výkonnostní údaje podle toho, zda jde o uživatelem nakonfigurované trasování nebo trasování používané operacemi export subnetwork či update subnetwork. Při měření výkonnosti trasování byste měli sledovat výkonnost trasování podsítí podle vaší standardní konfigurace během update subnetwork. Pokud plánujete použít export subnetwork, měli byste také plánovat měření výkonnosti trasování během export subnetwork podle očekávané konfigurace.
Pokud určitá podsíť nedosahuje požadovaného výkonu, můžete pak sledovat čas spojený s jednotlivými kroky u každé podsítě vůči počtu prvků v každé podsíti.
Když se podíváte na různé kroky spojené s operací trace, začnete chápat, proč některé trace trvají déle, a jaký významný dopad má konfigurace trace na celkový výkon.
Například pokud použijete takovýto graf k analýze výkonu trace po přidání funkcí nebo specifických typů výsledků, budete schopni změřit náklady na výkon těchto konkrétních změn, přičemž každá je zobrazena jako samostatná operace s přiřazenými náklady.
Prostředí a parametry Trace
Konfigurační sekce vám pomůže pochopit kontext trace. Sdělí typ trace, verzi, výchozí body a konfiguraci trace spolu se specifikovanými typy výsledků pro trace. Všechny tyto parametry ovlivňují chování trace. Změna kterékoli z nich by vedla k odlišnému výsledku a mohla by ovlivnit výkon.
Kroky a časy
Tato část záznamu obsahuje podrobné informace o všech operacích provedených během trace a o tom, jak dlouho každá trvala. Některé kroky také zahrnují informace o tom, kolik prvků bylo zapojeno v daném kroku trace.
Při analýze času je první věcí, kterou chcete udělat, podívat se na celkový čas trace, poté na velikost výsledků. Počet procházených a vrácených prvků je uveden na konci sekce Kroky a časy v následujících řádcích:
Celkový čas Trace je snadno pochopitelný; jedná se o celkový čas potřebný k provedení trace. Počet nalezených prvků vyžaduje trochu více úvahy, protože zahrnuje počet procházených prvků spolu s počtem prvků ve výsledku.
To je důležité, protože mnoho trace prochází mnoho prvků, ale vrací pouze podmnožinu výsledků. I když může být vrácen malý počet prvků, trace může vyžadovat analýzu mnoha prvků. Příklady zahrnují upstream nebo downstream trace, trace s nakonfigurovanou filtrační bariérou nebo trace spuštěné během update subnetwork k objevení prvků ve více subnetworks. Proto jsou procházené prvky často lepším ukazatelem výkonu než velikost výsledku.
Také budete chtít zkontrolovat jednotlivé kroky a jejich časy během trace. Tyto detaily vám ukážou, kde je během trace tráven čas.
Statistiky síťového indexu
Statistiky síťového indexu vám sdělí, kolik síťových informací bylo načteno z databáze během analýzy. Tyto záznamy obvykle používají pouze podpora a vývoj k diagnostice konkrétních problémů.
Tato sekce obsahuje následující statistiky:
- Statistiky tabulky topologie – Shrnutí počtu řádků přečtených z topologie sítě.
- Statistiky tabulek asociací – Shrnutí počtu přečtených asociací.
- Statistiky Weight engine – Shrnutí počtu přečtených atributů sítě.
- Statistiky správce paměti – Shrnutí použité paměti.
Pokud se rozhodnete podrobněji prozkoumat statistiky v této zprávě, můžete si všimnout, že ne všechny atributy sítě jsou uvedeny v sekci statistik Weight engine. Je to proto, že síťové atributy uložené in-line jsou uloženy uvnitř tabulek topologie a jsou zahrnuty při přístupu ke konektivitě prvku z databáze. Každý out-of-line síťový atribut načtený ze síťového indexu má s sebou malou cenu, obvykle ne více než několik milisekund u malé sítě. Nicméně při načítání mnoha out-of-line atributů nebo u větší sítě může být tato cena znatelná.
To je důvod, proč byste měli zvážit ukládání síťových atributů potřebných pro většinu vašich trace in-line, zejména těch odkazovaných vaší definicí subnetwork. Proč nejsou všechny síťové atributy uloženy in-line? Protože je omezené množství úložiště dostupného pro in-line síťové atributy, musíte tedy rozhodnout, které atributy jsou nejdůležitější a zajistit jejich uložení in-line. Také si všimnete, že síťové atributy uložené in-line se neobjevují ve statistikách síťového indexu.
Při porovnávání výsledků mezi dvěma testy můžete také sledovat cache misses, abyste zjistili, kolik bylo dostupné v paměti (v cache) oproti řádkům načteným z databáze.
Při porovnávání výkonu mezi různými traces nebo operacemi je důležité věnovat pozornost počtu cache misses. Trace spuštěný kompletně z paměti (hot cache) bude mít lepší výkon než stejný trace, který musí načítat informace o konektivitě z databáze (cold cache).
V uživatelských pracovních postupech toho moc neovlivníte, ale je důležité to zvážit při nastavování konzistentní testovací metodiky, abyste mohli přesně porovnat výsledky různých testů. Nejkonzervativnější a nejkonzistentnější způsob měření výsledků je zajistit, aby všechny testy byly prováděny proti cold cache.
Záznam update subnetwork
Při hodnocení výkonu update subnetwork byste měli začít pohledem na Záznam update subnetwork vytvořený během operace update subnetwork. Často také budete chtít zkontrolovat Trace Log spojený s každou subnetwork, protože ten často představuje většinu času stráveného aktualizací subnetwork.
Poznámka: Při kontrole Trace Log pro update subnetwork si můžete všimnout, že kroky a časy se liší oproti běžnému spuštění trace. Záleží to na konfiguraci vaší sítě, ale uvidíte více času stráveného hledáním prvků ve více subnetworks (pro sítě s propagací), čas strávený získáváním geometrie pro výpočet linky subnetwork i čas strávený výpočtem funkcí pro agregovanou linku.
Stejně jako Trace Log má i update subnetwork log tři sekce.
- Prostředí
- Parametry Subnetwork
- Kroky a časy
- Statistiky síťového indexu
Při hodnocení výkonu update subnetwork zvážíte následující informace:
- Jak dlouho trvala aktualizace subnetwork?
- Jak velká byla aktualizovaná subnetwork?
- Kolik prvků bylo aktualizováno?
První dvě lze snadno zjistit ze záznamu; poslední vyžaduje přečtení záznamu k určení počtu změněných prvků.
Při hodnocení celkového výkonu systému obvykle sledujete dobu potřebnou k aktualizaci každé subnetwork v systému vůči počtu prvků v subnetwork.
Při této analýze můžete zvážit tři různé scénáře:
- Jak dlouho trvá provedení první operace update subnetwork?
- Jak dlouho trvá aktualizace subnetwork, když se nic nezměnilo?
- Jak dlouho trvá aktualizace subnetwork při rozumném počtu změněných prvků?
Obvykle se chcete zaměřit na to, jak dlouho trvá spuštění update subnetwork při rozumném počtu úprav, protože to uživatelé zažívají ve svých denních pracovních postupech. První update subnetwork je důležitý zvážit, protože je nejvíce časově náročný a musí být proveden při nasazení systému. Scénář bez změn je zajímavý jako nejlepší možný případ pro výkon.
Když najdete subnetwork s nízkým výkonem, můžete se podívat na časy jednotlivých kroků a zjistit, zda nějaký krok nezabírá většinu času.
Pokud porovnáte čas strávený spuštěním trace během operace update subnetwork s běžným trace subnetwork, obvykle zjistíte, že trace během update subnetwork trvá déle. Je to proto, že update subnetwork provádí další práci při načítání geometrií k agregaci, výpočtu souhrnných funkcí a v některých případech hledání prvků ve více subnetworks.
Prostředí a parametry Subnetwork
Při kontrole konfigurační sekce záznamu byste měli věnovat zvláštní pozornost následujícím konfiguracím:
- Název verze
- Režim úprav
- Název vrstvy (Tier Name)
Název verze a režim úprav jsou důležité, protože chování a doba potřebná k aktualizaci subnetwork se mohou lišit podle použitého režimu úprav a zda proběhlo v defaultní nebo pojmenované verzi. Více o těchto aspektech se dozvíte v Understanding Subnetworks: Edit mode. Stručně řečeno: když je režim úprav nastaven na ‚with events‘ vznikají dodatečné náklady na výkon kvůli pravidlům atributů; když je režim ‚without events‘ vypnutý v pojmenované verzi, nemusíte aktualizovat všechny prvky v subnetwoku.
Je také důležité zvážit název vrstvy (tier name) při pohledu na výkon, protože konfigurace trace vrstvy ovládá chování update subnetwork ohledně vytváření nebo aktualizace linky subnetwoku, síťových diagramů atd.
Kroky a časy
Při pohledu na kroky a časy vás primárně zajímají následující sekce:
- Trace
- Různé kroky aktualizace (Connectivity, Content atd.)
- Správa linky subnetwoku
- Správa síťových diagramů
- Celkem
Podíváte se na Trace abyste viděli, kolik času trace zabralo a hlavně kolik prvků bylo identifikováno jako součást subnetwoku.
Dále se podíváte na čas strávený aktualizací různých atributů v databázi sledujících uložené informace o subnetwoku (název subnetwoku, zda je připojen atd.).
Čas strávený správou linky subnetwoku a síťových diagramů bývá obvykle relativně malý. Pokud však zabírá významný časový úsek, možná budete muset přezkoumat konfigurace těchto položek.
Řádek Celkem vám říká celkový čas potřebný k aktualizaci subnetwoku.
Statistiky síťového indexu
Úvahy při kontrole statistik síťového indexu pro update subnetwork jsou stejné jako u Trace Logu.
Záznam exportu (Export Log)
Při hodnocení výkonu export subnetwork zvažujete tři věci:
- Jaké typy výsledků, atributy atd. byly exportovány?
- Jak dlouho trvalo získat všechny informace požadované k exportu podle trace?
- Jak dlouho trvalo vygenerovat soubor?
K zodpovězení těchto otázek se budete primárně dívat do Export Logu. Pro podrobnější rozbor času stráveného během této operace je k dispozici TraceLog, který je generován pro trasování spuštěné jako součást exportu subnetwork.
V Export Logu jsou pět různých sekcí:
- Prostředí
- Parametry subnetwork
- Parametry exportu
- Kroky a jejich časy
- Statistiky síťového indexu
Při hodnocení celkového výkonu exportu subnetwork chcete porovnat dobu trvání exportu subnetwork s počtem exportovaných prvků. Na rozdíl od TraceLog a UpdateSubnetworkLog však neobsahuje počet prvků vrácených trasováním.
Počet prvků lze však získat z TraceLogu.
Pokud zjistíte, že subnetwork při exportní operaci nefunguje dobře, budete chtít zjistit, kde je čas v exportním logu stráven. Pokud většina času připadá na trasování, měli byste se podívat do trace logu. Při tom je často užitečné porovnat čas strávený trasováním během exportu s časem běžného trasování subnetwork (které nezahrnuje žádné typy výsledků ani funkce).
Tento přístup vám umožní zjistit, kolik času je stráveno během trasování v exportním subnetwork při získávání jednotlivých typů výsledků (konektivita, prvkové elementy atd.) a kolik času zabere samotné trasování. Trasování během exportu vždy trvá déle než běžné trasování, protože musí číst další informace z databáze. Podrobný pohled do trace logu během exportu vám ukáže, kolik času zabere získání každého typu výsledku.
Proto je důležité exportovat pouze atributy a další informace, které jsou nezbytné, protože náklady na export zbytečných informací mohou být vysoké.
Prostředí a parametry
Export subnetwork má mnoho možností, které ovlivňují, co můžete exportovat. Čím více informací zahrnete do exportu, tím déle bude trvat trasování potřebné k získání všech informací. Čím více informací zahrnete do exportu, tím větší budou soubory a déle potrvá jejich vytvoření a stažení.
Můžete vidět, jaké informace uživatel specifikoval pro zahrnutí do svého exportu v sekci parametrů exportu v reportu. To vám umožní vidět, jaké typy výsledků byly zahrnuty spolu s počtem síťových atributů, polí výsledků (pro prvky) a polí souvisejících záznamů (pro související záznamy), které byly vybrány.
Zahrnutí mnoha atributů z prvků a souvisejících záznamů vyžaduje další dotazy do databáze, což může prodloužit čas trasování pro získání těchto informací. Navíc výběr mnoha atributů může výrazně zvětšit velikost souboru. Zahrnutí všech síťových atributů pro subnetwork může zdvojnásobit velikost souboru i dobu potřebnou k exportu subnetwork. Zahrnutí atributů z mnoha různých tabulek bude mít ještě větší negativní dopad na výkon.
Kroky a časy
V logu exportního subnetwork je méně kroků k analýze. Ve většině případů bude největší náklad představovat trasování během exportního subnetwork. Pokud však vidíte velké množství času stráveného na krocích Process/Write JSON, znamená to, že soubor je velký a trvá dlouho jeho serializace, stažení a uložení.
Statistiky síťového indexu
Úvahy při přezkoumávání statistik síťového indexu pro exportní subnetwork jsou stejné jako u Trace Logu.
Build Log
Formát build logu se liší od ostatních diagnostických logů utility network, protože je navržen jako inkrementální log generovaný během potenciálně dlouhých relací. Každý řádek v build logu uvádí dobu dokončení kroku, celkový čas uplynulý do tohoto bodu a množství paměti použité v daném okamžiku.
Stejný formát log souboru se používá pro všechny tři build operace:
- Enable Network Topology
- Disable Network Topology
- Validate Network Topology
Proto si můžete všimnout, že číslování kroků v některých logech může přeskočit určité kroky. Je to proto, že ne všechny kroky platí pro všechny operace.
Při přezkoumávání logů se zaměřte na následující sekce
- Prostředí
Kroky a jejich časy
- Nastavení build network
- Post build processing
- Statistiky síťového indexu
Při hodnocení výkonu zvažte typ probíhajícího buildu, počet zpracovávaných síťových atributů, dostupnou paměť/diskový prostor, zda byla provedena analýza k identifikaci subnetworks ovlivněných validací (post-build processing) a počet zpracovávaných prvků. Většina těchto informací je dostupná v sekcích prostředí a nastavení build network v logu.
U Enable Network Topology a Disable Network Topology vás primárně zajímá propustnost, využití paměti a využití disku. Čím více můžete spoléhat na paměť při budování topologie sítě, tím rychlejší bude proces; u velkých datových sad to však není reálné. V takových případech začne build zapisovat informace na disk; pak musíte zajistit rychlý disk (ideálně SSD) a dostatek místa pro dočasné soubory.
U Validate Network Topology vás primárně zajímá celkový čas potřebný k sestavení sítě, protože uživatel obvykle volá Validate Network Topology a chcete minimalizovat dobu čekání. Pokud zaznamenáte velké množství času stráveného post build processingem, měli byste se seznámit s článkem o pochopení stavu subnetworks. Toto chování je řízeno definicí subnetwork pro každou úroveň v síti a lze jej upravit i po nasazení utility network. Utility networks nakonfigurované tak, aby udržovaly stavové pole svých subnetworks, musí provádět post build processing během Validate Network Topology k nalezení subnetworks ovlivněných validací, aby mohly být označeny jako neaktuální.
Prostředí a nastavení build network
Rozsah validace je uveden v sekci prostředí build logu; rozsah má význam pouze při hodnocení Validate Network Topology. Enable Network Topology a Disable Network Topology vždy běží na celém rozsahu sítě.
Kroky build network spolu s názvem log souboru ukazují typ provedeného buildu. Můžete také vidět počet síťových atributů, dostupnou paměť a diskový prostor při startu procesu. Pokud množství paměti použité během buildu překročí dostupnou paměť, proces začne zapisovat na disk a zpomalí se.
Kroky a jejich časy
Během procesu build network je mnoho kroků; nejsou zde všechny popsány, ale při přezkoumávání logů mějte na paměti následující body:
- Kolik informací bylo během tohoto kroku zpracováno?
- Kolik informací bylo během tohoto kroku vytvořeno?
- Kolik času/paměti tento krok spotřeboval?
Každý krok obvykle uvádí celkový čas potřebný k dokončení kroku v poslední zprávě daného kroku.
Celkový čas celé operace najdete na posledním řádku log souboru.
Pro určení množství použité paměti musíte porovnat celkovou paměť uvedenou v první zprávě kroku s celkovou pamětí uvedenou v poslední zprávě kroku.
Statistiky síťového indexu
Protože proces build network naplňuje síťový index, tato sekce může být zajímavá pro pochopení toho, kolik informací systémové tabulky přečetly, zapsaly nebo vytvořily během procesu. Nicméně po nasazení utility network nemáte mnoho možností tyto hodnoty ovlivnit.
Pokud jste na začátku projektu, můžete vidět dopady počtu síťových atributů a využít příležitosti zajistit si požadované síťové atributy ve vašem modelu. Pokud nepotřebujete síťové atributy pro žádné workflowy a jste stále na začátku projektu a můžete je odstranit ze svého modelu, zvažte to. Síťový atribut lze vždy přidat do sítě později; po nasazení jej však nelze odstranit.
Pokud uvažujete o tom, zda pokračovat ve modelování related records jako related records nebo je modelovat jako nespatial objekty s konektivitou a/nebo containmentem, můžete vidět čas potřebný k sestavení sítě zahrnující tyto dodatečné nespatial objekty do sítě.
Závěr
Nyní byste měli být obeznámeni s interpretací logů pro čtyři hlavní operace utility network. Můžete začít provádět testy výkonu a detailně interpretovat výsledky. Při navrhování architektury a důležitých rozhodnutích o modelování dat můžete měřit dopad těchto rozhodnutí na výkon.
Pro systematičtější přístup ke sběru a měření výkonových údajů možná budete chtít použít nástroj jako Extract Log Files, který kombinuje logy v databázi. Grafika v tomto článku byla vytvořena pomocí přístupu, kdy byly výkonové údaje extrahovány z každého log souboru pomocí regulárního výrazu a použity k vytvoření vizualizací.
Tyto log soubory jsou důležité, protože poskytují přesné měření času stráveného serverem při konkrétních operacích. Jsou velmi cenné pro hodnocení jediné operace; neposkytují však úplný obraz. Analýza výkonu musí být prováděna komplexně tak, aby brala v úvahu nejen výkon utility network, ale i dopad celé architektury na výkon i chování systému pod zatížením.
Pro příklady komplexnějšího přístupu k testování a návrhu navštivte ArcGIS Architecture Center.
Pro příklady toho, jak modelování related records může ovlivnit výkon, odkazujeme na Modeling related data in a utility network.}}
Pro příklady toho, jak může konfigurace režimu úprav vaší podsítě ovlivnit výkon aktualizace podsítě, si přečtěte Understanding Subnetwork Edit Mode článek.
Pro příklady toho, jak může konfigurace správy stavu vaší podsítě ovlivnit výkon ověřování topologie sítě, si přečtěte Understanding Subnetwork Status článek.
