Community Update: Intros, Tour de Force, Visualforce

by Jon Mountjoy on May 30, 2008 at 05:03 AM

I'm a new member of the force.com team, and I'll be working here as the community manager and editor-in-chief of developer.force.com. As a result, I hope to be touching base with a lot of you developers, ISVs and admins out there, as well our internal salesforce.com employees. I'll also be working at developing our blog and content strategies, infrastructure and more. There's a lot to do, and I'm keen to help our thriving community grow even bigger. Feel free to ping me at any time about the community, with any suggestions, complaints or comments (jmountjoy at salesforce dot com) or join me on Twitter or other data streams.

I will be producing a community update like this every week or two, highlighting forthcoming events (check out the awesome Tour de Force website with new events in the USA, Ireland and Japan), community members (see Anshu), webinars (Move Beyond S-Controls), interesting board threads, things that catch my eye (like the Dreamforce Session Idea site), external sites (Simon, Joe, Steve and many more) and so on, so please stay tuned.

Regards,
Jon

Resources

We have a couple of new resources for you:

  • A short Visualforce Components Demonstration by Adam Gross shows off some of the capabilities found in Visualforce Components. This is going to big: reusable, modular, user interface components. I need to create a directory listing components that we can start finding them all. Done!
  • A new Visualforce resource page recently went live, pointing to reference material, tutorials and webinars to get you up to speed on the technology.

Blogs

In the blogs, I'd like to welcome new blogger Anshu Sharma. Anshu blogged about being In India, with Force(.com)!, and some of the questions he encountered during a talk he gave on PaaS and Force.com.

Also in the blogs, Ron Hess tells us about Coding The Cloud at Google's I/O Event, where he's presenting on integrating force.com apps with Google GData interfaces. I'm also keen to see how our developers use the new Google Earth API. We've seen plenty of Google Maps mashups - now how can we use Google Earth too?

Finally, Peter Coffee has some interesting thoughts on what it means to be Disconnected. He makes the point that "..it's not the problem of any single technology provider (or even any particular subset of the tech provider ecosystem) to solve the problem of staying up and running even if your public network link is intermittent."

Upcoming Events

From our event calendar, we have the following events that may interest you:

Education Services

Education services have two upcoming courses:

Technorati Tags: , ,

Comments (1) | TrackBack (0) Save to del.icio.us Digg this story

Limits on search query sizes

by purpleprose on February 21, 2006 at 03:35 PM

To improve performance and reliability, salesforce.com has recently set a limit to getUpdated and getDeleted queries at 600,000 records. Queries that exceed that limit will get an error of EXCEEDED_ID_LIMIT.

If you need to retrieve more than 600,000 records, we recommend splitting the query by narrowing the date range.

Comments (1) | TrackBack (0) Save to del.icio.us Digg this story

gzip matters

by Simon Fell on December 4, 2005 at 06:45 PM

I've put together a little .NET app called SforceExporter than allows you to explore the performance improvements the various perf recommendations make, in summary, if you do nothing else, make sure you're using gzip compression for a nice & easy 6x perf boost.

Comments (2) | TrackBack (0) Save to del.icio.us Digg this story

Data Loading Performance Benchmarks, Factors and Techniques

by Andrew Waite on May 19, 2005 at 12:26 PM

The performance of bulk operations using sforce is influenced by a number of factors including:

  • The org-wide sharing model for the object under operation. Private sharing models with lots of sharing rules may reduce performance.
  • The presence of any active workflow rules that have to be evaluated/fired and what events are tied to that  rule (creating tasks and sending email alerts is a significant drag on performance)
  • Number of columns in the load (inserts/updates)
  • Inclusion of long text fields (i.e. Description)
  • Available bandwidth in your network connection

When operating on large amounts of data (>10,000 records) you should, as a best practice, take the following considerations:

  • Temporarily Disable all Workflow Rules on the object (unless they need to be fired)
  • Enable compression in your SOAP client. For help on compression and additional performance tips see Performance tips (incl. compression)

You can also consider using the Data Loader since it:

  • Implements compression
  • Handles batching for you
  • Has both graphical and command-line interfaces
  • Bypasses the writing to the recent items list

The Sforce Data Loader will be available soon at no additional cost and with source code included. Stay tuned to sforce.com for the official announcement!

Comments (2) Save to del.icio.us Digg this story

Performance tips

by Simon Fell on April 4, 2005 at 09:22 PM

Getting the maximum performance out of the API requires following a few simple rules.  The main difference is that you are going over a Wide Area Network, so network times will be higher. 

We have spent a significant amount of time desiging our API for optimal performance.   Please follow the following guidelines when using the API

  1. Most calls are bulk calls (they can take more than one record).  Do not sit in a loop calling create with just 1 account, batch them up and pass 200 accounts to create in one go.  Loading 1,000,000 records can be done in 5,000 calls or 1,000,000 calls.  Doing it in 5,000 calls will dramatically improve performance
  2. Get familiar with the retrieve call.  If you are pulling data from related tables, the retrieve call is a high performance call that you should be using
  3. Cache metadata, if you're using the describe* calls a lot, cache the results of each call for the duration of the session.
  4. Make sure you're using HTTP/1.1 persistent connections, every time you create a new connection, you have to go through the SSL setup again, persistent connections allows you to aggregate that SSL setup code over multiple requests. (If you're using Axis, this means ditching the default HTTPSender, and using the superior, but not default commonsHTTPSender class instead)
  5. Use compression, unless you have an OC45 connection into the back of your machine, compression will help reduce transmission times, the Sforce API supports gzip and deflate compression for both request and response.
  6. Consider a local lookup cache.  If you are constantly doing lookups, you should consider a local lookup table.   

    See these tech notes for help on compression:

    SOAP Compression in Visual Studio
    Enabling SOAP Compression in Java with Apache Axis

Comments (3) Save to del.icio.us Digg this story