I have to develop a "private" auction site based on data already stored in Force.com platform.

Develop a site with Authenticated Website User Type is a viable way? I'm worried about perfomance and governor limits of sites like bandwidth and Request Time... I mean that type of site is surely "stressed" by users (multiple requests and so on...)

What is the alternative? Maybe Heroku hosted site with some sort of sync between force.com (backend already developed) and an external db? (I think this solution is more complicated)

2 Answers 2


I think that using Force.com Sites + Customer Portal (for the authenticated portion) is the quickest and easiest way to create a public facing website that uses your Salesforce data as its basis. I had some concerns about the bandwidth and processing time limits as well, but it has turned out to not be an issue at all with many concurrent users. Images, css, etc. can be put in static resources to cache as Shane noted. Still, you should definitely try to come up with a rough estimate of what you think your usage will be for the bandwidth part. I imagine it might be harder to figure out the processing time.

Obviously going the route of a Heroku app is more complex, but creating a Heroku app is becoming easier and now that Java is supported I suspect it will become more of an option for shops that already have Java knowledge. There's also a new Heroku Eclipse Plugin to make it easier to develop. If your data doesn't change much you could pull the data that you need from SF on a regular interval into a local DB for your Heroku app to use and then push back up on a regular interval.

Some other things to consider that are non limits related:

  • Is there a requirement for 365/24/7 uptime? If so, Force.com Sites won't work because it goes down everytime that SF goes down since it is just your VF and Apex running on SF. Still, SF isn't down a whole lot and the upgrade downtime windows are not super long. Of course, if you are using Heroku to connect to SF you'll still have to keep in mind the downtime when designing your interactions with SF.

  • Will it be acceptable for users to be exposed to the secure.force.com domain for https use? If not then Force.com Sites + Customer Portal won't work because they do not support custom SSL certs which means that anything over https must use the secure.force.com domain.

  • You said that data will be shared, but is there any sort of internal SF application that your are building that will share a lot of the same functionality? If so Force.com Sites can save you a lot of time because you can use the same code for your internal app that you use on Force.com Sites. Even if you can't reuse all of the VF pages you can abstract a lot of the business logic into a service layer and share that.


We use force.com site and authenticated site. At some times (doing a story on the evening news) we've put thousands of users on it simultaneously.

The non-authenticated users are counting against your request time, etc. Once they log in, bandwidth and request time are not the issues...you already paid for the login volume so they're only subject to the normal limits that your internal users have.

And we're doing some pretty heavy calculation stuff (debug log on a primary page runs 2MM lines).

So far we've been pleased. Use static resources as much as possible so they cache. Our experience has been that the denser the traffic, the faster it goes.

Also carefully check the license object access for the auth site user....they can't edit some of the standard objects so you end up writing extra code for wrappers, validations rules that you'd normally use native VF field capabilities for.

You must log in to answer this question.

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