On Tue, Nov 24, 2015 at 01:44:07AM +0100, Dennis Jacobfeuerborn wrote:
> On 23.11.2015 22:38, Willy Tarreau wrote:
> > Hi Andrew,
> >
> > On Mon, Nov 23, 2015 at 12:19:22PM -0600, Andrew Hayworth wrote:
> >> That said, the difference between one and two map lookups is
> >> negligible, so I don't think you're saving much this way and it'll
> >> make configuration harder in some ways if you keep adding IPs. I can
> >> vouch from personal experience in production that we run 2+ map
> >> lookups on every request at Braintree (hundreds of req/s) and it adds
> >> no noticeable latency. Food for thought. :)
> >
> > I agree, depending on the map size, you'll see something between 1 and 10
> > million lookups per second, it's quite cheap. I do abuse them as well and
> > I don't bother about the number of lookups. Sure if I have to match a
> > country among a few tens, I'll certainly use a variable first, but otherwise
> > I don't care.
>
> I'm going to use multiple lookups until I can upgrade to 1.6 because I
> agree that it's not going to cause any major issues in our current setup.
> It's just that when I'm looking the same value up multiple times in a
> map of about 800.000 values my coding sensibilities immediately go for
> storing the result in a variable instead.
Just FWIW in 1.5 there's a tricky alternative to variables. You can perform
a sample capture in TCP rules, and reuse this capture later :
tcp-request content capture src,map(ip-to-country) len 2
...
http-request add-header x-country %[capture.req.hdr(0)]
...
use_backend country_XXX if { capture.req.hdr(0) XXX }
It will effectively work as a variable, though this variable will be dumped
into the logs. Since it's the source address you're interested in, you can
even do that in "tcp-request connection" rules, and it will be performed
only once per connection, which is the most optimal situation. But as you
can see it's a trick and it is limited because you can't do much using HTTP
inputs for example.
Regards,
Willy
