[Catalyst] Re: Serving "static" content from DB

[Aristotle Pagaltzis]

* John Romkey <romkey at apocalypse.org> [2009-06-06 14:55]:
> There are very few drawbacks to serving directly from the
> filesystem (only one I can think of, which has to do with
> access control to the content), while there are several when
> serving from the DB, mostly performance-related. Apache is very
> good at serving a static file quickly

Varnish is even better at serving cached objects. I wouldn’t
deploy an app without a reverse proxy in front any more. For
static content in the DB, use some form of content addressing
scheme (use some hash of the content as the key for the file),
then you can set the expiration date for those URIs to 20 years
in the future and let the frontend cache sort them out.

> - when you have to pull a large object out of the database,
> you're dramatically increasing the instruction path and you're
> also increasing the number of copies of the data that it's
> necessary to do. Add in the overhead of then passing it through
> Catalyst and you've probably increased your overhead by orders
> of magnitude.

Who cares? The frontend reverse proxy will keep that object
cached for the next 3 weeks if it’s hot for that long. Those
requests are never going to punch through to the Catalyst app
server so how slow or fast things are on the Catalyst end is
just a pointless microoptimisation.

And the backend gets that much easier to set up, because you no
longer need to worry about which processes running where have
what sort of access to what part of the filesystem, and is the
app server configured to put the files where Apache will map them
to the right URI?

What a headache.

Just stick it in the database, have the app serve it, and let
HTTP worry about optimising GETs. That’s what it was *designed*
for, and it’s *awesome* at that. Learn it, live it, love it.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>