[mapguide-internals] Re: Please review RFC 73

[Kenneth Skovhede, GEOGRAF A/S]

OK, I was not considering that MgMap.Create was in another
process than the repository. Thanks for clearing that up.


Another question:
How are permission issues handled if there is a partial error?
Eg. requesting 2 resources, but access is denied to one of them?
An exception could also happen while accessing one of the resources.

Simply returning an error would follow the current "abort" method
on runtime map creation failure.
There has been talk about fixing this behavior.

If this RFC would at least consider what implications the change
would have for fixing this, I would be happy.

A method could be to return an exception list.

Regards, Kenneth Skovhede, GEOGRAF A/S



Trevor Wekel skrev:
> Hi Kenneth,
>
> Data transmission from server to web does take some time.  Furthermore, all service operations are queued. Currently, rendering requests and repository requests are on the same queue.  This means each GetResourceContent request is interleaved/queued alongside any rendering service request.  If the average queue wait time is 1 second and your map has 100 layers, then you will be waiting 100 seconds for the map to appear.  Moving the whole thing server side take the resource requests out of the queue so the resource operations should complete in around 5 milliseconds, yielding an MgMap.Create time of around half a second for the same 100 layer map.
>
> Thanks,
> Trevor 
>
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Kenneth Skovhede, GEOGRAF A/S [ks at geograf.dk]
> Sent: Monday, July 13, 2009 1:30 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Re: Please review RFC 73
>
> 1)
> If you replace a sequence of GetResourceContent calls,
> I would expect that the only performance improvement
> is perhaps the absense of a number of locking calls.
> The actual time is, AFAIK, spent in the xmldb code,
> making little room for perfomance gains.
>
> So, the motivation is a bit thin, but the calling code
> will likely benefit from the combined call.
>
> 2) Ok
>
> 3)
> I have yet to figure out the MapGuide macro system, so I can't help you
> there :).
> I just have a desire to be able to call the WebTier and get multiple
> resources
> with one call instead of many. The http overhead is quite significant.
>
> Regards, Kenneth Skovhede, GEOGRAF A/S
>
>
>
> Christine Bao skrev:
>   
>> Hi Kenneth,
>>
>>      Thank you for your comments.
>>
>> 1.  The load that would be removed would be for sequential requests to the XmlDb?
>>
>> I'm not sure about your meaning. If you're talking about how to get the collection of resource contents by the collection of resource ids, I'm going to leverage the existing GetResourceContent(resourceid, preprocesstag) function. Yes, it will call XmlDb by a sequential requests.
>>
>> 2.       How much improved?
>>
>> It's hard to give a number. The more layers in a map, the more significantly improved. We'll have performance test later to see how it improves.
>>
>> 3.       Expose to WebTier
>>
>> Yes, then it should be PUBLISHED_API instead of INTERNAL_API, is it right?
>>
>> Thanks & regards,
>> Christine
>>
>>
>>
>> From: "Kenneth Skovhede, GEOGRAF A/S" <ks at geograf.dk>
>>
>> Subject: Re: [mapguide-internals] Please review RFC 73
>>
>> To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
>>
>> Message-ID: <4A53272C.8020502 at geograf.dk>
>>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>
>> The load that would be removed would be for sequential requests to the
>>
>> XmlDb?
>>
>>
>>
>> This is definately a logic improvement, but have you quantified how much
>>
>> faster this will make the MgMap operation?
>>
>>
>>
>> Would you consider exposing this improved function to the WebTier?
>>
>>
>>
>> Regards, Kenneth Skovhede, GEOGRAF A/S
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>     
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals_______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>