I can see that having an effect with the given numbers. But what about a 5 seconds cache. Afterall it takes at least a couple seconds to load any page in the browser. I think 5 or even 10 seconds would be just as good unless the app is Ajaxified. Then I would go lower.

do you mean browser caching, data caching (e.g. memcached/Application Cache) or output/proxy caching (e.g. squid) ?

I think it depends what you want to save, and how often the data is modified... if it is modified once a day, then caching for 1 second is a bit daft :-) but if it can change within seconds, you probably can't live with multi-minute or hour caches.

Again, it depends what you're caching and where, but the most sensible approach is to consider the lifecycle of the data to understand how long it can be cached for. You can of course do explicit event driven cache refreshing - e.g. when you update dataset x or namespace y or even object z, then replace the cached object (though it depends whether you're caching single items or sets etc), but it can be a useful option.

I think we need more info if you want a better answer as there is no magic one-size-fits-all solution, and it's very dependable on the dynamics of the architecture and the data.

Yes, it's a potentially good idea, as long as you are only caching what you actually need. I think you would need to decide which parts of the page need caching. Is it just a certain table of data, a few tables, or the whole page that is changing? You may even decide to have a collection of cached data objects which are set at different intervals as some may not have the same priority as others.

I modified the post because I was not clear in explaining what I was talking about

So, given your 1000 hits and 100 writes, you want to serve up 1 version per second, rather than 100 versions per second?

Insanely brilliant!

No one is going to know (or care) that it's being updated once per second rather than 100 times per second.