Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: Fixing Kea package (Francis Dupont)
2. Re: KEA performance and hook framework (Francis Dupont)
3. Re: KEA performance and hook framework (Angelo Failla)
4. Re: KEA performance and hook framework (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Mar 2016 13:25:52 +0000
From: Francis Dupont <[email protected]>
To: Zdenek Dohnal <[email protected]>
Cc: [email protected]
Subject: Re: [kea-dev] Fixing Kea package
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have two concerns about the patch:
- for coroutine it is far simpler (and safer) to switch to the boost
coroutine header. Note there is already a ticket about this as this fixes
too WIN32 portability issues.
- the make_pair fix is correct but is not compatible with not C++11
compilers. So it should be fine to find a fully compatible fix.
(all other C++11 issues were fixed but obviously this PostgreSQL
one was missed: please open a ticket for it).
Another note: Botan exists in a C++11 version (1.11.x) but with some
major API changes...
Regards
Francis Dupont <[email protected]>
PS: Fedora 24 is not yet available (alpha is scheduled for 20160322,
beta for 20160503 and final 20160607 according to the current schedule).
But as a Fedora user you can be sure I'll install a VM and check whether
our softwares (bind9, ISC DHCP and Kea) build correctly. So remaining
issues will be fixed and documented at this time.
------------------------------
Message: 2
Date: Mon, 14 Mar 2016 13:57:00 +0000
From: Francis Dupont <[email protected]>
To: Angelo Failla <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] KEA performance and hook framework
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
> It seems KEA is a single threaded UDP server using blocking sockets
=> it uses not-blocking sockets but is single threaded so it doesn't
change something for your problem.
If I understand well this problem you have a high latency backend
called via hooks. I suppose your backend supports many simultaneous
calls so IMHO you need to split the load over several kea servers
and rely on the backend for the coherency (BTW it will be better than
a multi-threaded server according to my experience of parallel and
multi-thread applications). DHCP is a stateless protocol so any
load balancer could be able to do the job. And Kea has a -p port
command line option.
To summary I assume your backend has enough throuput and suggest
a multi-process (eventually a multi-machine) service, so the performance
limit will be the backend one.
Regards
Francis Dupont <[email protected]>
------------------------------
Message: 3
Date: Mon, 14 Mar 2016 15:49:08 +0000
From: Angelo Failla <[email protected]>
To: Francis Dupont <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] KEA performance and hook framework
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 3/14/16, 1:57 PM, "Francis Dupont" <[email protected]> wrote:
>> It seems KEA is a single threaded UDP server using blocking sockets
>
>=> it uses not-blocking sockets but is single threaded so it doesn't
>change something for your problem.
Yep.
>If I understand well this problem you have a high latency backend
>called via hooks.
Correct. Well even if it was 10ms it?s kinda sad that a C++ application would
only serve 100 RPS in that case and basically not make use of cores in the box
or some concurrency technics like other modern software are doing.
Anyway, we are going to implement a workaround on our side.
>I suppose your backend supports many simultaneous calls
It does.
>so IMHO you need to split the load over several kea servers
>and rely on the backend for the coherency
We do spread the load across multiple servers but it doesn?t help much in
situations like the one in the incident.
>(BTW it will be better than
>a multi-threaded server according to my experience of parallel and
>multi-thread applications).
I think it?s still worth it investing time in going that way.
We have a work around
> DHCP is a stateless protocol so any
>load balancer could be able to do the job. And Kea has a -p port
>command line option.
Totally unrelated to this thread but I wanted to ask if you guys know
dhcprelay(8)?
If so I have a question: I see it takes a list of servers and it relays traffic
to them. Does it balance traffic evenly amongst the upstream servers? If so:
how?
------------------------------
Message: 4
Date: Mon, 14 Mar 2016 16:16:12 +0000
From: Francis Dupont <[email protected]>
To: Angelo Failla <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] KEA performance and hook framework
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
As far as I know all available DHCP relays just relay DHCP traffic and
none split it using a smart algo (in fact most keep no state and
duplicate it if they are configured with several server addresses).
Regards
Francis Dupont <[email protected]>
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 24, Issue 5
**************************************
