I am working on a rather complex application hosted on Heroku and pulling data from Database.com. Because of the way SOQL works, I usually make a number of calls where I would traditionally have made one with a pile of joins. Because there is a reasonably large delay between the call and the response, this can result in heavy penalties.

So far I have moved the queries out of loops, mapping by Id which has lead to some improvements but even without looping, there are still quite a few calls. What can I do to improve response time?

  • Not that this helps, but recently learned about the existence of heroku/postgres. There's a webinar coming up on Aug 23rd that may interest you.
    – Adam
    Commented Aug 11, 2012 at 18:26

3 Answers 3


Round trips will kill you, so you want to do as much as possible in a single round trip, one thing you could do is encapsulate your multiple queries into a single operation using a custom web service (either soap or rest, depending on whats supported better in your client), this would get you down to 1 distributed API call, which would help a lot.

  • Thanks. This would, unfortunately, result in a huge refactor but now I know in the event time is allocated to speed things up. Commented Aug 13, 2012 at 14:22

Two generic things that come to mind are caching and asynchronous operations.

For caching, you have three options, depending on the scale and complexity of your app:

  1. In session
  2. At the application level
  3. A caching server

Option 1 works well if the data is user-specific while the second two work well for global data. This will partially be determined by how long the data is valid and how long you can reasonably display stale information.

For asynchronous operations you need to make sure the calls to database.com are not blocking the main thread. This would allow you to start displaying data while the calls complete.

  • I thought about caching but ran into the problem of how to determine stale entries. With SQL, a short and sweet call for a time stamp can be enough to determine if an entry needs to be refreshed. Because the call itself, not the payload is the problem I'm having, that time stamp call could be only marginaly quicker. Commented Aug 11, 2012 at 23:50
  • The caching can be tricky. Some items you'll know are long lived (maybe pick list options or something similar) where as others you may have to manually expire, such as whenever a delete/update/insert operation is done.
    – Mike Chale
    Commented Aug 12, 2012 at 0:54

For cloudspokes, we followed Superfell's approach of custom REST services on DB.com. It's not only good for efficiency, but the loose coupling makes it easy to consume the same services from mobile clients.

  • this probably should be a comment, not an answer.
    – superfell
    Commented Aug 15, 2012 at 23:55
  • Stackexchange does not allow you to post a comment to someone's else's answer unless you have 50 reputation, which is a stupid policy because it forces you to post comments as answers. Lots of posts about this such as: meta.stackexchange.com/questions/9701/…
    – Rob Cheng
    Commented Aug 16, 2012 at 18:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .