Meanwhile, I keep trying to think of workarounds ... the EntityCacheState will serialize to the SL client correctly in v5.2.3 coming Oct. 15, so grabbing all this data via an invoked server method which does the AsyncParallelTask and returns an EntityCacheState could be another option.  PM or email me if this is something you'd want to try now.

 

As for a workaround for you right now, I don't know what to tell you.  Presumably the AsyncSerialTask will be faster, but at about 30 seconds probably still too slow.  You might be able to use .Include with some of your queries.  I know you'd tried a giant .Include query with poor performance, but maybe "judicious" use of .Include which keeps the SQL queries from getting too ugly might be a compromise.

 

 

AsyncParallelTask (with 18 queries) in SL        = 60 seconds
daisy chained 18 queries in SL                         = 30 seconds
18 async queries in SL                                     = 160 seconds
AsyncParallelTask (with 18 queries) on server = under 1 second

 

I also want to test the AsyncParallelTask with a BOS in non-SL to get an idea of what the transmission hit is between a BOS and no-BOS run.  I can do this later today in our test suite.  Right now I think it's still unclear what is transmission-related overhead, what is SL-related, and what is AsyncParallelTask-related.

 

    var items01 = from item in em.BusAssociates select item;
    Assert.IsTrue(items01.Count() > 0);

 

.. this selects only the number of items, it doesn't retrieve the items and then do a count.  DevForce handles the retrieval of a primitive much differently than the retrieval of entities which need to be merged into cache.  When going over the wire too there's of course a big difference in message size.

 

I didn't know you were working with the development web server, in that case, I use Firefox and Firebug (which may require Fiddler too I'm not sure, but integrates really well with it).  Ward blogged about how to set up Firefox and Fiddler - http://neverindoubtnet.blogspot.com/2009_08_01_archive.html.

 

 

 

You will have some performance hit in Silverlight because the data has to be sent across the wire, but that hit shouldn't be as big as you're seeing.  If you're not using a ServiceReferences.ClientConfig the default binding uses binary encoding.  (Beta versions of DevForce Silverlight used text encoding.)  If you are using a ClientConfig, what do the bindings look like?  I'd really recommend using Fiddler to inspect the messages and request/response times.  (The message sizes will probably be a bit large -- we've reduced some bloat in the coming release, and will be adding compression in a following release.)

 

Out of curiosity, if you run a single async query in Silverlight test, w/o using the AsyncParallelTask, how long does that take?

 

I think we already covered this before, but make sure the EntityManager used for the queries is both connected and logged in prior to executing the task.  If it's not, you'll see lots of superfluous connect/login calls to the server.

 

Async fetch logic, both pre- and post-, and the AsyncParallelTask, is the same in Silverlight as in non-Silverlight; so there is no difference in events fired or anything else.  Property interceptors and validators are not fired during the data load, nor is PropertyChanged.  The EntityChanging and EntityChanged events do fire.

 

Edited to add  -

The parallel task always returns the results from each async query back to the calling thread, so potentially you could see the async portion of all the queries complete, but the final post-processing involving the merge into the EntityManager cache all has to be done synchronously (because the EM is not threadsafe), so this could back up.  (I haven't actually seen this is testing, but I believe it's possible.)

 

First, what does an async query do that would take 10 seconds?   Good question.  An async query has 3 "phases":  1) where it checks if connected and logged in and whether the query can be satisfied from cache; 2) the async phase, where the request is sent to the EntityServer on a separate thread; and 3) the merge of the returned data into the EntityManager cache, done back on the calling thread.  Various events are fired along the way also.  Why this whole process would take 10 seconds for very little data I don't know, since we haven't seen this issue in our tests.  Even launching Prism Explorer directly from our website, you generally see queries completing within a second or so. 

 

I would try to break this down a bit -- first see what the generated SQL looks like; next take that SQL and run it standalone within a query window (SQL*Plus or whatever) to see how long the database takes to execute it; next use Fiddler (or the network tool of your choice) to see what the request and response times are to the EntityServer.   If all of this looks reasonably good, then I'd focus on what's happening as the data is merged in the EM cache.  You will see the EntityChanging and EntityChanged events fired during the merge, and you'll see getter actions called if the data is bound to a UI control.  It might be worthwhile to retrieve the data without having bound it to anything to get a better idea of how long the merge into cache is taking.