signal process in nginx

[Brian Akins]

On Dec 21, 2011, at 7:09 AM, 한그루 wrote:

> 
> My customer wants two way synchronization instead of one way propagation. For example if a backend server fails to return then nginx should notice operators promptly that the server is bad.  

Couldn't you do this notification via log scrapping?  Also, depending on your setup, it's very likely that you will get transient upstream failures, so you may get a lot of "false positives."


> In addition we have not only server list but also other kinds of repository.

What types of "things."

> For example, some policy like max_session_count or  max_session_rate per one server etc. anyhow i can't help but modify nginx code.

If it can be controlled via the config file there is no reason to modify nginx code.  We have some settings that vary based on the "size" of the server running nginx (worker count, connections, etc), but we use a single configuration template.  Also, the contents of upstreams vary on data center and/or availability zone, etc.

> 
> By the way reloading the config doesn't affect the performance of nginx even in peak time without any loss of client request?
>  

Depends on your peak. In my experience, there is a slight bump in CPU/memory usage, but nothing alarming.

I see no reason to try to modify nginx to do things that are handled via chef/puppet/cfengine/rsync/etc

--Brian