Velikost požadavku<\/LI><\/UL><\/UL>
V tomto článku předkládám výsledky těchto testů spolu s několika návrhy na maximalizaci výkonu. Můj testovací stroj je stolní počítač s Windows 7 SP1 a ArcGIS 10.2.1 s 18GB RAM a čtyřjádrovým procesorem Intel Xeon W3550 běžícím na 3 GHz. Testovací data byla uložena na jinak prázdném 2 TB SATA pevném disku, který jsem před testováním defragmentoval a konsolidoval. Testy byly nakonfigurovány tak, aby určily průměrné doby odezvy služeb za různých podmínek. Pod pojmem „doba odezvy“ rozumím čas, který služba potřebuje k načtení zdrojových dat, jejich zpracování a přenosu výstupního obrazu. Čas přenosu byl minimalizován tím, že testovací aplikace běžela přímo na serverovém stroji.<\/P>
<\/P>
Tato informace je napsána s ohledem na uživatele GIS se středně pokročilými až pokročilými znalostmi. Předpokládám, že čtenář má obecné znalosti o službách pro obrázky, rastrových datech a analýze, rastrových funkcích, geoprocessingu, mozaikových datech, mapových projekcích a mezipaměti mapových služeb.<\/P>
<\/P>
Měřítko mapy a rozlišení zdrojových dat<\/STRONG><\/P><\/P>Pixely zpracovávané pro analýzu dynamickými službami pro obrázky obvykle nejsou totožné s pixely uloženými ve zdrojových datech. Místo toho jsou pixely zdrojových dat nejprve resamplovány za běhu na novou velikost založenou na aktuálním měřítku mapy. Tento vzorec ukazuje vztah mezi měřítkem mapy a velikostí resamplovaných pixelů, pokud jsou jednotky mapy v metrech:<\/P><\/P>Velikost resamplovaného pixelu = měřítko mapy * 0.0254\/96<\/A><\/P><\/P>
Velikost resamplovaného pixelu je analogická parametru „Analysis Cell Size“ v Geoprocessing Frameworku a někdy se označuje jako „velikost pixelu požadavku“. Při oddalování mapy na menší měřítka velikost resamplovaného pixelu roste, až nakonec služba resampluje z pixelů v pyramidách. Resampling z pyramid pomáhá udržet výkon služby relativně konzistentní v rozsahu měřítek mapy.<\/P>
<\/P>
Graf 1. Výkon služby pro obrázky provádějící binární překryvnou analýzu v rozsahu měřítek mapy.<\/P><\/DIV>Výkon se stále liší podle měřítka mapy a typicky vypadá podobně jako graf 1. Tyto výsledky jsem vytvořil pomocí aplikace nakonfigurované tak, aby simulovala jednoho uživatele posouvajícího mapu 100krát za sebou při specifických měřítkách mapy. Graf ukazuje průměrný čas, který služba potřebovala k zpracování a přenosu výstupních obrazů pro různá měřítka mapy. Tato konkrétní služba byla nakonfigurována s šablonou rastrové funkce k provedení binární překryvné analýzy nad jedenácti překrývajícími se rastry v mozaikovém datasetu. Velikosti pixelů zdrojových datasetů se pohybovaly od 91,67 do 100 metrů. Šablona rastrové funkce byla nastavena tak, aby vracela binární výsledek, kde každý výstupní pixel je klasifikován jako buď „vhodný“, nebo „nevhodný“ podle parametrů analýzy.<\/P><\/P>Podívejte se na tři body podél vodorovné osy, kde doba odezvy náhle klesá. Na těchto měřítkách mapy je velikost resamplovaného pixelu stejná jako velikosti pixelů pyramid ve zdrojových datech. Doba zpracování resamplingu je nejnižší právě na těchto měřítkách, protože existuje téměř shoda 1:1 mezi pixely zdrojových dat a resamplovanými pixely. Klientské aplikace používající tuto konkrétní službu zaznamenají dramaticky rychlejší doby odezvy, pokud budou nějak omezeny pouze na tato měřítka. Jedním ze způsobů je použití dlaždicové základní vrstvy (tiled basemap). Webové mapové aplikace používající dlaždicové základní vrstvy jsou obecně omezeny právě na tato měřítka mapy. Nejčastěji používaným dlaždicovým schématem je dlaždicové schéma ArcGIS Online/Bing Maps/Google Maps (dále jen „AGOL tiling scheme“). Červeně tečkované svislé čáry v grafu označují měřítka mapy pro úrovně 7 – 12 tohoto dlaždicového schématu. Bohužel tato měřítka nejsou příliš blízko těm, kde tato služba dosahuje nejlepšího výkonu. Existují dvě možnosti sladění pixelů zdrojových dat s měřítky dlaždicového schématu:<\/P><\/P>Vytvořit vlastní základní mapu s vlastním dlaždicovým schématem odpovídajícím velikostem pixelů dat.<\/LI>Vzorkovat nebo resamplovat data na velikost pixelu odpovídající dlaždicovému schématu základní mapy.
<\/LI><\/OL><\/OL>Graf 2. Výkon služby binární překryvné analýzy s různými velikostmi pixelů zdrojových dat<\/P><\/DIV>Vodorovná osa v grafu 2 představuje „velikost pixelu požadavku“ místo měřítka mapy jako v grafu 1. Oranžový graf ukazuje doby odezvy jiné služby nakonfigurované stejně jako první modrá služba, kromě toho že používá zdrojové datasety up-samplované na pixely o velikosti 38 metrů pomocí nástroje Resample<\/A>. Up-sampling na 38 metrů sladila nejrychlejší doby odezvy služby s měřítky dlaždicového schématu AGOL, což vedlo k výraznému snížení doby zpracování na těchto měřítkách z přibližně 1,5 sekundy na asi 0,5 sekundy. Navíc si všimněte, že výkon se zlepšil téměř ve všech měřítcích kromě toho největšího. To je pravděpodobně způsobeno tím, že všechna zdrojová data mají stejné rozlišení (38 m) místo tří (91,67 m, 92,5 m, 100 m), a/nebo proto, že pixely zdrojových dat jsou také zarovnány mezi datasetem (což bylo dosaženo definováním společného výchozího bodu pro každý resamplovaný raster pomocí nastavení prostředí „Snap Raster“).<\/P><\/P>
Přiznávám, že použití nástroje Resample k přípravě dat pro analýzu není ideální, protože vede ke druhotným datům méně přesným než originál. To může být naprosto přijatelné pro aplikace určené k poskytnutí počáteční průzkumné analýzy; nicméně je nejlepší generovat nová primární data požadované velikosti pixelu kdykoli je to možné. Například pokud máte přístup k polygonům tříd půdy (land-class polygons), můžete je použít k vytvoření nového primárního rastrového datasetu požadované velikosti pixelu pomocí nástroje
Polygon to Raster<\/A>, místo abyste resamplovali existující rastrový dataset tříd půdy.<\/P><\/P>
Abych zjistil o kolik se výkon zlepšil u pixelů o velikosti 38 metrů, vypočetl jsem procentuální změnu průměrných dob odezvy pro každé měřítko a zprůměroval hodnoty přes více měřítek.<\/P>
<\/P>
Up-sampling zdrojových dat na pixely o velikosti 38 metrů snížil doby odezvy o –> …<|vq_lbr_audio_128829|>... Desetinné stupně. Tři sloupce napravo poskytují navrhované hodnoty pro vzorkování rastrových dat. Tyto návrhy nejsou pevně dané. Není nutné vzorkovat svá data přesně na tyto doporučené velikosti. Klíčem je vybrat velikost, která je o něco menší než jedna z velikostí měřítek cílového dlaždicového schématu.<\/P>
<\/P>
Měřítka map a velikosti pixelů pro dlaždicové schéma ArcGIS Online\/Bing Maps\/Google Maps<\/EM><\/P>
<\/A><\/P><\/P>
Mimochodem, sladění velikostí pixelů vašich dat s dlaždicovým schématem podkladové mapy je také užitečné pro pracovní postupy, které zahrnují statické snímky překryté dlaždicovou podkladovou mapou. <\/SPAN>Pro tyto případy můžete vytvořit přehledy mozaikových datasetů pro zobrazení v menších měřítcích místo rastrových pyramid. <\/SPAN>Jednou z výhod přehledů mozaikových datasetů je, že můžete definovat základní velikost pixelu přehledů i měřítkový faktor tak, aby odpovídaly vašemu cílovému dlaždicovému schématu. <\/SPAN>Tímto způsobem nemusíte pře-vzorkovávat zdrojová data na novou základní velikost pixelu, abyste vyhověli konkrétnímu dlaždicovému schématu.<\/P>
Metoda pře-vzorkování<\/STRONG><\/P><\/P><\/P>
Metoda pře-vzorkování<\/A> <\/SPAN>určená pro požadavek obrazové služby má také vliv na výkon. <\/SPAN>Volba metody by měla být primárně založena na typu dat použitých v analýze. <\/SPAN>Graf 3 ukazuje výkon služby binární překryvné analýzy (s daty o rozlišení 38 metrů) s různými metodami pře-vzorkování.<\/P>
<\/A>Graf 3. Časy odezvy služby binární překryvné analýzy s různými metodami pře-vzorkování<\/P><\/DIV>
<\/P>
<\/P>
<\/P>
Bilineární pře-vzorkování je výchozí metoda. <\/SPAN>Zde je porovnání průměrných časů odezvy ostatních metod vůči bilineární metodě za pět testovaných měřítek mapy:<\/P>
<\/A><\/P>
Rastrový formát<\/STRONG><\/P><\/P>Formát ukládání dat může mít obrovský vliv na výkon. Například průměrný čas odezvy služby binární překryvné analýzy přes všechna měřítka map byl o 36 % nižší, když byla data uložena ve formátu GeoTIFF oproti rastrovým datům spravovaným v souborové geodatabázi. Sekce
Datové zdroje a formáty<\/A> v příručce Image Management doporučuje ponechat data v jejich původním formátu, pokud nejsou v některém z pomalejších formátů, jako je ASCII. GeoTIFF s interními dlaždicemi je doporučenou volbou pro přeformátování, protože poskytuje rychlý přístup k pixelům pro obdélníkové oblasti pokrývající pouze podmnožinu celého souboru.Typ pixelu a komprese<\/STRONG><\/P><\/P>Typ pixelu určuje přesnost hodnot uložených v datech a může mít velký vliv na výkon. Obecně jsou celočíselné typy rychlejší než typy s plovoucí desetinnou čárkou a typy s nižší přesností jsou rychlejší než typy s vyšší přesností. Komprese snímků může potenciálně zvýšit nebo snížit výkon v závislosti na situaci. Pro více informací o vlivu komprese na velikost souboru viz sekci Datové zdroje a formáty v příručce Image Management. Abych posoudil dopad typu pixelu a komprese na výkon dat uložených na lokálním pevném disku, testoval jsem skupinu obrazových služeb nakonfigurovaných k provedení extrémně náročné překryvné analýzy na 15 rastrových sadách dat. Služby byly nakonfigurovány identicky kromě typu pixelu a komprese analyzovaných dat. Testy byly provedeny při měřítku mapy odpovídajícím velikosti pixelu dat.<\/P>
<\/A>Grafy 5 & 6. Průměrný čas odezvy a velikost úložiště vs. typ komprese pro obrazovou službu provádějící složitou překryvnou analýzu<\/P><\/DIV>
<\\/P><\\/P>P Následující tabulka ukazuje procentuální změnu časů odezvy u přeformátovaných datasetů oproti původnímu datasetu s dvojitou přesností plovoucí desetinné čárky.
Projekce za běhu
Projekce za běhu je velmi důležitou funkcí platformy ArcGIS. Ušetřila uživatelům GIS jako jsem já nespočet hodin práce tím, že odstranila nutnost zajistit, aby každý dataset v mapě byl uložen ve stejném souřadnicovém systému. Nicméně v některých případech může být tato flexibilita a pohodlí nákladná, když je vyžadován ultra rychlý výkon. Následující graf ukazuje jeden z těchto případů.
Graf 8. Výkon dynamické obrazové služby nakonfigurované k provedení vážené překryvné analýzy.
Graf 8 ukazuje výkon služby, která provádí váženou překryvnou analýzu na šesti datasetech v projekci Albers. Horní graf ukazuje výkon, když je výstup služby nastaven na Web Mercator (Auxiliary Sphere). Dolní graf ukazuje výkon, když je výstup služby ve stejném souřadnicovém systému jako data. Výkon bez reprojekce do Web Mercator se zlepšil průměrně o 45 % napříč všemi měřítky map. Toto je poměrně extrémní příklad. Náklady na výkon reprojekce souvisejí s matematickou složitostí vstupních a výstupních projekcí. Projekce se stejnou plochou jako Albers jsou matematicky složité ve srovnání s válcovými projekcemi jako Mercator. Neprovedl jsem testy k potvrzení tohoto tvrzení, ale očekávám, že náklady na výkon reprojekce mezi dvěma válcovými projekcemi jako UTM a Web Mercator by byly méně nákladné než v tomto příkladu a že jednoduchá projekce z geografických souřadnic do Web Mercator by byla ještě méně nákladná.
Aby se zabránilo projekci za běhu, musíte zajistit, aby všechna vaše data byla ve stejném souřadnicovém systému, včetně podkladové mapy. Většina podkladových služeb aktuálně dostupných od Esri na ArcGIS Online je ve Web Mercator (auxiliary sphere). Takže pokud chcete použít jednu z těchto podkladových map, museli byste převést svá data do stejného souřadnicového systému. To může být přijatelné řešení pro některé situace, ale mějte na paměti, že to vede k druhé generaci dat s menší polohovou přesností než původní zdrojová data. Alternativně můžete vytvořit vlastní podkladovou mapu ve stejném souřadnicovém systému jako vaše data a buď ji publikovat na server ArcGIS Server nebo ji nahrát do ArcGIS Online jako hostovanou mapovou službu. Pokud zvolíte tento přístup, doporučuji kešovat podkladovou mapu pomocí vlastního dlaždicového schématu s úrovněmi měřítek odpovídajícími velikostem pixelů vašich dat.
Velikost požadavku
Velikost požadavku je přímo spojena s velikostí okna mapy v aplikaci a je specifikována v REST API jako počet řádků a sloupců pixelů ve výstupním obrázku. Abych změřil její dopad na výkon, provedl jsem sérii testů při různých velikostech požadavků na službu weighted overlay analysis, kterou jsem použil pro testy reprojekce za běhu. Měřil jsem průměrné doby odezvy pro velikosti požadavků od 400x400 do 2200x2200, s nárůstem po 100 pixelech (např. 500x500, 600x600 atd.). Všechny testy byly provedeny v měřítku mapy 1:113386, což odpovídá velikosti pixelu 30 metrů u zdrojových rastrových datových sad.<\/P>
<\/A>Graf 9. Průměrná odezva v MP\/s pro různé velikosti požadavků na službu weighted overlay.<\/P><\/DIV>
<\/A>Graf 10. Průměrná doba odezvy při různých velikostech požadavků na službu weighted overlay.<\/P><\/DIV>
<\/P>
<\/P>
Graf 9 ukazuje, že propustnost této služby se ustálí při velikosti požadavku přibližně na 1000x1000 pixelech na asi 1,5 – 1,6 MP/s. Graf 10 ukazuje, že velikost požadavku má lineární dopad na výkon. Tato služba je schopna poskytovat odezvy pod jednu sekundu pro požadavky až do přibližně 1 440 000 pixelů, nebo velikosti požadavku 1200x1200.<\/P>
<\/P>
Shrnutí<\/STRONG><\/P><\/P>Rastrová analýza může zahrnovat mnoho fází zpracování a analýzy dat. Komplexní řetězce zpracování za běhu mohou klást velké zatížení na server a přispívat k pomalému výkonu. V některých případech lze dosáhnout obrovských zlepšení výkonu předzpracováním dat do efektivnějšího formátu pro resamplování a zpracování za běhu.<\/P><\/P>Pro aplikace používající dlaždicové vrstvy podkladových map jsou největší zlepšení výkonu pravděpodobně dosažena sladěním velikostí pixelů dat s měřítky dlaždicového schématu podkladové mapy. Sekce „Map Scales and Source Data Resolution“ popisuje teorii tohoto přístupu a poskytuje tabulku s doporučenými velikostmi pixelů pro aplikace používající podkladové mapy s dlaždicovým schématem ArcGIS Online/Bing Maps/Google Maps. Alternativně mohou vývojáři vytvářet podkladové mapy s vlastními dlaždicovými schématy, aby sladili existující velikosti pixelů analyzovaných dat.<\/P><\/P>Dalším způsobem, jak výrazně snížit zatížení serveru v některých případech, je vyhnout se projekci dat analýzy za běhu. Toho se dosahuje zajištěním, že podkladová mapa a analyzovaná data jsou ve stejném souřadnicovém systému. Dopad projekce za běhu na výkon závisí na vstupních a výstupních souřadnicových systémech a je diskutován v sekci nazvané „On-the-fly Projection“.<\/P><\/P>Formát souboru, typ pixelu a typ komprese analyzovaných dat mohou také mít obrovský dopad na výkon. GeoTIFF s interními dlaždicemi je doporučován pro situace, kdy je nutné data přeformátovat ze pomalejšího formátu. Pixely nižší přesnosti poskytují lepší výkon než pixely vyšší přesnosti. Komprese pixelů může potenciálně zvýšit nebo snížit výkon v závislosti na tom, jak jsou data uložena a přistupováno k nim serverem. Tato témata jsou diskutována v sekcích nazvaných „Raster Format“ a „Pixel Type and Compression“.<\/P><\/P>Klientské aplikace také mohou hrát roli ve výkonu dynamické obrazové služby. Doby odezvy služby jsou nejnižší, když aplikace specifikují nearest neighbor resampling, následovaný bilinear resampling. A existuje přímý vztah mezi výkonem služby a velikostí okna mapy v aplikaci. Tato témata jsou diskutována v sekcích nazvaných „Resampling Method“ a „Request Size".<\/P><\/BODY><\/HTML>
