implement DNS ttl about connectable HOT 11 CLOSED

Thinking about it the consul service cache is much more like a ConfigStore in that it watches a HTTP endpoint.

BACKEND_8080=cache://127.0.0.1:8500/httptest

Could be a way to denote it where httptest is the name of the service in this case.

from connectable.

Do you have numbers that compare the time to set up connections using local DNS vs the other in-memory mechanisms? My guess is that even though one sounds much faster, the actual difference is not that big, and not worth the complexity even in high connection scenarios. Can you produce a test or Go benchmark or something to see if this is worth exploring?

from connectable.

You are right - this needs some numbers and I have premature optimization rattling in my head also.

I've put together a script to run some ab benchmarks over 3 types of connection. Its been a useful test generally of ambassador doing its thing!

The 3 types:

• direct - bypassing ambassadord
• dns - using the SRV DNS lookups
• kv using the consul key/value cache

The summary (running with ab settings of -n 200 -c 20):

direct:

    Requests per second:    1412.08 [#/sec] (mean)
    Time per request:       14.163 [ms] (mean)
    Time per request:       0.708 [ms] (mean, across all concurrent requests)

kv:

    Requests per second:    549.93 [#/sec] (mean)
    Time per request:       36.368 [ms] (mean)
    Time per request:       1.818 [ms] (mean, across all concurrent requests)

dns:

    Requests per second:    269.91 [#/sec] (mean)
    Time per request:       74.098 [ms] (mean)
    Time per request:       3.705 [ms] (mean, across all concurrent requests)

I'm not sure which of these 2 scenarios apply:

a) dns is twice as slow as kv
b) dns is only 2 ms slower than kv

If a) I can make a PR with this example (not tested)
If b) then its been a good day messing with benchmarks and generally testing ambassadord.

So, its totally up to you if this is worthwhile - it's useful to get perspective on what is not important so sorry if this turns out to be just noise :)

from connectable.

No, this is very educational. Thank you for looking into it. I knew
establishing connections would be slower through ambassadord, but now we
know by how much. Would you mind doing another test using some kind of
other reverse proxy (like haproxy or nginx)?

I'm thinking if we were to implement caching, it would just be baking into
the DNS backend and use the TTL of the record, perhaps with an optional
override argument/parameter. That seems like the simplest way to achieve
caching. Bang for buck it terms of desire/complexity.

For now, let's keep gathering info and thinking about it.

On Thu, Sep 11, 2014 at 4:00 PM, Kai Davenport [email protected]
wrote:

You are right - this needs some numbers and I have premature optimization
rattling in my head also.

I've put together a script
https://github.com/binocarlos/ambassadord-speedtest to run some ab
benchmarks over 3 types of connection. Its been a useful test generally of
ambassador doing its thing!

The 3 types:

• direct - bypassing ambassadord
• dns - using the SRV DNS lookups
• kv using the consul key/value cache

The summary (running with ab settings of -n 200 -c 20):

direct:

Requests per second:    1412.08 [#/sec] (mean)
Time per request:       14.163 [ms] (mean)
Time per request:       0.708 [ms] (mean, across all concurrent requests)

kv:

Requests per second:    549.93 [#/sec] (mean)
Time per request:       36.368 [ms] (mean)
Time per request:       1.818 [ms] (mean, across all concurrent requests)

dns:

Requests per second:    269.91 [#/sec] (mean)
Time per request:       74.098 [ms] (mean)
Time per request:       3.705 [ms] (mean, across all concurrent requests)

I'm not sure which of these 2 scenarios apply:

a) dns is twice as slow as kv
b) dns is only 2 ms slower than kv

If a) I can make a PR with this example
https://github.com/binocarlos/ambassadord/blob/master/consulcache.go
(not tested)
If b) then its been a good day messing with benchmarks and generally
testing ambassadord.

So, its totally up to you if this is worthwhile - it's useful to get
perspective on what is not important so sorry if this turns out to be just
noise :)

—
Reply to this email directly or view it on GitHub
#7 (comment).

Jeff Lindsay
http://progrium.com

from connectable.

Yes the TTL option is a much better idea - a custom scheme felt messy.

I've added nginx and haproxy to the benchmarks - here are the updated results:

direct:

    Requests per second:    1345.86 [#/sec] (mean)
    Time per request:       14.860 [ms] (mean)
    Time per request:       0.743 [ms] (mean, across all concurrent requests)

haproxy:

    Requests per second:    811.37 [#/sec] (mean)
    Time per request:       24.650 [ms] (mean)
    Time per request:       1.232 [ms] (mean, across all concurrent requests)

nginx:

    Requests per second:    754.53 [#/sec] (mean)
    Time per request:       26.507 [ms] (mean)
    Time per request:       1.325 [ms] (mean, across all concurrent requests)

kv:

    Requests per second:    606.32 [#/sec] (mean)
    Time per request:       32.986 [ms] (mean)
    Time per request:       1.649 [ms] (mean, across all concurrent requests)

dns:

    Requests per second:    263.57 [#/sec] (mean)
    Time per request:       75.881 [ms] (mean)
    Time per request:       3.794 [ms] (mean, across all concurrent requests)

Which is encouraging generally in terms of ambassadord performing well :)

from connectable.

Yep, good to know we can at least come within the same ballpark as
haproxy/nginx without much optimization. Should we retitle this issue to
implement DNS ttl?

On Thu, Sep 11, 2014 at 8:13 PM, Kai Davenport [email protected]
wrote:

Yes the TTL option is a much better idea - a custom scheme felt messy.

I've added nginx and haproxy to the benchmarks - here are the updated
results:

direct:

Requests per second:    1345.86 [#/sec] (mean)
Time per request:       14.860 [ms] (mean)
Time per request:       0.743 [ms] (mean, across all concurrent requests)

haproxy:

Requests per second:    811.37 [#/sec] (mean)
Time per request:       24.650 [ms] (mean)
Time per request:       1.232 [ms] (mean, across all concurrent requests)

nginx:

Requests per second:    754.53 [#/sec] (mean)
Time per request:       26.507 [ms] (mean)
Time per request:       1.325 [ms] (mean, across all concurrent requests)

kv:

Requests per second:    606.32 [#/sec] (mean)
Time per request:       32.986 [ms] (mean)
Time per request:       1.649 [ms] (mean, across all concurrent requests)

dns:

Requests per second:    263.57 [#/sec] (mean)
Time per request:       75.881 [ms] (mean)
Time per request:       3.794 [ms] (mean, across all concurrent requests)

Which is encouraging generally in terms of ambassadord performing well :)

—
Reply to this email directly or view it on GitHub
#7 (comment).

Jeff Lindsay
http://progrium.com

from connectable.

Renamed - I never knew you can rename issues - my thing I learned today already...

from connectable.

Getting back to this project and this issue soon. ;)

from connectable.

readme for new version of ambassadord coming: https://github.com/progrium/ambassadord/tree/connectable#readme

from connectable.

nice! I like the new name :-)

from connectable.

The new lookup package now that it's evolved into gliderlabs/connectable does perform 1s caching/TTL. It's not configurable yet, but should be.

from connectable.