$binary_server_addr

[Igor Sysoev]

Performance improvement will be negligible, you will not see it in any benchmark.

-- 
Igor Sysoev
http://nginx.com

On Mar 13, 2014, at 13:58 , SplitIce wrote:

> Thats an interesting figure, certainly worthy of consideration. I am only interested in performance savings, the memory used is negligible as this particular limit takes the brunt of quite a few attacks (insecure Wordpress blogs are quickly becoming the bane of my existence).
> 
> I am not yet sure if there is room for gains here yet, was mainly curious if thought had been placed in this area (e.g existing patches) for testing prior to a thorough investigation.
> 
> Thanks,
> Mathew
> 
> 
> On Thu, Mar 13, 2014 at 8:08 PM, Igor Sysoev <igor at sysoev.ru> wrote:
> On Mar 13, 2014, at 12:43 , SplitIce wrote:
> 
>> I guess our configuration is a but of an edge case pretty much every server serves at-least one /24 (with the intention to raise this to /22 eventually).
> 
> /22, that is, 1024 server addresses. You will save 32K.
> 
> 
> -- 
> Igor Sysoev
> http://nginx.com
> 
>> Anyway thanks for the answer, I am going to go investigate what would be involved in developing a patch for this feature and if it would provide a performance increase in our use case.
>> 
>> 
>> On Thu, Mar 13, 2014 at 7:10 PM, Igor Sysoev <igor at sysoev.ru> wrote:
>> On Mar 13, 2014, at 11:09 , SplitIce wrote:
>> 
>>> Has anyone put any thought into the possibility of a $binary_server_addr variable?
>>> 
>>> Sometimes its quite useful to limit certain events by server_addr instead of the client address (e.g to limit requests made by certain UA's or other events).
>> 
>> You can use $server_addr. The binary form of $remote_addr saves memory since there is a lot of remote addresses.
>> The number of server addresses is much less so there is no sense to introduce another variable.
>> 
>> 
>> -- 
>> Igor Sysoev
>> http://nginx.com
>> 
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>> 
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140313/2b4f471d/attachment-0001.html>