$binary_server_addr

[SplitIce]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20140313/1d213034/attachment.html>