Hi,

Let's say I have a web server (Nginx) that looks up files in a certain directory and serves them to users. For example my www doc root is site/ :

/home/me/www/site/
                 index.html
                 blah.css

Does that make sense if "site/" actually is a soft link to, say, "sitev1/" like that:

/home/me/www/site -> /some/where/else/sitev1
/some/where/else/sitev1/
                       index.html
                       blah.css

That way I only have to change the target pointed by "site" when I want to put sitev1 or sitev2 in production for example.
I tested this configuration, it is working great. But are there any drawbacks or unwanted side effects ? (sorry, I'm new to this)

Thank you

Backup tools know to look for symlinks and treat them specially, but nginx likely just opens the file and the kernel does the rest (quite transparently). That transparency allows the kernel to efficiently cache the link translation and Make Things Happen, all with nginx completely oblivious.

In short, the presence of a symlink shouldn't be a bother under reasonable load. If you had millions of symlinks, maybe...

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

Apache has a "FollowSymlinks" option which may affect settings like yours. But as far as I'm aware of, nginx doesn't care. As jed said, the impact of symlinks on overall performance should be also negligible.

As for backup tools, that depends on the options you use. For example, if you use rsync to copy your stuff to another location, you'll need to set either the -l option or the (more popular) -a option in order for rsync to take care of symlinks automatically.

Thank you very much jed and hybinet.
I think I'll give that symlink based layout a chance. I understand it's pretty much a standard on linux (shared libs in /usr/lib for example) but I was not sure in a webserver context.
As for backup tools, I don't plan to use them because a Git repository is in charge of the site materials. My idea is to export (git archive) interesting branches when they are finalized (sitev1, sitev2..). I then just update the symlink. I would not have to edit nginx.conf and restart the server. Also, if sitev2 is horribly broken, I can quickly switch back to sitev1.