Stefano Mazzocchi wrote:
> Berin Loritsch wrote:
>
>
>>However, what I see as more practical is that the specific files cached
>>might change by the time of day. For instance, web administrators usually
>>have log analyzers that will easily determine which parts of the site get
>>hit heaviest at which time of day. This is very important. For instance,
>>we may want the cache to artificially lengthen the ergodic period for specific
>>resources during their peak load in order to scale more gracefully as more
>>users view those resources.
>>
>
> hmmm...
Got you thinking huh? :)
>>Such an adaptive cache would
>>be _more_ concerned with slowly degrading performance by serving stale data
>>rather than ensuring the data retrieved from the cache is the most up to date.
>>
>
> Good point.
>
> I see two ways of achieving this transparently:
>
> 1) tune your Cacheable behavior for those resources that need this
> 2) add a site-wide Cacheable behavior that is summed to the other
> Cacheable events
>
> of course, we must have a way to measure *machine load* from java both
> fast and reliable (probably a sampling thread asking for 'uptime' or
> similar and storing this someplace?)
This is true. It is something that I have given some thought about, but
haven't done any research into yet.
>>This would be an adaptive cache that *could* possibly have pluggable or adaptible
>>policies regarding stale data. For instance, a site like Slashdot can get away
>>with marginally stale data as the average user is not constantly using it
>>in day to day work. However, such a policy would be vey detrimental to a
>>corporate web site that managed the daily workflow of information that is
>>core to the company's needs. It is also detrimental to web sites that require
>>that users cannot see each other's data, where privacy and security are
>>chief concerns.
>>
>>However, for sites like D-Haven (if I get the time) is supposed to be, stale
>>data would be acceptable because the content would have a naturally longer
>>ergodic period to begin with.
>>
>
> If you already know your site is not going to change for a given period
> of time, well, batch generate the site and be happy (like we do for
> *.apache.org), if parts are dynamic and parts are not, use both, if
> everything is dynamic (yes, there are cases where *everything* needs to
> be dynamic), you have to tune your cache.
And that is the point. Right *now* D-Haven would be better off batch
generated. However, when it gets to full potential, almost everything
will need to be dynamic. You also have to concider the cost of batch
generating in a mixed environment. For example, if only one or two
pages are batch generated, and the rest of a large site is dynamic,
it would be cheaper and easier for the one or two pages to remain
dynamic.
>
> By having pluggable Cacheable logic, you can even say that, if load is
> higher than a certain amount, the cache is still valid, no matter what
> happened to the real data.
Exactly.
>
> The IoC cache design allows you to do what you want and the adaptive
> caching even to turn caching off for those resources where even 'trying
> to cache' is more expensive than not even trying.
>
> But even adaptive caching will not remove your needs to optimize and
> design a system in order to scale. No matter how smart it is.
All we need now is one that is not only adaptive, but makes predictions
based on probability ;P
(Sorry, I have been reading up on Artificial intelligence, and probability
theroy is pretty interesting...)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
