CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • Slow first usage per-type with Client DataPortal

    rated by 0 users
    Not Answered This post has 0 verified answers | 15 Replies | 2 Followers

    Top 500 Contributor
    23 Posts
    andrew123 posted on Mon, Jul 28 2014 4:17 AM

    I'm finding that when I first start up my application the first client dataportal usage PER TYPE, is very slow.

    So, for example, the first Fetch of MyObject takes around 800ms, whereas every subsequent MyObject takes around 250ms (the server is in a different location).  If I then Fetch MyOtherObject (without restarting the application), this first usage is slow, but subsequent usages are fine.

    The server is running at all times using a SelfHosted server (not IIS) so should be fully up and running and with no startup delays, so I don't believe that the server-side is affecting things.

    I've had a look around at the usual suspects for first WCF usage being slow, but neither seems to make a difference:

    - proxy detection (I don't have a proxy and have tried setting the relevant config file things to disable)

    - serialization (I have tried forcing serialization of MyObject manually before first using the DataPortal)

     

    I am not specifying a serializer, so I think this means that it will be using BinaryFormatter.  I have my DataPortal configured to use NetTcp with transport level security.

    The thing is, if this was slow for the first usage for ALL objects (i.e. the first usage of the first type is slow, but aftewards everything is fine), I would assume this is a WCF thing, but because the first usage of every type is slow, it makes me think this has something to do with CSLA and the way it does things.

    This is also the same in a Release build after ngen-ing the binaries.

    Does anyone have any other ideas for what could be causing this?  Does anyone else see the same issue?

    Could it be to do with the fact that the WCF service is based upon reflection (dynamic typing) and how the serialization handles this?

     

     

     

    All Replies

    Top 10 Contributor
    2,279 Posts

    How about the initialization of rules. 

    AddObjectAuthorizationRules and AddBusinessRules methods is called only the first time you touch an object of that type. Do you do any database access or other possible time consuming operations in one of these methods? 

    It could also be caused by initialization of KeyValuePair lists used by rules when they fetch the initial list from the database (and cache them internally so you do not get the cost on next access). 

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 500 Contributor
    23 Posts

    Thanks for the reply Jonny.

    I've checked and we are using per-type Auth and Business rules, but none of these fetch data from the DB.

    The BusinessRules are all using CSLA simple rules such as MaxLength etc. with hardcoded values.

    The Auth Rules use some AuthorizationRule derived classes, but their data is all pre-loaded into a client cache on app startup (and besides the call to access this data is within Execute on the rule only).

    I have put traces into the client DataPortalInvoke and DataPortalInvokeComplete as well as some tracing on the server-side in the DataPortal_OnDataPortalInvoke and DataPortal_OnDataPortalInvokeComplete.  It appears that the major delay comes between the DataPortal_OnDataPortalInvokeComplete on the server and the DataPortalInvokeComplete on the client side. 

    Any ideas what could be causing this?

    Side note: These are Sync requests, not Async.

    Top 10 Contributor
    2,279 Posts

    Hi,

    I would suggest that you run a Profiler - Performance Session to determine where the CPU time is consumed. 

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 500 Contributor
    23 Posts

    This is exactly what I did yesterday.

    There are two places that are significantly slower the first usage than the second:

    System.Net.Socket.Receive - 

    and

    System.Runtime.Serialization.ClassDataContract.ReadXmlValue

    Both are during the client read (Csla.DataPortalClient.WcfProxy+<Fetch>d__a.MoveNext())

    I have tested on other networks so don't think it is a transmission issue.  It looks like it is the NDCS being slow deserializing.

    I've checked and CSLA is definitely using the BinaryFormatter, so I guess the NDCS seems to be slow deserializing the WcfResponse object?

    I am going to have a play with pre-serializing some of the objects to see if this speeds things up.

     

    Top 500 Contributor
    23 Posts

    I've switched to basicHttpBinding to rule out any net.tcp weirdness, but am still getting the same delay.

    One thing I have noticed is that now I can view the raw http data in Fiddler, the Object data appears to be Xml encoded.

    However, when I put a breakpoint on my csla Server, the ApplicationContext.SerializationFormatter is set to BinaryFormatter.

    I was expecting therefore in the raw Http request/response in Fiddler to see Xml versions of the CSLA Request/Criteria/WcfResponse classes, but with raw binary data for the object data field.  Should I?

    I wonder if something is misconfigured to cause the BinaryFormatter not to be used?

    Top 500 Contributor
    23 Posts

    Following on from my previous reply, could someone clarify something around the serialization.  The "Using CSLA 4 - Data Portal" e-book says:

    "The WCF data portal channel uses the NDCS, because that is how 

    WCF serializes data for transfer over the network. Even when the WCF data portal channel is used, 

    CSLA .NET defaults to using the BinaryFormatter for all serialization operations outside the data 

    portal."

     

    Does this mean that when WCF is used as the transport NDCS is used for serialization of the objects no matter what CSLA is configured to use?

     

    Top 10 Contributor
    2,279 Posts

    Hi, 

    Data is serialized in 2 steps:

    1. CSLA serializes the object structure to a byte array in memory (default BinaryFormatter)
    2. The serialized object structure is sent in a DataPortal envelope (including f.ex. ApplicationContext, User etc) using the serializer for that channel. If you use WCF channel the default is NDCS.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Top 500 Contributor
    23 Posts

    Hi Jonny

    This is strange...because I don't think I am seeing this.

    When I set the basicHttpBinding for the WCF service and ran Fiddler over the communications, I could see the objects were serialized in XML - I could read all of the property names and values etc.

    I was expecting, and judging by your reply what I should see, to see an Xml response object within which is a property which contains a blob of raw data of the object.

    At runtime, CSLA is definitely stating that the ApplicationContext.SerializationFormatter is BinaryFormatter though.

    Any ideas?

    Top 10 Contributor
    9,475 Posts

    There are a number of data portal channel implementations, so it depends on which you are using (and which version of CSLA).

    The _mobile_ WcfProxy does this:

    1. "serialize" the object graph into a flat object data structure
    2. Serialize the flat object data structure into a byte array (typically XML)
    3. Transfer the byte array via WCF - and of course WCF serializes the payload too, probably using DataContractSerializer

    The _non-mobile_ WcfProxy does this:

    1. Serialize the object graph via WCF, forcing WCF to use the NDCS
    2. WCF transfers the serialized data over the wire because it managed the serialization

    The HttpProxy does this:

    1. Serialize the object graph to a byte array using the formatter configured for use (typically MobileFormatter, so like the _mobile_ WcfProxy)
    2. Transfer the byte array via an HTTP request with the byte array as the payload - iirc it is Base64 encoded, but I'd have to look at the code to be sure

     

    Rocky

    Top 500 Contributor
    23 Posts

    Thanks Rocky.

    I guess that explains why I am seeing XML serialization as we are using the non-mobile WcfProxy.

    I've managed to speed up first usage by forcing types through the NCDS at startup, but it's not ideal.  I guess I can't use the svcutil to generate the XmlSerialisers.dll because the WcfProxy DataContract properties are "object" and don't know about my types!

    Top 10 Contributor
    9,475 Posts

    Jonny is right though, if you haven't run a profiler you could be wasting your time on the serialization issue.

    Rocky

    Top 500 Contributor
    23 Posts

    Agreed - and this is what I first did.  See earlier reply

    There are two places that are significantly slower the first usage than the second:
    System.Net.Socket.Receive -
    and
    System.Runtime.Serialization.ClassDataContract.ReadXmlValue
    Both are during the client read (Csla.DataPortalClient.WcfProxy+<Fetch>d__a.MoveNext())
    

    I've now got something running on app startup to find all serializable types in my assemblies and to run them through the NetDataContractSerializer. The speed of the first usage of the DataPortal for each type in the same ball park as subsequent uses.

    But it does take about 30-45 seconds to run through all of my types at startup, so its not ideal. I know that first usage of Xml Serialization is known to be slow, and you can pre-generate the serialization data for them (see http://msdn.microsoft.com/en-us/library/aa751883.aspx) but unfortunately because the CSLA DataContract is simply "object", if I run the svcutil over it, it isn't going to know about my types at that point!

    Is there any way to get the non-mobile proxy to use the same mechanism as the mobile one re: binary formatting the objects first before adding to the request/response? I am using binaryMessageEncoding (and net.tcp) in WCF, but I feel I am losing the benefit when the entire objects are first being serialized into XML by the NCDS.

    Top 10 Contributor
    9,475 Posts

    If you are using CSLA 4 I'd recommend just switching to the "mobile" data portal. In version 4.5 I think the mobile implementation is generally better than the previous implementation, and works universally across all the supported platforms (well, to be fair, HttpProxy works _everywhere_, but the mobile WcfProxy works most places).

    Rocky

    Top 500 Contributor
    23 Posts

    I'd like to try it, but at first attempt I have serialization errors (I fixed the first one around Generic Principal, but swiftly moved on to another) "Serialization of type object is not supported."

    The application I have inherited has approximately 1300 objects based up CSLA base classes (which I suppose *should* just work as the bases implement IMobileObject).  There are also ton of other criteria objects that are just POCOs though, so I would need to convert these to CriteriaBase.  I feel I might be pulling at a thread with this...!

    I take it that I can't use the Mobile DataPortal with BinaryFormatter!?

     

    Page 1 of 2 (16 items) 1 2 Next > | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems