Ontwerpen en optimaliseren van Image Services voor high-performance analyse

DavidJohnson5

<\/HEAD>

Beeldservices zijn niet alleen bedoeld voor het leveren van afbeeldingen; ze kunnen ook dynamische pixel-niveau analyse uitvoeren op meerdere overlappende rasterdatasets met behulp van gekoppelde rasterfuncties.  Beeldservices leveren razendsnelle prestaties met vooraf verwerkte bronafbeeldingen, vooral wanneer deze worden geleverd vanuit een tegelcache.  Dynamische beeldservices daarentegen reageren mogelijk niet zo snel vanwege de extra verwerkingsvereisten die ze aan de server stellen.  Hoge prestaties zijn belangrijk voor dynamische beeldservices omdat de gegevens automatisch opnieuw worden verwerkt elke keer dat de gebruiker de kaart verschuift of inzoomt.  Dynamische beeldservices produceren doorgaans reactiesnelheden onder de seconde voor eenvoudige analysetypen.  Maar complexere analyses kunnen veel langer duren, afhankelijk van de complexiteit van de verwerkingsketen en het aantal betrokken invoerdatasets.  Hoe kunnen we betere prestaties krijgen in die situaties?  Om die vraag te beantwoorden heb ik een reeks tests uitgevoerd om te zien hoe de volgende factoren de prestaties van dynamische beeldservices beïnvloeden:<\/P>

<\/P>

• Kaartschaal en resolutie van brongegevens<\/LI><\/UL><\/UL>
  • Herbemiddelingsmethode<\/LI><\/UL><\/UL>
    • Formaat en compressie van brongegevens<\/LI><\/UL><\/UL>
      • Projecteren on-the-fly<\/LI>
      • Aanvraaggrootte<\/LI><\/UL><\/UL>

        
        In dit artikel presenteer ik de resultaten van die tests samen met enkele suggesties om de prestaties te maximaliseren.  Mijn testmachine is een desktopcomputer met Windows 7 SP1 en ArcGIS 10.2.1, uitgerust met 18GB RAM en een quad-core Intel Xeon W3550-processor die draait op 3 GHZ.  De testgegevens waren opgeslagen op een verder lege 2 TB SATA harde schijf die ik voorafgaand aan het testen had gedefragmenteerd en geconsolideerd.   De tests waren geconfigureerd om de gemiddelde reactietijden van services onder verschillende omstandigheden te bepalen.  Met "reactietijd" bedoel ik de tijd die een service nodig heeft om de brongegevens op te halen, te verwerken en een uitvoerafbeelding te verzenden.  De transmissietijd werd geminimaliseerd door de testapplicatie direct op de servermachine uit te voeren.<\/P>

        <\/P>

        Deze informatie is geschreven met de intermediate tot gevorderde GIS-gebruiker in gedachten.  Ik ga ervan uit dat de lezer een algemeen begrip heeft van beeldservices, rastergegevens en analyse, rasterfuncties, geoprocessing, mozaïekdatasets, kaartprojecties en caching van kaartservices.<\/P>

        <\/P>

        Kaartschaal en resolutie van brongegevens<\/STRONG><\/P><\/P>De pixels die worden verwerkt voor analyse door dynamische beeldservices zijn over het algemeen niet identiek aan de pixels die zijn opgeslagen in de brondatasets.  In plaats daarvan worden de brongegevenspixels eerst on-the-fly herbemiddeld naar een nieuwe grootte op basis van de huidige schaal van de kaart.  Deze formule toont de relatie tussen kaartschaal en herbemiddelingsgrootte wanneer de kaartunits van de gegevens meters zijn:<\/P><\/P>Herbemedelde pixelgrootte = kaartschaal * 0.0254\/96<\/A><\/P>

        <\/P>

        De herbemedelde pixelgrootte is analoog aan de parameter "Analysis Cell Size" in het Geoprocessing Framework en wordt soms aangeduid als de "pixelgrootte van het verzoek".  Naarmate je uitzoomt naar kleinere kaartschaal, neemt de herbemedelde pixelgrootte toe totdat uiteindelijk de service herbemiddelt vanaf de pixels in de piramides.  Herbemiddeling vanaf piramides helpt om de prestaties van de service relatief consistent te houden over een reeks kaartschaalniveaus.<\/P>

        <\/P>

        Grafiek 1. Prestaties van een beeldservice die een binaire overlay-analyse uitvoert over een reeks kaartschaalniveaus.<\/P><\/DIV>De prestaties variëren nog steeds afhankelijk van kaartschaal en lijken meestal op grafiek 1.    Ik genereerde deze resultaten met een applicatie die was geconfigureerd om één gebruiker te simuleren die honderd keer achter elkaar over specifieke kaartschaalniveaus pande.  De grafiek toont de gemiddelde tijd die de service nodig had om uitvoerafbeeldingen te verwerken en te verzenden voor verschillende kaartschaalniveaus.  Deze specifieke service was geconfigureerd met een rasterfunctie-sjabloon om een binaire overlay-analyse uit te voeren op elf overlappende rasters in een mozaïekdataset.  De pixelgroottes van de brondatasets varieerden van 91,67 tot 100 meter.  De rasterfunctie-sjabloon was geconfigureerd om een binair resultaat terug te geven, waarbij elke uitvoerpixel werd geclassificeerd als ofwel "geschikt" of "ongeschikt" op basis van de analyseparameters.<\/P><\/P>Kijk naar de drie punten langs de horizontale as waar de reactietijd abrupt daalt.  Bij die kaartschaalniveaus is de herbemedelde pixelgrootte gelijk aan de pixelgroottes van de piramides in de brongegevens.  De verwerkingstijd voor herbemiddeling is het laagst bij die schalen omdat er bijna een 1:1-overeenkomst is tussen brongegevenspixels en herbemedelde pixels.  Clientapplicaties die deze specifieke service gebruiken zullen dramatisch snellere reactietijden zien als ze op enige wijze beperkt zijn tot alleen die schalen.  Een manier om dit te doen is door gebruik te maken van een tegelbasemaplaag.  Webmapping-applicaties die tegelbasemaps gebruiken zijn doorgaans beperkt tot alleen die kaartschaalniveaus.  Het meest gebruikte tegelingsschema is het ArcGIS Online\Bing Maps\Google Maps-tegelingsschema (hierna kortweg aangeduid als het "AGOL-tegelingsschema").  De rood-gestippelde verticale lijnen in de grafiek geven de kaartschaalniveaus aan voor niveaus 7 t/m 12 van dit tegelingsschema.  Helaas liggen deze schalen niet erg dicht bij de schalen waarop deze service het beste presteert.  Er zijn twee opties om brongegevenspixels en tegelingsschema-schalen op elkaar af te stemmen:<\/P><\/P>Bouw een aangepaste basemap met een aangepast tegelingsschema dat overeenkomt met de pixelgroottes van de gegevens.<\/LI>Neem monsters of herbemiddel de gegevens naar een pixelgrootte die overeenkomt met het tegelingsschema van de basemap.<\/LI><\/OL><\/OL>Grafiek 2. Prestaties van binary overlay-analyse service met verschillende pixelgroottes van brongegevens<\/P><\/DIV>De horizontale as in grafiek 2 vertegenwoordigt niet kaartschaal zoals in grafiek 1, maar "pixelgrootte van het verzoek".  De oranje grafiek toont reactietijden van een andere service die identiek was geconfigureerd aan degene in blauw, behalve dat deze gebruikmaakt van brondatasets die waren opgehoogd naar pixels van 38 meter met behulp van het Resample<\/_A> geoprocessing-gereedschap.  Het opschalen naar 38 meter bracht de snelste reactietijden van deze service in lijn met het AGOL-tegelingsschema, wat resulteerde in een significante daling in verwerkingstijd bij die schalen, namelijk ongeveer van 1,5 seconden naar ongeveer 0,5 seconden.  Bovendien valt op dat prestaties verbeterd zijn bij bijna alle schalen behalve bij de allerhoogste.  Dit komt waarschijnlijk doordat alle brongegevens nu dezelfde resolutie hebben (38m) in plaats van drie (91,67m, 92,5m, 100m), en/of omdat brondatapixels ook tussen datasets zijn uitgelijnd (bereikt door het definiëren van een gemeenschappelijk oorsprongspunt voor elk herbemedeld raster via instelling "Snap Raster").<\/P>

        <\/_p>

        P>Eerlijk gezegd is het gebruik van het Resample-gereedschap om gegevens voor analyse voor te bereiden niet ideaal omdat dit resulteert in data tweede generatie die minder nauwkeurig is dan het origineel.  Dit kan perfect acceptabel zijn voor toepassingen bedoeld om een eerste verkennende analyse te bieden; echter, het is beter om nieuwe data eerste generatie te genereren op gewenste pixelgrootte waar mogelijk.  Bijvoorbeeld als u toegang heeft tot landclassificatiepolygonen kunt u deze gebruiken om nieuwe eerste generatie rasterdataset te genereren op gewenste pixelgrootte met behulp van Polygon to Raster<\/_A>, in plaats van bestaande landclassificatie-rasterdataset opnieuw bemonsteren.<\/_p>
        P>Om vast te stellen hoeveel beter prestaties werden met pixels van 38 meter berekende ik procentuele verandering in gemiddelde reactietijden per schaalniveau en nam vervolgens gemiddelden over meerdere schaalniveaus.<\/_p>P> <\/_p>P>Het opschalen naar pixels van 38 meter verminderde reactietijden met                               &nbps63.8% bij slechtst presterende doel-kaartschaal!& nbsp ;38 meter was niet mijn enige optie in dit voorbeeld .& nbsp ;Ik had ook kunnen kiezen voor een grootte die overeenkomt met één andere schaal uit het tegelingsschema .& nbsp ;De volgende tabel geeft alle kaartschaalniveaus weer uit het AGOL-tegelingsschema , evenals overeenkomstige pixelgroottes in meters , voeten en Decimale graden.   De drie kolommen aan de rechterkant geven voorgestelde waarden voor het bemonsteren van rastergegevens.  Deze suggesties zijn niet in steen gebeiteld.  Het is niet noodzakelijk om uw gegevens precies op deze aanbevolen groottes te bemonsteren.  Het belangrijkste is om een grootte te kiezen die iets kleiner is dan een van de groottes van de doel-tegelindeling schaalniveaus.<\/P>

        <\/P>

        Kaartschaal en pixelgroottes voor het ArcGIS Online\/Bing Maps\/Google Maps tegelindeling schema<\/EM><\/P><\/A><\/P>

        <\/P>

        Trouwens, het afstemmen van de pixelgroottes van uw gegevens met een basemap tegelindeling schema is ook nuttig voor workflows waarbij statische afbeeldingen worden overlegd op een tegelbasemap.  <\/SPAN>Voor die gevallen kunt u mozaïek dataset overzichten bouwen voor weergave op kleinere schalen in plaats van raster piramides.  <\/SPAN>Een van de geweldige dingen aan mozaïek dataset overzichten is dat u de basis pixelgrootte van overzichten kunt definiëren evenals de schaalfactor om overeen te komen met uw doel-tegelindeling schema.  <\/SPAN>Op deze manier hoeft u de brongegevens niet opnieuw te bemonsteren naar een nieuwe basis pixelgrootte om aan een bepaald tegelindeling schema te voldoen.<\/P>
        Herverzamelingsmethode<\/STRONG><\/P><\/P><\/P>De

        herverzamelingsmethode<\/A> <\/SPAN>die is opgegeven voor een afbeeldingsservice aanvraag heeft ook invloed op de prestaties.  <\/SPAN>De keuze welke te gebruiken moet voornamelijk gebaseerd zijn op het type gegevens dat wordt gebruikt in de analyse.  <\/SPAN>Tabel 3 toont de prestaties van de binaire overlay analyse service (met 38 meter gegevens) met verschillende herverzamelingsmethoden.<\/P><\/A>

        Tabel 3. Reactietijden van de binaire overlay analyse service met verschillende herverzamelingsmethoden<\/P><\/DIV>

        <\/P>

        <\/P>

        <\/P>

        Bilineaire herverzameling is de standaardmethode.  <\/SPAN>Hier is hoe de reactietijden voor de andere methoden vergeleken met bilineair gemiddeld over de vijf geteste kaartschaalniveaus:<\/P>

        <\/A><\/P>

        
        Rasterformaat<\/STRONG><\/P><\/P>Het opslagformaat van de gegevens kan een enorme impact hebben op de prestaties.  Bijvoorbeeld, de reactietijd van de binaire overlay analyse service gemiddeld over alle kaartschaalniveaus was 36% lager wanneer de gegevens werden opgeslagen in het GeoTIFF-formaat versus bestand geodatabase beheerde raster.  De

        Gegevensbronnen en formaten<\/A> sectie van de  Afbeeldingsbeheer gidsboek raadt aan om de gegevens in hun oorspronkelijke formaat te laten tenzij het in een van de trager presterende formaten zoals ASCII is.  GeoTIFF met interne tegels is de aanbevolen keuze voor herformattering omdat het snelle toegang tot pixels biedt voor rechthoekige gebieden die slechts een subset van het hele bestand beslaan.Pixeltype en compressie<\/STRONG><\/P><\/P>Het pixeltype bepaalt de precisie van de waarden die in de gegevens zijn opgeslagen en kan een enorme impact hebben op prestaties.  Over het algemeen zijn gehele getal types sneller dan drijvende-komma types, en lagere precisie types zijn sneller dan hogere precisie types.  Compressie van afbeeldingen kan mogelijk prestaties verhogen of verlagen afhankelijk van de situatie.   Voor meer informatie over het effect van compressie op bestandsgrootte verwijzen wij naar het Afbeeldingsbeheer gidsboek sectie over Gegevensbronnen en formaten.  Om de impact van pixeltype en compressie op de prestaties van gegevens opgeslagen op een lokale harde schijf te beoordelen, heb ik een groep afbeeldingsservices getest die geconfigureerd zijn om een extreem intensieve overlay analyse uit te voeren op 15 raster datasets.  De services waren identiek geconfigureerd behalve voor het pixel- en compressietype van de analysedata.  De tests werden uitgevoerd op het kaartschaalniveau dat overeenkomt met de pixelgrootte van de gegevens.<\/P><\ /A><\ P style=\ "color: #888; font-size: 12px; margin: 5px;\ ">Grafieken 5 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;. Gem. reactietijd en opslaggrootte vs. compressietype voor een afbeeldingsservice die een complexe overlay analyse uitvoert<\ /P>< P >< \ / P >< P > De volgende tabel toont het procentuele verschil in reactietijden met de geherformatteerde datasets versus het originele double-precision floating-point dataset.< A _ jive_internal = " true " href = " https : \ / \ / community . esri . com \ / servlet \ / JiveServlet \ / download \ / 58798 -189236 \ / Table_pixeltype . png " > < IMG __ jive_id = "388586 " alt = " Table_pixeltype . png " class = " jive-image " height = "100 " src = " https : \ / \ / us . v-cdn . net \ /6038851 \ / uploads \ / legacyfs \ / online \ /388586_Table_pixeltype.png " width = "469 " \/ > < \/ A > < \/ P > < P > < \/ P > < STRONG > On-the-fly Projectie < \/ STRONG > < P > < \/ P > < P > On-the-fly projectie is een zeer belangrijke functie van het ArcGIS platform.  Het heeft GIS-gebruikers zoals ik ontelbare uren werk bespaard door te voorkomen dat elke dataset in een kaart in hetzelfde coördinatensysteem moet worden opgeslagen.  Echter, in sommige gevallen kan deze flexibiliteit en gemak kostbaar zijn wanneer ultra-snelle prestaties vereist zijn. & nbsp;& nbsp ; De volgende grafiek toont zo'n geval. < \/ P > < DIV style = " width : auto ! important ; line-height : 18px ; margin-bottom : 20px ; padding : 4px ; text-align : center ; background : #f1f1f1 ; " > < A _ jive_internal = " true " href = " https : \ / \ / community . esri . com \ / servlet \ / JiveServlet \ / download \ /58798-189237\ / chart8b . png " > < IMG __ jive_id = "388587 " alt = " chart8b . png " class = " jive-image " height = "337 " src = " https : \ / \ / us . v-cdn . net \ /6038851\ / uploads\ / legacyfs\ / online\ /388587_chart8b.png " style = " margin : 5px 5px 0 ; padding :10px ; box-shadow :1px 1px 3px #999999 ; background : none repeat scroll 0 0 #F5F5F5 ; " width = "625 " \/ > < \/ A > < P style = " color : #888 ; font-size :12px ; margin :5px ; "> Grafiek 8. Prestaties van een dynamische afbeeldingsservice geconfigureerd om een gewogen overlay analyse uit te voeren. < \/ P > < \/ DIV > < P > < \/ P > < P > Grafiek 8 toont de prestaties van een service die een gewogen overlay analyse uitvoert & nbsp ; op zes datasets in een Albers projectie.  De bovenste grafiek toont de prestaties wanneer de uitvoer van de service is ingesteld op Web Mercator (Auxiliary Sphere).  De onderste grafiek toont de prestaties wanneer de uitvoer van de service hetzelfde coördinatensysteem als de gegevens is. & nbsp ; Prestaties zonder reprojection naar Web Mercator verbeterden gemiddeld met 45% over alle kaartschaalniveaus.  Dit is een vrij extreem voorbeeld.  De prestatiekosten van reprojection zijn gerelateerd aan de wiskundige complexiteit van invoer- en uitvoerprojecties.  Equal-area projecties zoals Albers zijn wiskundig complex vergeleken met cilindrische projecties zoals Mercator.  Ik heb geen tests uitgevoerd om dit te bewijzen, maar ik verwacht dat de prestatiekosten van reprojection tussen twee cilindrische projecties zoals UTM en Web Mercator minder kostbaar zouden zijn dan in dit voorbeeld, en dat een eenvoudige projectie van geografische coördinaten naar Web Mercator nog minder kostbaar zou zijn.< \/ P > < P > Om on-the-fly projectie te vermijden moet u ervoor zorgen dat al uw gegevens zich in hetzelfde coördinatensysteem bevinden, inclusief de basemap.  De meeste basemap services die momenteel beschikbaar zijn via Esri op ArcGIS Online zijn in Web Mercator (auxiliary sphere).  Dus als u een van die basemaps gaat gebruiken, moet u uw gegevens converteren naar hetzelfde coördinatensysteem.  Dit kan een acceptabele oplossing zijn voor sommige situaties, maar houd er rekening mee dat dit resulteert in data tweede generatie met minder positionele nauwkeurigheid dan de originele brongegevens.  Als alternatief kunt u uw eigen basemap maken in hetzelfde coördinatensysteem als uw gegevens, en deze publiceren naar een ArcGIS Server site of uploaden naar ArcGIS Online als een gehoste kaartservice.  Als u deze aanpak volgt, raad ik aan om de basemap te cachen met behulp van een aangepast tegelindeling schema met schaalniveaus die overeenkomen met de pixelgroottes van uw gegevens.< \/ P > < P > < \/ P > < STRONG > Aanvraaggrootte < \/ STRONG > < P > < \/ P > < P > Aanvraaggrootte is direct gerelateerd aan de grootte van het kaartvenster in de applicatie en wordt gespecificeerd in de REST API als het aantal rijen en kolommen pixels in het uitvoerbeeld.  Om het effect ervan op prestaties te meten, heb ik een reeks tests uitgevoerd bij verschillende aanvraaggroottes op de weighted overlay analysis service die ik gebruikte voor de reprojection-on-the-fly tests.  Ik heb de gemiddelde responstijden gemeten voor aanvraaggroottes variërend van 400x400 tot 2200x2200, met toenames van 100 pixels (bijv. 500x500, 600x600, enzovoort).  Alle tests werden uitgevoerd op de kaart schaal van 1:113386, wat overeenkomt met de 30 meter pixelgrootte van de bron raster datasets.<\/P>
        <\/A>

        Grafiek 9. Gemiddelde respons in MP\/s voor verschillende aanvraaggroottes voor de weighted overlay service.<\/P><\/DIV>

        <\/A>

        Grafiek 10. Gemiddelde responstijd bij verschillende aanvraaggroottes voor de weighted overlay service.<\/P><\/DIV>

        <\/P>

        <\/P>

        Grafiek 9 toont dat de doorvoer voor deze service afvlakt bij een aanvraaggrootte van ongeveer 1000x1000 pixels tot ongeveer 1,5 6 6 6 6 MP\/s.  Grafiek 10 toont dat de aanvraaggrootte een lineaire impact heeft op de prestaties.  Deze service kan sub-seconde responstijden leveren voor aanvragen tot ongeveer 1.440.000 pixels, of een aanvraaggrootte van 1200x1200.<\/P>

        <\/P>

        Samenvatting<\/STRONG><\/P><\/P>Rasteranalyse kan vele stadia van gegevensverwerking en analyse omvatten.  Complexe on-the-fly verwerkingsketens kunnen zware verwerkingsbelastingen op een server leggen en bijdragen aan trage prestaties.  Enorme prestatieverbeteringen kunnen in sommige gevallen worden bereikt door de gegevens vooraf te verwerken naar een efficiënter formaat voor resampling en on-the-fly verwerking.<\/P><\/P>Voor toepassingen die gebruikmaken van tiled basemap lagen, worden de grootste prestatieverbeteringen waarschijnlijk bereikt door de pixelgroottes van de gegevens af te stemmen op de schalen van het basemap tegelschema.  De sectie 3Map Scales and Source Data Resolution 4 beschrijft de theorie achter deze aanpak en biedt een tabel met aanbevolen pixelgroottes voor toepassingen die basemaps gebruiken met het ArcGIS Online\Bing Maps\Google Maps tegelschema.  Alternatief kunnen ontwikkelaars basemaps bouwen met aangepaste tegelschema's om af te stemmen op de bestaande pixelgroottes van de analysedata.<\/P><\/P>Een andere manier om in sommige gevallen de verwerkingsbelasting op een server aanzienlijk te verminderen is het vermijden van on-the-fly projectie van de analysedata.  Dit wordt bereikt door ervoor te zorgen dat de basemap en analysedata zich in hetzelfde coördinatensysteem bevinden.  De prestatie-impact van on-the-fly projectie varieert afhankelijk van het invoer- en uitvoercoördinatensysteem en wordt besproken in de sectie getiteld 3On-the-fly Projection 4.<\/P><\/P>Het bestandsformaat, pixetype en compressietype van de analysedata kunnen ook een grote impact hebben op prestaties.  GeoTIFF met interne tegels wordt aanbevolen voor situaties waarin het nodig is om de gegevens te herformatteren vanuit een trager formaat.  Pixeltypen met lagere precisie geven betere prestaties dan typen met hogere precisie.  Pixelcompressie kan zowel prestaties verhogen als verlagen, afhankelijk van hoe de gegevens worden opgeslagen en benaderd door de server.  Deze onderwerpen worden besproken in de secties getiteld 3Raster Format 4 en 3Pixel Type and Compression 4.<\/P><\/P>Clientapplicaties kunnen ook een rol spelen in dynamische image service prestaties.  Serviceresponstijden zijn het laagst wanneer applicaties nearest neighbor resampling specificeren, gevolgd door bilinear resampling.  En er is een directe relatie tussen serviceprestaties en de grootte van het kaartvenster in een applicatie.  Deze onderwerpen worden besproken in de secties getiteld 3Resampling Method 4 en 3Request Size 4.<\/P><\/BODY><\/HTML>

DavidJohnson5

I think you have the right idea.  It's great that you are getting good performance at 1:10,000, even though one of the pyramid levels in your source data corresponds to a map scale of 1:10,500. That's the power of Image Server at work!  Image Server is highly optimized out-of-the-box.  For typical service configurations and usages, details like the pixel sizes of the source data are not significant factor in overall performance.  However based on my results, I expect you would get even better performance if the pyramid in your data was at 9,500 instead of 10,500.  Although it's possible that the improvement may not be easily perceived at the human level in your case.  Putting this in perspective, the service I used to generate my results performed a server-side analysis on 11 different raster datasets. So the performance impact of resampling from 11 datasets with sub-optimal pixel sizes was greatly amplified.  Typical image services do not require this amount of heavy lifting.  But for cases like mine where performance was not satisfactory, this is one approach that can potentially bring huge gains in performance.