JCS Lateral TCP Auxiliary Cache Scalability

[Paul Snively <ps...@IFILM.com>]

Gentlemen,

As you may recall, we are evaluating the use of the combination of Hibernate
and JCS for a redeployment of IFILM.com, a massively-trafficked streaming
media distribution site on the Internet. Naturally, we have questions as to
exactly how some of the infrastructure that we would like to be able to rely
on works under particularly demanding scenarios. At the moment, the
important question before us is how JCS' Lateral TCP Auxiliary Cache
implements its put operations. Does it fork a thread per socket connection
to lateral cache, does it do a broadcast to the subnet, does it do a
multicast...? We received feedback from one gentleman earlier who uses the
lateral cache with two machines. Has anyone used it with 10? 20? 30? Are
there either known or anticipated issues with scaling to this level? Any
insights based upon experience are greatly appreciated.

Many thanks,
Paul Snively

RE: JCS Lateral TCP Auxiliary Cache Scalability

[Joe Azure <jo...@openwave.com>]

Blair,

I thought I would give you some of my insights from the bit of work I have
done on the TCP leteral cache...

The implementation I started with (1 weeks old or so), did not work very
well for more thatn 2 nodes since the connection recovery implementation was
a little bit flawed.  That meant that when I started up my servers, all but
the last server was missing connections to some other nodes.

I also wanted my cache to only send cache invalidations over the wire, and
not try to send cached objects, since it was much faster to get them from
the database on the other nodes, rather than serialize them and send them.
I implemented this for our system and performance of lateral caching went up
quite a bit.  Unfortunately I haven't has time to put together some numbers
on this...

The LTCP cache, as it is today, maintains a list of nodes for which it
shares cache regions.  Upon initialization, each node creates and opens a
Server socket that listens for any communication from other nodes (those
nodes may or may not listen to messages from THIS server though).  In
addition to this server socket, a socket is opened to the listening ports of
each of the other nodes, and remains open.  If there is a failure nduring
sending on one of these sockets (or opening it in the first place), that
particular lateral cache is placed in recovery mode, and every n seconds
will try to re-establish itself.

I hope this gives you a little more information....Oh yeah, as for threads,
off the top of my head, I don't remember if the lateral cache updates are
triggered somewhere upstream and then processed asynchronously in another
thread.  Maybe someone else knows has that answer handy?????

Cheers,

Joe

-----Original Message-----
From: Paul Snively [mailto:psnively@IFILM.com]
Sent: Monday, December 09, 2002 4:06 PM
To: 'turbine-jcs-user@jakarta.apache.org'
Cc: Blair Harrison; Tatum Lade; Lee Parayno
Subject: JCS Lateral TCP Auxiliary Cache Scalability


Gentlemen,

As you may recall, we are evaluating the use of the combination of Hibernate
and JCS for a redeployment of IFILM.com, a massively-trafficked streaming
media distribution site on the Internet. Naturally, we have questions as to
exactly how some of the infrastructure that we would like to be able to rely
on works under particularly demanding scenarios. At the moment, the
important question before us is how JCS' Lateral TCP Auxiliary Cache
implements its put operations. Does it fork a thread per socket connection
to lateral cache, does it do a broadcast to the subnet, does it do a
multicast...? We received feedback from one gentleman earlier who uses the
lateral cache with two machines. Has anyone used it with 10? 20? 30? Are
there either known or anticipated issues with scaling to this level? Any
insights based upon experience are greatly appreciated.

Many thanks,
Paul Snively

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>