For speed, you'll get the most gains if you denormalize when possible - yes, the relational purists are going to riot, but you don't have many of the benefits of normalization anyway such as foreign key constraints or native joins.
If that isn't an option - and I really do recommend looking into it where it makes sense - if you're able to retrieve keys, we may also be able to make use of batch queries by key. On Mon, Apr 5, 2010 at 2:59 PM, Matt Hall <[email protected]> wrote: > Hi Everyone, > > I've been trying for the past while to get our relatively simple JDO > based site to run at a reasonable speed, but I'm failing and I'd love > any suggestions. I'll describe it as succinctly as possible to > hopefully keep your interest :) > > * The basic structure is a User -> Order -> Line items type > structure. > * The main query performed is "Orders for a user." > * A user usually has around 10 orders, each order has under 100 line > items. > * The Order -> Items relationship is done as a One-to-many owned > relationship. > > My problem is that the basic request the site handles: "Get all orders > for a user and do something based on the line items" is very slow. In > real response time, my average is now 1.5 seconds, and some of the > users are seeing 20 second response times. Clearly not ok. > > What appears to be slow, after profiling with the new app stats tool > is that each line item is getting loaded as it's used (lazy loading), > which works great in some cases but terrible in this case since each > item takes 20-30ms to load. > > I have tried: > > * Moving items into the default fetch group for orders, seems to have > no effect (may not even be possible due to limitations of joins) > * Level 2 caching with memcache - not much effect either since only > the individual line items are cached, not the whole List, so we still > pay a price in round trip to the cache on each line item. > * A sort of wacky cache that I wrote on top of the JDO managed > relationship to cache the whole collection. This went poorly and > resulted in odd data inconsistencies, probably because I did something > wrong but the whole thing felt wrong. > > So my question is - what am I doing wrong? What's the best/standard > way to represent a Master -> Detail type relationship, where the total > items for a user will be relatively small but requests need to work > with a fair number of them. > > Thanks for any suggestions, I'd be happy to answer any questions if > what I've written isn't clear. > > Matt > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-appengine-java%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- Ikai Lan Developer Programs Engineer, Google App Engine http://googleappengine.blogspot.com | http://twitter.com/app_engine -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
