[erlang-questions] Force re-resolve of DNS

[Felix Gallo]

I responded to Roberto privately about this at a bit more length, but in
summary: my experiences with a large client attempting to use ELB to
elastically balance load were a continuous slow motion clown car train
wreck, and truly any solution is better; but in particular, haproxy is very
stable under load, is radically more configurable than ELB, radically more
informative, and you don't have to open a ticket with haproxy in order for
it to pretend to work properly.

F.

On Wed, Feb 25, 2015 at 7:56 AM, Fred Hebert <mononcqc@REDACTED> wrote:

> The ELB *will* need prewarming, otherwise, only a long sustained period
> of activity will force it to auto-scale up. I'm not sure what the exact
> time duration is, but it's far from instantaneous. ELBs can auto-scale to
> dozens of nodes per AZ but it's usually easier to just try and open a
> support ticket, ask for prewarming along with the load (or concurrent
> connections) you expect to need to handle, and their team will help scale
> it up.
>
> On Wed, Feb 25, 2015 at 10:31 AM, Roberto Ostinelli <roberto@REDACTED>
> wrote:
>
>> Thank you Geoff,
>> I'm actually seeing errors way before the 10 minutes.
>>
>> To put it in perspective: without ELB I can connect 180,000 long-term
>> connections in 1 minute.
>> With ELB, I get up to 7,000.
>>
>> There's the whole "pre-warming" thing so I think this might be related:
>> though I've been bashing it repeatedly and it really doesn't change
>> anything.
>> So I'm trying to isolate why this isn't working as expected behind an ELB.
>>
>> Any thought from anyone who has used ELB in their life? Better if
>> Erlang-related obviously, this started as an Erlang question after all ;)
>>
>> Best,
>> r.
>>
>> On Tue, Feb 24, 2015 at 8:00 PM, Geoff Cant <nem@REDACTED> wrote:
>>
>>> Looks like {cache_size, 0}. might be an option too.
>>>
>>> That said, ELBs don't change their IPs all that often. It takes ~10mins
>>> for scale events to happen (increase in requests before the ELB adds more
>>> nodes), so I wouldn't worry too much about getting dns results to expire
>>> every minute. I think it's more important that after resolving, if you
>>> connect and get some kind of error (connection refused, or an invalid ssl
>>> cert, or some other response that shouldn't be possible from your ELB) that
>>> your client re-resolves DNS before reconnecting. (i.e. the failure you're
>>> protecting against is a stale DNS result that's leading you to someone
>>> else's ELB)
>>>
>>> Cheers,
>>> -G
>>>
>>> > On 2015-02-24, at 08:26 , Roberto Ostinelli <roberto@REDACTED>
>>> wrote:
>>> >
>>> > I'm considering using the {cache_refresh, Time}. of inet_cfg:
>>> > http://www.erlang.org/doc/apps/erts/inet_cfg.html
>>> >
>>> > Wouldn't this be a valid option?
>>> >
>>> > Best,
>>> > r.
>>> >
>>> > On Tue, Feb 24, 2015 at 4:52 PM, Roberto Ostinelli <
>>> roberto@REDACTED> wrote:
>>> > Dear List,
>>> > I'm currently testing a system behind Amazon's ELB.
>>> >
>>> > From their documentation:
>>> >
>>> > "If clients do not re-resolve the DNS at least once per minute, then
>>> the new resources Elastic Load Balancing adds to DNS will not be used by
>>> clients. This can mean that clients continue to overwhelm a small portion
>>> of the allocated Elastic Load Balancing resources, while overall Elastic
>>> Load Balancing is not being heavily utilized".
>>> >
>>> > I therefore need to ensure my clients re-resolve the DNS every minute
>>> or so. Is there a way to do so? I couldn't find anything in inet_res.
>>> >
>>> > Thank you,
>>> > r.
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150225/cb21a50e/attachment.htm>