[mapguide-internals] ServiceArchitecture and design rules??

[Trevor Wekel]

Hi UV,

MgByteReader::Read(BYTE_ARRAY_OUT buffer, INT32 length) is a copy only paradigm.  However, most of the Server code passes MgByteReader* so the copying would only occur when the contained data is actually used.

For tight loops which use the same MgByteReader object, I agree that copying does add overhead.  Do you know of any other specific instances where this copying occurs?  MgByteReader typically contains the end result of an operation.  I am not aware of too many places where this tight loop would occur.  "->Rewind()" in a loop would indicate such behaviour.  I don't see it being called in too many places.

Another place where copying occurs is STRING.  This is a remap of std::wstring.  I suppose we could replace std::wstring with ICU (http://site.icu-project.org/) but that would be lot of work and I'm not certain that ICU's reference semantics are much better than what we have now.

As for object references being more stable than copies, I'm not so sure about that.  The reference counts must be 100% thread safe and there is more likelihood for data corruption with tons of threads accessing the same piece of data.  You'd probably have to implement copy on write to guard against unexpected behaviour.

Regards,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: March 20, 2010 11:57 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] ServiceArchitecture and design rules??

Hi trevor,

thanks for the offer.
However, I think server internals should be discussed on this list so it 
can be references later and adds to the server internal code documentation.

BUFFER COPIES
I came into this while working on metatiling where large objects (>1MB) 
needs being reused.

The return type MgByteReader being used for many API calls is a copy 
only datatype.
Instead of providing access to the underlying buffer it provides only a 
copy operation.
Its a serializable type which seems to be made for network transfer. 
Thats fine if used that way.

However, with the advent of multi-core CPUs scaling up a server is 
usually done on a single node with more cores  and a large shared memory
where using shared buffers with proper reference counting is a lot more 
performant!

So there is currently a lot of memory overhead caused by copying which 
is unnessary within the same address space
which applies to the vast majority of server usage scenarios!
This seems a similar issue to the cache design which 
serialize/deserialize objects
which somehow seems to miss the point when done within the same address 
space.
(also some of this caching in the FDO part is supposedly not multi user 
safe as stated by Harris on 19.05.2009)
So there is a lot of copying of data happening in this code base which 
seems not always necessary.

Was this a choice being made when trying to scale out the server to 
multiple nodes a while ago?

I think we should discuss a change of programming paradigm.
This could lead to some of the classes being reimplemented with this 
change in mind.
(and we could swap implementations depending on sever configuration)
Maybe this is not soooo much work after all and I believe it would 
increase performance and stability a lot!

Any thoughts?


Trevor Wekel wrote:
> Hi UV,
>
> Did you want to contact me offline?  I can help you wade though it all and provide suggestions on the implementation.  I am on Skype and have reasonable long distance rates to various countries (Canada, US, Germany, Australia, Slovenia, and others).  I think this topic would be a good candidate for a verbal conversation.  It might take too long over email.
>
> The same offer (live chat - wow!) applies for any developers out there working on projects with the intent to submit them to the vault.  One of my personal goals for this year is help with community involvement, even though it will likely cost me some potential consulting revenue :(
>
> Just ping me by email to schedule something.
>
> Thanks,
> Trevor
>
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
> Sent: March 19, 2010 8:15 PM
> To: MapGuide Internals Mail List
> Subject: [mapguide-internals] ServiceArchitecture and design rules??
>
> Hi,
>
> i just wondered if someone can provide a bit deeper insight into the 
> service architecture.
>
> I am trying to distribute some functionality between the service as 
> indicated by visibility of code.
> (as we dont want/can simply include everything as needed - the big C++ 
> linking problem)
>
> e.g. I want to add a internal API method to the MgServerRenderingService.
>
> Trying even to access a static member directly fails due to DLL 
> import/export settings.
> I suppose this is due to design as it looks there have been some fancy 
> plans regarding service distribution.
> Or is there a trick with the preprocessor how to include other services 
> to get the DLL access done correctly?
>
> or is the only doable solution to propagate and expose any internal 
> interservice API via the MgRenderingService so I can access it via the 
> service manager?
>
>     Ptr<MgRenderingService> svcRendering = 
> dynamic_cast<MgRenderingService*>(
>         serviceMan->RequestService(MgServiceType::RenderingService));
>
> This feels like a costly overkill for addressing server internal 
> functionality which should be local....
> and what code is needed in the proxy version for an internal APi call.....
>
> thanks for some clarification
>
> _______________________________________________
> 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