Find your content:

Search form

You are here

Performance of sites and Authenticated Website User Type


I have to develop a "private" auction site based on data already stored in 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 (backend already developed) and an external db? (I think this solution is more complicated)

Attribution to: Alberto Maianti

Possible Suggestion/Solution #1

We use 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 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.

Attribution to: Shane McLaughlin

Possible Suggestion/Solution #2

I think that using 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, 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 domain for https use? If not then Sites + Customer Portal won't work because they do not support custom SSL certs which means that anything over https must use the 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 Sites can save you a lot of time because you can use the same code for your internal app that you use on 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.

Attribution to: Peter Knolle
This content is remixed from stackoverflow or stackexchange. Please visit

My Block Status

My Block Content