locked
WCF Data Services Server - Performance issue during projection. RRS feed

  • Question

  • Hi,

    I have been working on performance optimizing our custom data service provider. In this proccess I have run into a bottle neck in WCF Data Services Provider (the server part).

    The issue is related to GET requests (queries) containing projections (a $select). It seems that for each returned entity the WCF DS server framework will call TryResolvePropertyName on the ResourceType for each property in the projection.

    Now - imagine I am returning 10000 entities and projecting 20 properties. This will result in 200000 calls to TryResolvePropertyName. Now if look at the implementation of TryResolvePropertyName with ILSpy, we'll end up in this...

    internal ResourceProperty TryResolvePropertyName(string propertyName, ResourcePropertyKind exceptKind)
    {
    	return this.Properties.FirstOrDefault((ResourceProperty p) => p.Name == propertyName && (p.Kind & exceptKind) == (ResourcePropertyKind)0);
    }
     

    If my ResourceType has 200 properties and i am only projecting the 20 last properties in the Properties Collection, this alone takes around 1.2 seconds. In my setup this around 50% of the entire querying processing time on the server - including roundtripping to a database on another machine and getting the response back to the client.

    I know you are dedicated to performance (you often state that on the blog), could you please have a look at this.

    As a comparison: If the Propertis collection were a Dictionary<srting,ResourceProperty> 200000 lookups could be made in 0.05 seconds.

    Another approach would be to only do this havy stuff for the first entity in the feed.

    Is there any way to hook into this property resolving stuff, so I can do a more efficient implementation myself?

    Btw. This is on WCF Data Services 5.5.0 with a custom provider.

    Kind Regards

    Uffe


    • Edited by Uffe Lauesen Thursday, June 13, 2013 5:39 PM Soften up title
    Thursday, June 13, 2013 12:14 PM

Answers

  • Thanks for reporting this. I was able to repro this on my end and have already a fix for this ready. When we release the next version, this should be fixed. Just to make sure, we are doing all the heavy lifting while parsing the URL, hence there should be no need to look up for properties during serialization in projection scenarios.

    Thanks a lot once again for bringing this to our attention.

    Pratik


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Thursday, June 13, 2013 6:17 PM
    Moderator

All replies

  • Thanks for reporting this. I was able to repro this on my end and have already a fix for this ready. When we release the next version, this should be fixed. Just to make sure, we are doing all the heavy lifting while parsing the URL, hence there should be no need to look up for properties during serialization in projection scenarios.

    Thanks a lot once again for bringing this to our attention.

    Pratik


    This posting is provided "AS IS" with no warranties, and confers no rights.


    Thursday, June 13, 2013 6:17 PM
    Moderator
  • Thanks for the quick response Pratik.

    Looking forward for the next release then - I would expect it will speed up our system quite a bit and with less resources.

    Regards

    Uffe

    Friday, June 14, 2013 6:48 AM