Changes between Initial Version and Version 1 of MapGuideRfc63

Timestamp:

04/21/09 19:56:06 (16 years ago)

Author:

uvlite

Comment:

--

MapGuideRfc63

@@ +1 @@
+= !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 [wiki:MapGuideRfcs 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 [[BR]]
+
+    a) which creates large request from the small tiles [[BR]]
+
+    b) blocks existing requests for the same map and scale. (maybe even the lockfiles in the tile cache can serve this purpose.[[BR]]
+
+    c) splits up the large tile (calling into new methods in the renderers)[[BR]]
+
+    d) releases the blocked requests which are requesting tiles computed in the current request (usimg lockfiles in tilecache??)[[BR]]
+
+
+== Test Plan ==
+
+TBD
+
+== Funding/Resources ==
+
+TBD 
+== closed Issues ==
+
+NONE
+
+== open Issues ==
+
+Design
+
+
+== Suggestions ==
+
+Please Comment.