MapGuide RFC 63 - Introducing smart request queues to improve performance and stability

This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	(22.04.2009)
Last Modified	(UV Wildner) Timestamp
Author	(UV Wildner)
RFC Status	(draft)
Implementation Status	(discussion needed)
Proposed Milestone	(2.2?)
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1
no vote

Overview

In the current MapGuide Implementation the multithreaded server receives and processes concurrent requests for computing adjacent tiles. This approach does not make clever use of the machine resources as the parallelization of those operations rarely speeds up the total processing time. Therefore, e propose the introduction of smart request queue which can sort requests by Map & Scale.

Motivation

A memory limitation can cause the mapping / rendering service to abort rendering the tile before all features are determined. Its very interesting that the serialization enforced by STDOUT of the debug build solves this problem already! Returning the faulty tile without an error message is a defect (like #462) However, this gives us as reason to suggest a redesign of the Tiling service.

Basically, the server does not do anything efficient if we start to request mutliple tiles of the same map and scale at the same time. This is like windows copying. If you start n parallel copy streams between the same disks you end up thrashing your disk.

Proposed Solution

1. We therefore propose the introduction of smart request queue into the server which can sort requests by Map & Scale.
2. The request queue serializes all tile requests and creates separate queues for each mapscale.
3. A configurable multiplication factor can be set to ask the tileservice to compute larger tiles which are later sliced up into the requested small ones. Using a smart queue there is a way to block requests for those tiles to come in side the queue.

This does not seem very hard to do and will improve performance and stability of the mapguide server dramatically.

Implications

This requires some thoughtful investigation of the queue structures in the ACE. I believe the LoadBalanceManager is a good starting point to look at doing this.

1. The queue needs to get another dimension based on map and scale information.
2. Tileservice needs to get wrapped (subclassed) with an implementation
   

a) which creates large request from the small tiles

b) blocks existing requests for the same map and scale. (maybe even the lockfiles in the tile cache can serve this purpose.

c) splits up the large tile (calling into new methods in the renderers)

d) releases the blocked requests which are requesting tiles computed in the current request (usimg lockfiles in tilecache??)

Test Plan

TBD

Funding/Resources

TBD

closed Issues

NONE

open Issues

Design

Suggestions

Please Comment.