plugging into the backside of ATS?

["Earle, Erik" <Er...@disney.com>]

Is there a good starting point for looking at plugging into the internals of ATS.

For example, suppose I wanted to replace the default caching mechanism with memcache or add a full http client (like libcurl) without blocking in a continuation callback thread.

Re: plugging into the backside of ATS?

[Leif Hedstrom <zw...@apache.org>]

On 05/27/2011 01:28 PM, Earle, Erik wrote:
>
> Is there a good starting point for looking at plugging into the 
> internals of ATS.
>
> For example, suppose I wanted to replace the default caching mechanism 
> with memcache or add a full http client (like libcurl) without 
> blocking in a continuation callback thread.
>

You'd want to implement that as a 'server intercept' plugin I think Then 
your plugin acts as the "origin", and you have to implement all access 
to either the memcache storage, or HTTP yourself. You then have the 
option to make the "response" cached in the normal ATS HTTP cache (i.e. 
if you use TSHttpTxnIntercept() it would not be cacheable, while if you 
use TSHttpTxnServerIntercept() it will go through the HTTP SM, and 
therefore potentially could be cached).

This would be a fair amount of work, but I've seen it done at least 
once, and it worked very well (it used a distributed FS as the "backend" 
cache). There's no way, currently at least, to implement a replacement 
HTTP cache as a plugin (so, an intercept plugin is the only way to do it).

Cheers,

-- Leif

Re: plugging into the backside of ATS?

[Leif Hedstrom <zw...@apache.org>]

The implication being that if you need a distributed cache, you should try our  clustering features.

Cheers,

-- leif

On May 27, 2011, at 3:37 PM, John Plevyak <jp...@gmail.com> wrote:

> 
> Just an FYI, the clustering support in the proxy right now is optimized for some non-obvious case: very
> large documents are streamed in chunks, and header matching occurs on the cache which contains the
> document which minimizes round trips, staging to disk handles the long tail, etc.
> 
> I think that you will find that replacing the disk cache with memcache will not improve performance and
> will likely run into some subtle problems.  However, I am interested to see the results.   BTW: I have
> a memcache on TS implementation around somewhere, for a persistent memcached.
> 
> john
> 
> On Fri, May 27, 2011 at 12:28 PM, Earle, Erik <Er...@disney.com> wrote:
> Is there a good starting point for looking at plugging into the internals of ATS. 
> 
>  
> 
> For example, suppose I wanted to replace the default caching mechanism with memcache or add a full http client (like libcurl) without blocking in a continuation callback thread.
> 
>  
> 
>  
> 
>  
> 
> 

Re: plugging into the backside of ATS?

[Eric Balsa <er...@apache.org>]

I started messing around with a protocol plugin
[http://trafficserver.apache.org/docs/v2/sdk/NewProtocolPlugins.html]
of the memcached protocol on top of the TS cache (sounds like John
beat me to it). Think that could be way cooler (persistant, protocol
compatible, high performing, large object support, etc) than TS
caching to memcache.

Don't forget the 1MB limit on memcached "objects". I'm pretty sure you
can increase that, but I think it's compile time IIRC:

http://code.google.com/p/memcached/wiki/FAQ#What%5Fis%5Fthe%5Fmaximum%5Fdata%5Fsize%5Fyou%5Fcan%5Fstore?%5F%281%5Fmegabyte%29

--Eric

On Fri, May 27, 2011 at 2:37 PM, John Plevyak <jp...@gmail.com> wrote:
>
> Just an FYI, the clustering support in the proxy right now is optimized for
> some non-obvious case: very
> large documents are streamed in chunks, and header matching occurs on the
> cache which contains the
> document which minimizes round trips, staging to disk handles the long tail,
> etc.
>
> I think that you will find that replacing the disk cache with memcache will
> not improve performance and
> will likely run into some subtle problems.  However, I am interested to see
> the results.   BTW: I have
> a memcache on TS implementation around somewhere, for a persistent
> memcached.
>
> john
>
> On Fri, May 27, 2011 at 12:28 PM, Earle, Erik <Er...@disney.com> wrote:
>>
>> Is there a good starting point for looking at plugging into the internals
>> of ATS.
>>
>>
>>
>> For example, suppose I wanted to replace the default caching mechanism
>> with memcache or add a full http client (like libcurl) without blocking in a
>> continuation callback thread.
>>
>>
>>
>>
>>
>>
>

Re: plugging into the backside of ATS?

[John Plevyak <jp...@gmail.com>]

Just an FYI, the clustering support in the proxy right now is optimized for
some non-obvious case: very
large documents are streamed in chunks, and header matching occurs on the
cache which contains the
document which minimizes round trips, staging to disk handles the long tail,
etc.

I think that you will find that replacing the disk cache with memcache will
not improve performance and
will likely run into some subtle problems.  However, I am interested to see
the results.   BTW: I have
a memcache on TS implementation around somewhere, for a persistent
memcached.

john

On Fri, May 27, 2011 at 12:28 PM, Earle, Erik <Er...@disney.com> wrote:

> Is there a good starting point for looking at plugging into the internals
> of ATS.
>
>
>
> For example, suppose I wanted to replace the default caching mechanism with
> memcache or add a full http client (like libcurl) without blocking in a
> continuation callback thread.
>
>
>
>
>
>
>