>
> I was having a similar discussion related to memcached (dumb blogs of data)
> vs. Scala and Actors distributed via Terracotta.  The discussion boiled down
> to the fact that Actors are stateful wrappers around the data.  Having the
> Actor manage the update messages rather than blowing away the blob from
> memcached when something updates something that could impact blob state
> seems to be the smart way to go.  There was an excellent presentation about
> a year ago from the folks that did Chow Hound at CNET.  They used memcached
> and their biggest issues where making sure that the memcached objects
> reflected reality without destroying the value of the cache.
>
> I think the Actor model of managing state gives the benefits of memcached
> with a ton more intelligence.  With Erlang, you just add boxes (rather than
> worrying about hash key sharding and other wacky ways of distributing the
> cache across machines.)
>
> My 2 cents (or morning rant as the case may be.)
>
> Thanks,
>
> David

I think this is a good idea. However, I don't think processes make the
distributed storage problems go away. Even if you stored state in
actors/processes, you would need to be able to look up the process for
a given object ID, which means you would need some centralized lookup
table plus some algorithm for distributing processes between nodes
(taking into accounts nodes crashing and new nodes joining).

The nice thing about processes is they can die if they don't receive a
message in X minutes, enabling automatic garbage collection of idle
sessions.

In Erlang, though, the best way to store a lot of data in RAM is to
use ets tables because ets tables don't get garbage collected. The
helps maintain soft real-time performance and avoid long gc cycles
even when you have gigabytes of objects stored in RAM.

Memcached is written in C, so it doesn't suffer from the GC issue.
However, sometimes memory management in C can be even slower because
free() can be quite expensive. I wonder if memcached uses a more
clever strategy such as memory pools.

Yariv

>
> >
> > Yariv
> >
> >
> > On Jan 16, 2008 7:51 AM, Itai Zukerman <[EMAIL PROTECTED]> wrote:
> > >
> > > > A PHP presentation tier talking to an Erlang web service for its data?
> > > > Reimplementing PHP in Erlang? Compiling PHP to Erlang? What are the
> > > > benefits? Et c. :)
> > >
> > > I'm thinking of a PHP extention to turn PHP into an Erlang "C-node",
> > > and then use Erlang to manage persistent data, communication, etc.
> > > Basically what Yariv does, but with a PHP front-end.
> > >
> > > So PHP would look like this:
> > >
> > >   $pid = erl_self();
> > >   erl_send( "[EMAIL PROTECTED]", "{~p,get_user_info,~d}", $pid, $userId
> );
> > >   list( $i, $term ) = erl_receive( "{ok,UserName,UserAge}",
> "{error,Why}" );
> > >   switch( $i ) {
> > >     case 0:
> > >       list( $name, $age ) = erl_extract( $term );
> > >       ...
> > >     case 1:
> > >       list( $why ) = erl_extract( $term );
> > >       echo( "error: $why" );
> > >       ...
> > >   }
> > >
> > > I'm a bit unsure about the best way to pull the data out of the Erlang
> > > terms.  I've only skimmed through the erl_interface docs.
> > >
> > > Why?  Because although I haven't tried it, yet, I suspect Erlang would
> > > make a better, more stable and scalable back-end than a memcache+Java
> > > combination.  And you need PHP because, well, it's so popular.
> > >
> > > >
> > >
> >
> > http://liftweb.net
> > Collaborative Task Management http://much4.us
> >
> > > >
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to "Bay Area Functional 
Programmers"  
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/bayfp?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to