MogileFS limits...

[dormando]

> has anyone added in memcached in front of the tracker db? seems like
> another layer of caching could be thrown in to save some of the work
> (although i don't know how the workload is really...) and of course
> sharding and just using mysql proxy/multiple servers... seems like
> eventualy too many files you'll have to scale the tracker db too. but
> i suppose that is expected.

Yeah. We just haven't had to scale out the DB yet. It'd be a snap from 
multiple design points though.

The trackers support internally using memcached to cache paths, but most 
folks use external patch caching:

1) cache paths returned from the tracker in memcached, fetch from app 
(don't have to talk to tracker at all for a cache hit)
2) and/or use perlbal's header/patch caching stuff. Internal to perlbal 
so it'll skip hitting the app/memcached entirely.

> is perlbal required?

Nope. You do need something on the storage nodes to update io statistics 
though. Could be anything.

> i have nginx right now running as my mogstored http server. i saw it
> can be used in its place... it was a piece of cake to setup. where
> else would perlbal be required at this point?

You need something with reverse proxy redirection (I guess nginx does 
this?) in front of your whole kit. So your app/whatever returns paths to 
perlbal/nginx/whatever and will serve up the actual file from mogilefs.

> i am looking into suggesting and trying to get development started (if
> it makes sense) for a mogilefs-aware plugin to nginx. something like
> the X-Sendfile header  in Lighty (or X-Accel-Redirect in nginx
> already) but you can give it a mogilefs key instead... feed the file
> directly to the webserver and release PHP/etc. from it (just like
> X-Sendfile stuff does for normal files...)

Yup, same idea as the default perlbal stuff. Kinda.

-Dormando