Infrastructure Map Server Developer

Reply
Valued Contributor
swimming123
Posts: 86
Registered: ‎04-12-2012
Message 1 of 8 (1,049 Views)

AIMS map rendering speed

1049 Views, 7 Replies
03-04-2013 03:30 PM

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.

Valued Mentor
jackie.ng
Posts: 273
Registered: ‎10-06-2008
Message 2 of 8 (1,035 Views)

Re: AIMS map rendering speed

03-04-2013 05:02 PM in reply to: swimming123

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

Active Member
kalman.albert
Posts: 9
Registered: ‎09-30-2008
Message 3 of 8 (1,021 Views)

Re: AIMS map rendering speed

03-05-2013 07:31 AM in reply to: swimming123
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
 
 
Valued Contributor
swimming123
Posts: 86
Registered: ‎04-12-2012
Message 4 of 8 (1,017 Views)

Re: AIMS map rendering speed

03-05-2013 10:37 AM in reply to: kalman.albert

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?

 

Valued Mentor
jackie.ng
Posts: 273
Registered: ‎10-06-2008
Message 5 of 8 (1,014 Views)

Re: AIMS map rendering speed

03-05-2013 05:38 PM in reply to: kalman.albert

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

Valued Mentor
jackie.ng
Posts: 273
Registered: ‎10-06-2008
Message 6 of 8 (1,009 Views)

Re: AIMS map rendering speed

03-05-2013 05:55 PM in reply to: swimming123

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

Valued Contributor
swimming123
Posts: 86
Registered: ‎04-12-2012
Message 7 of 8 (908 Views)

Re: AIMS map rendering speed

03-18-2013 12:16 PM in reply to: jackie.ng

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.

New Member
MitchGreig
Posts: 1
Registered: ‎10-11-2013
Message 8 of 8 (312 Views)

Re: AIMS map rendering speed

10-11-2013 02:05 PM in reply to: swimming123

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.

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Are you familiar with the Autodesk Expert Elites? The Expert Elite program is made up of customers that help other customers by sharing knowledge and exemplifying an engaging style of collaboration. To learn more, please visit our Expert Elite website.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community