e at osterman.com
Wed May 9 18:21:11 UTC 2007
Python proof of concept code.
It doesn't appear to cache contents, only stat.
Also, on a philisophical side note. I am floored by how often almost
identical ideas are conceived of by different people at the same time.
Look at the date on that blog entry!
Cal Heldenbrand wrote:
> This is really cool! One section of our application is mapping, which
> uses MapServer <http://mapserver.gis.umn.edu/> along with ka-map
> <http://ka-map.maptools.org/>. For tiles & shape files, we have an
> NFS backend (a bigass NetApp box) to serve all of these up. Granted,
> the netapp performs really well, and serving up static tiles seems to
> be an easy task for it at the moment. If this particular service
> becomes really popular, I could see that a large cache could be
> helpful to our architecture.
> I would definitely be excited if someone started working on this. (I
> might even help out if I can!)
> Cal Heldenbrand
> FBS Data Systems
> E-mail: cal at fbsdata.com <mailto:cal at fbsdata.com>
> On 5/9/07, *Erik Osterman* <e at osterman.com <mailto:e at osterman.com>>
> MogileFS is pretty sweet; I'll give it that. We considered it
> pretty seriously before going with GlusterFS. Since MogileFS
> relies on application modifications, which isn't a possibility
> when the application is blackbox, we ultimately decided against
> it. I don't think they finished the fuse module either, and the
> web page still says, "We've prototyped a FUSE binding, so you
> could use MogileFS without application support, but it's not
> Also, I'm less thrilled about managing MogileFS with all of its
> Perl depenencies. Memcache and GlusterFS are a cakewalk in
> comparison to setup and configure. Granted, GlusterFS isn't yet
> fully production worthy, it's been stable for us.
> Note that CacheFS is not dependent on the underlying filesystem,
> so a MemcacheFS developed in the same fashion could straddle
> multiple exported filesystem types, such as NFS, GlusterFS, SMB,
> OpenAFS, and even MogileFS. In much the same way Memcache doesn't
> tie you to one database, MemcacheFS wouldn't tie you to one type
> of networked filesystem.
> Thanks for the suggestion...
> Erik Osterman
> Bruce Wang wrote:
>> On 5/9/07, *Erik Osterman* <e at osterman.com
>> <mailto:e at osterman.com>> wrote:
>> Right, this is along the same lines, but not generalized.
>> They made Lighty Memcache aware, but that doesn't do much for
>> other applications, e.g. our XSLT processor which can only
>> access files. Further more, since it's not generalized, the
>> cached data cannot easily be shared by many unrelated
>> applications. So, if different applications employ their own
>> Memcache caching strategy, a lot of memory is waisted on
>> duplicate data. Though, embracing this idea, one could use
>> Lighty + modmemcache + webdav + fuse but that sounds very slow :)
>> Is this what you want? Also by Brad Fitzpatrick
>> simple is good
>> skype: number5
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached