make Cache extensible #357

Closed
tj opened this Issue Sep 5, 2011 · 10 comments

Comments

Projects
None yet
2 participants
Member

tj commented Sep 5, 2011

so that we can support Redis etc instead of in-memory caching only

I donnot see support redis is a good idea.
because redis is for name/value store, value is not same as static file.
If we use redis cache, we should connect to redis process, that's much slower than access node's memory,
and access of redis must use asynchrous call, coding is more complex than using node's variable directly.
If we like redis's swap func, we can design a in-node-memory cache who's argorithm is better than simple LRU instead.
By the way, I read the source of staticCache and find cache will not invalidated when corresponding file is changed.
I beleave solve that problem is more urgent than supporting redis.

Member

tj commented Sep 14, 2011

agreed, this is not priority, the main benefits would be:

  • less bloat for the node process(es)
  • shared cache

redis being a key/val store makes it perfect for caches. the cache
logic in here should at very least be designed in such a way to accomodate such a thing

if for the reasons below
1/less bloat for the node process(es)
2/shared cache
we can set up a separate node process for static file caching
that cache-node-process will do better than redis for static-file only caching
and we only need node, we don't have to setup a redis
If we think v8/node has high performance, we can devloper node' version redis ,
that will better than redis for redis-of-node is only for javascript access.
If v8 has memory layout similar to compiled/semi-compiled lang such as c++/java,
the cache has compact data layout, consume low memory, and provide quick access.
client API will be much simple, for example :
cache = new require('jsCache',{host:xxx.xx.xxx.xxx:port});
cache.set(path,object) -- that will stringify object and sent to jsCache server,then be parsed and named with path
cache.get(path) -- that will communicate to jsCache server that will return a stringified json and revert to object.
So, jsCache will better than radis and more better with V8/js-engine improve it's proformance.

Another think, if js worker thread is supported in the future, cache in main thread can shared among all worker threads,
and at the same time, cache is accessed as js data directly, better speed than communicate to other cache service.

Member

tj commented Sep 15, 2011

im not suggesting everyone should use redis, just that it should be extensible, this would be abstract, so it could be more node processes, redis, mongo, memcache, anything.

jsCache can be designed to reliable service.
jsCache can replicate to other memeber service at other mechine
jsCache can flag data region's activeness, then serialize the data to file, when needed revert to mem js objects.
when received signal to exit, save entire data to disk first.
every tech other than js that can format data to json can use http to access jsCache and get json result.
so it's general cache, not for js/node only.
Since js is object/data in engine's mem and every data has a name/path, so jsCache is natually a good data cache,

We just want to solve the problem of cache for js,
so we donn't need to and shouldn't being so extensible and so open for every existing cache that are not in node's world.
cache is just for speed and easy api/use, so a jsCache for node is natrual choice,
if being extensible is need, desige the API for jsCache is enough, every one can implenment jsCache with that API,
but donn't invite outer world cache, deployment/develpment get more complex, and
, in practise, if one use node/js , one just want a simple pure js/node eviroment, not to invent additional complexity.

Member

tj commented Sep 15, 2011

im just saying a good API, is one that is abstract, that can work with anything the developer wishes. We use redis in many cases, and it's trivial to install, many people use memcache etc, there's no need to force everything on node, nor will that spawn an elegant API.

Every lang/api has goals, abstract is not final goals, too abstract and too open may not be good, we'll be losed in practise,
Fewer high-quality fitted implemetation is better than much choice.
Nokia has too much model but Apple wins with only iPhone.
Android has many versions/branchs, so dev/use on it is much complex than iPhone.
So, keep think as simple as posible and then more peaple will use.
A good cache API is good idea, but I donnot want to see many redis/... implemetations, because is no simple.
Sometime give user too many choise may mislead them.

Node is invented to replace the currently popular server-side software, so if node need a cache, it's better base on node/js.

Member

tj commented Sep 15, 2011

Sure, I agree, but it's trivial in this case to abstract the cache logic, and it is simple, it's extremely simple to use redis as a cache, there are benefits to using things like redis, and there are benefits to using node, and some for the simplicity of in-memory cache like we have now, that's all there is to it

Member

tj commented Oct 16, 2011

meh for now, people can use something much faster than node if they go beyond the use-case of staticCache

tj closed this Oct 16, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment