On 02/22/2011 04:33 AM, [email protected] wrote:
Ok, understood. Maybe first in RAM and then move to SSD or HDD based on its size.
That gets even more problematic, particularly with large objects (it works well for small objects though). And it probably has negative effect on RAM cache hit performance (TS actually does the exact opposite, it writes to disk cache first, and only promotes to the RAM cache when an object is fetched more than once). This is to avoid unnecessary churning of the RAM cache.
That much said, I can imagine applications where such an approach would make sense, it's something to discuss on the dev@ mailing list I think, and get smart people like John involved. Your suggestion has the nice benefit that it makes it easier to decide which disk cache an object belongs to (since it's post-fetch).
So to understand, at this moment all users are treated equally? I guess the main problem is as the user wont be authenticated, we wont know who he is, thus bad to track user usage :(
Correct. You can track by IP though, so if you are in a controlled environment, and people have well known IP's (e.g. assigned via DHCP / MAC addresses), you could follow that. Writing a plugin that does authentication wouldn't be horrible difficult, but requires C-coding skills. I'm also not sure that we have appropriate APIs to provide the authenticated user information from a plugin back into certain sub-systems, such as logging. Once we get someone working on such a plugin, we'll also have to investigate that (and we're certainly open to adding new plugin APIs to make sure features such as this can be properly implemented as plugins).
I guess then at this stage better to stick to caching only and leave other stuff to other applications.
Squid provides all (and more) of the features that you are looking for. I'd definitely take a look at it as well.
-- leif
