# Re: Re: signal process in nginx

**URL:** <https://www.ruby-forum.com/t/re-re-signal-process-in-nginx/226255>\
**Category:** NGINX\
**Created:** [December 21, 2011, 1:10pm UTC](https://www.ruby-forum.com/t/re-re-signal-process-in-nginx/226255 "2011-12-21T13:10:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 21, 2011, 1:10pm UTC](https://www.ruby-forum.com/t/re-re-signal-process-in-nginx/226255/1 "2011-12-21T13:10:52Z")

</div>

* * *

nginx mailing list  
removed\_email\_address@domain.invalid  
[http://mailman.nginx.org/mailman/listinfo/nginx](http://mailman.nginx.org/mailman/listinfo/nginx)

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 21, 2011, 4:04pm UTC](https://www.ruby-forum.com/t/re-re-signal-process-in-nginx/226255/2 "2011-12-21T16:04:49Z")

</div>

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