On 10/3/06, Jonathan Dance <jd-a...@public.gmane.org> wrote:
some webservers have dynamic database support... they connect to the
db as needed to parse requests. it sounds awesome, until you realize
that its awesomely stupid. the db calls end up blocking the server,
the configuration is a nightmare, and perfomance/usage just sucks.
I think the biggest reason things like dbm or rdbms support gets added
directly into web servers is that it allows run-time configuration -
you do not need to reload, which can be a lot easier for people who
are not shell-comfortable (like PHBs). The (big) downside with a rdbms
is that the server does not know if something has changed, so it needs
to constantly ask the data source for the latest information (although
you could have it cache it for a limited period of time, e.g. 1
minute). With a file-based dbm, the server can cache results but will
have to keep checking the ctime of the file, which is better but still
adds overhead and considerable extra code.
Not saying dbm or rdbms support is a good idea, but just adding some
perspective.
PHBs don't typically configure web servers (and certainly don't
currently use nginx or complicated database configuration backends),
so that's rather irrelevant.
I've never seen a web server that constantly hits a db for
configuration... anyway, you could do the same thing with shell
scripts that poll the db, write a new conf file, and HUP the web
server if the config is valid.
I wouldn't be against having a separate contrib daemon that does
something like this, but I definitely do not want to see database
drivers ending up loaded in the workers or the master.
-bob
7 messages in ru.sysoev.nginxRe: Re: Feature Req: Include Pipe
