trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <>
Subject Re: Initial doubts
Date Tue, 22 Feb 2011 16:19:20 GMT
On 02/22/2011 04:33 AM, 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

View raw message