AIMS map rendering speed

[swimming123]

I think AIMS2013 do has some advantages compared with Mapguide 6.5 old version. But the speed to render a map is our concern, especially we have heavy data.

In our situation, each of a map includes minimum 120 layers, total we have 1800 maps( I use 8 links to point to these layout/map resources for internal and external users dynamically), even it just takes 8 hours for caching one map, it still takes 2 years to cache all the data. So I prefer no cache. Then usually it takes half minute to zoom in/out. Additional factor is we have to update some of spatial data once a month, caching is not our first option. Any suggestions for this situation? Thank you.

[jackie.ng]

Here's a general checklist:

• What data sources? SQLite is the fastest of the lot whose read performance is unmatched by other providers. If exporting from AutoCAD Map, consider SQLite as the goto file format.
• Feature density. Do you need to see all these features at this scale in such high detail? Consider generalizing/sub-sampling your data at specific zoom levels. This is especially relevant for raster imagery.
• For RDBMS data sources: Do you have proper spatial indexing applied for your geometry columns? SQL Server is notorious for being dog slow if you feed it a default [-180,180,-90,90] spatial index.
• Feature Joins: Performance will be bad/erratic if the join is on multiple properties and/or one side of the join is from a Feature Source using any of the following providers: OGR, WMS, ArcSDE, <any FDO provider that does not support ordered queries>

The new profiler in AIMS2013 should tell you what Layers/Feature Sources need to be investigated

- Jackie

[kalman_albert]

I don't think AIMS2013 has some advantages, maybe few (don't belive all marketing text) . If you need speed forgot AIMS. We tested and unfortunately MG6.5.is much faster than AIMS.

If you want AIMS work you need n x Server n x Processor,n x Core, n x Memory (and always is not enough)  and for MG 65. is need 1 server 1 procesor and few memory.

Today we still use MG 6.5 and we will use more time in the future after  manage to install on win server 2008 on x64.  Autodesk not convince me with MGE.

Unfortunately the join table (secondary table)  in AMIS is absolute

impossible  to use compare what simple,versatile, and fast is in MG65, therefore because customer request work their GIS as 'Google maps speed' and the date to be online the MG6.5 still alive.

When we use  MGE (sorry, MGOS) ?, MGE(MGOS) has a good render engine to generate report, is much, much better like Lite view.

Kalmy

[swimming123]

Thanks all above suggestion comments.

Jackie, most of our data is shapfiles stored in PostgreSQL/PostGIS (a few raster data). Because we already decide use AIMS, we have to improve the rendering speed. So far, we can do the following things to improve a little bit:

• Big layer/shapefile separated into several small shapefiles;
• Using "Base Layer Group", not manually caching (because it takes too long time). But the AIMS is not good as open source, you can round up all the sacle values, not as good as open source you can swith between "Base Layer Group" and normal layer group just one click;
• sub-sampling/generalizing data at specific zoom level.

Any other suggestions?

[jackie.ng]

Notice how your Google Maps, Bing and OpenStreetMap load in square by square?

That's because they're tiled maps, pre-baked and ready to be served through a series of load-distributed servers. So if someone asks for "Google Maps speed", they are asking for tiled maps (that AIMS can do) whether they are aware of it or not.

The perceived performance of MG 6.5 is because all the hard work is off-loaded to that filthy, IE-only, black box, ActiveX viewer control. It's 2013, such black box, Microsoft-only technology does not belong here.

AIMS is not MG 6.5. Don't look at AIMS with a MG 6.5 mindset.

- Jackie

[jackie.ng]

Okay, since you're housing most of your spatial data within a RDBMS, then the full suite of DBMS optimizations are available to you, that AIMS doesn't and won't need to be concerned about.

This is venturing into DBA territory, but a general list would be.

 * Turn on trace logging in the PostgreSQL FDO provider (link) and see what gnarly SQL the FDO provider is sending off to postgres.

 * Use EXPLAIN / query execution plans provided by postgres/pgadmin to give you a better idea how such SQL queries can be improved through proper indexing.

 * Indexing specific columns to improve queries that have filters.

If this indexing stuff is a bit over your head, there's a site that explains it better than I can: 

http://use-the-index-luke.com/

- Jackie

[swimming123]

Using Base Layer Group, add multiple connection to RDBMS for each of heavy data group also can improve the rendering speed dramatically. Thx for Jackie solution.

[MitchGreig]

We've been working with AIMS 2013 for about a year and have been live for just over two months so I figured it's time to share some things we've learned for other's benefit. I work with swimming123 so I figure I should elaborate on his point above about postgres.

I assume it is the nature of the FDO provider but each data connection you make to a PostgreSQL database acts as one connection to the database. So if you have only built one data connection everything is being piped through one connection which will act as a significant bottleneck. By giving your heavier data its own data connection (even though its just a duplicate resource) you will allow it to be queried simultaneously to your other resources. Now, there are limitations to the number of connections that make sense to a postgres database (We are moving the DB to a second server and setting up connection pooling over the next few weeks), but you are doing yourself a tremendous disservice by using one.