Optimizing GIS Services: Scalability & Performance. Firdaus Asri

Transcription

1 Optimizing GIS Services: Scalability & Performance Firdaus Asri

2 Define Performance

3 Performance The speed at which a given operation occurs E.g. Request response time measured in seconds

4 Scalability The ability to increase output and maintain acceptable performance Examples Capacity 10 maps/sec and response time 1 second Capacity 1000 cars/hrs and speed 55 mph

5 Capacity The maximum level of output the system can produce At capacity Over capacity

6 Bottleneck Resource(s) limiting the performance or capacity Think of : lanes - as CPU processor toll booths as ArcGIS Server instances cars - as map requests Low Load High Load

7 Response Time Step Load (users) Response Time (sec) time

8 Resource Utilization User load Throughput(req/hr) CPU Utilization (%) Network used (Mbps) Response Time (sec) Capacity (~ 85% utilization) Memory used (Mb) Content length (bytes) Time

9 Required Skillset Configuration, Tuning, Testing Performance Tuning Sizing (Hardware and Software) Performance Testing

10 Performance Factors - Software

11 Factors of map service performance Data access Rendering Image compression / size Consider all of these when creating a map service

12 Data Access Local data will draw faster than remote data Versions maintenance Less version the less state lineage Delta tables getting too large Spatial index Do you have one? (e.g. XY events) How long has it been rebuild and compressed? Attribute indexing Not always needed

13 Data Access Troubleshooting Publishing analyzers indicate lack of a spatial index etc. Evaluate index efficiency The number of features returned for each draw query Large index grid sizes lead to too many features being drawn Evaluate I/O performance if using remote data Unnecessary attribute indexes May confuse query plans in some databases Don t index fields just because they exist in a def query

14 Rendering Speed Optimized map services were introduced to resolve performance bottlenecks at this stage Remaining areas to be concerned with: Complex effects (e.g. geometric effects in representations) Inline annotation (aka Bloated annotation) Anti-aliasing performance Higher levels use more RAM and are slower Text anti-aliasing has a negligible effect in most cases Layer transparency

15 Image Rendering Smaller images are faster to download Image formats have limitations e.g. limited color palettes, lossy compression Image compression itself has a performance penalty Use the preview window to evaluate performance of image type Evaluate size and performance in a test service in network conditions Balance size vs. quality when choosing the image type based on your needs

16 Image Rendering (cont.) Image type used for cached services affects: Download size Storage size of the cache Portability For caching vector data Consider new PNG image type Chooses the correct PNG type (8, 24, 32) for each tile based on content Low content areas use less storage.

17 Geodatabase Performance Keep delta tables and versioning tree small Reconcile and post Compress Synchronize replicas Rebuild indexes Update statistics

18 Map Service Optimization Turn Off capabilities you don t need No of Instances Rarely: 0-1 Medium: 2-2 High: 3-3 Turn On Check and Repair Data Connection

19 Demo: Part 1

20 Performance Factors: Hardware

21 Hardware Resources CPU Network bandwidth and latency Memory Disk

22 Processor

23 Memory Guideline Item Web Server ArcGIS Server ArcGIS Server with Image Extension Oracle SQL Server PostgreSQL File GDB Memory 2GB per Core 4GB per Core 5GB per Core 8GB per Core 4GB per Core 2GB per Core 1GB per Core

24 Hardisk Use the best possible hardisk SAN for Server SSD for Desktop Increase Pagefile provide more virtual memory

25 Virtualization Performance depends on configuration and implementation 5-30% Deploy servers in the same techbase and VLAN Overburdened VMs will incur significant performance degradation

26 Network Latency Network Type Range Notes LAN < 10 ms Target < 1 ms Wired WAN / Internet < 400 ms Target < 100 ms Wireless WAN / Internet > 500 ms High variance

27 Performance Testing

28 Testing Objectives Meet Service-Level Agreement (SLA) Bottlenecks analysis Capacity planning Benchmarking different alternatives

29 Testing Tools Test Tools Open Source Pros LoadRunner No Industry Leader Automatic negative correlations identified with service-level agreements HTTP web testing Click and script Very good tools for testing SOA Test results stored in database Thick client testing Can be used for bottleneck analysis Cons High cost Test development in C programming language Test metrics difficult to manage and correlate Poor user community with few available examples Silk Performer No Good solution for testing Citrix Wizard-driven interface guides the user Can be used for bottleneck analysis Moderate to high cost Test metrics are poor. Test development uses proprietary language. Test metrics difficult to manage and correlate Poor user community with few available examples Visual Studio Test Team No Low to moderate cost Excellent test metric reporting Test scripting in C# or VB.NET Unit and web testing available Blog support with good examples Very good for bottleneck analysis No built-in support for AMF No thick-client options Moderate user community JMeter Yes Free Tool Provides only response times Poor user community with few available examples

30 Performance Monitoring

31 What Need to be Monitored? Hardware (perfmon) CPU, Memory, Network, Disk Uptime GIS Services (ArcGIS for Server Stats, IIS logs) Response Time Throughput Uptime Geodatabase (ArcPy) Number of connections Feature class count DBMS (system views)

32 Demo: Part 2

33 Q & A

34 SOLUTION MIX Technology: ArcGIS for Server Enterprise Geodatabase Data: HERE Data Resources: solutions.arcgis.com

35 STAY CONNECTED Esri Malaysia Training: Subscribe to our e-newsletters:

36