... | ... | @@ -34,7 +34,7 @@ Master issue: https://gitlab.isc.org/isc-projects/kea/issues/875 |
|
|
|
|
|
As of 1.6, we have iterative allocator, which tries leases one by one. It's very fast if the pool utilization is small and there are relatively many addresses available. However, it slows down dramatically when most addresses are already allocated. For example, if there's a /24 subnet and we have 250 addresses allocated, finding the next free may take up to 250 queries. This can be extremely slow.
|
|
|
|
|
|
This idea alleviates the problem by calling a stored procedure once, the procedure finds the lease and returns it. This should be much faster as it requires just one call and the processing is done locally on MySQL/pgsql
|
|
|
This idea alleviates the problem by calling a stored procedure once, the procedure finds the lease and returns it. This should be much faster as it requires just one call and the processing is done locally on MySQL/pgsql
|
|
|
|
|
|
A potential SQL query that might optimise this given e.g. an `addr int(4) unsigned` field that holds IPv4 addresses in integer format is this:
|
|
|
|
... | ... | @@ -78,7 +78,7 @@ One trivial improvement here is for case of 2 instances: make the other instance |
|
|
|
|
|
Master issue: https://gitlab.isc.org/isc-projects/kea/issues/877
|
|
|
|
|
|
Permit the servers to do an actual allocation on DISCOVER/SOLICIT (i.e. fake-allocation flag = NO) - ISC DHCP assigns a shortened life-time (120 seconds) to leases when they are first offered. This keeps them from being offered to any other client. At first blush, it might seem like this would would slow down our response rate, but then again it might actually make us faster overall. Requests end up being treated more like renewing/returning clients. It would also make it far easier for multiple Kea instances (or even threads), to share the same address space.
|
|
|
Permit the servers to do an actual allocation on DISCOVER/SOLICIT (i.e. fake-allocation flag = NO) - ISC DHCP assigns a shortened life-time (120 seconds) to leases when they are first offered. This keeps them from being offered to any other client. At first blush, it might seem like this would would slow down our response rate, but then again it might actually make us faster overall. Requests end up being treated more like renewing/returning clients. It would also make it far easier for multiple Kea instances (or even threads), to share the same address space.
|
|
|
|
|
|
### Adapt host cache to work with MySQL and PgSQL
|
|
|
|
... | ... | @@ -120,11 +120,11 @@ Master issue: https://gitlab.isc.org/isc-projects/kea/issues/878 |
|
|
|
|
|
* Restructure MySQL backend to have one method that runs all queries. That way we could run some logging there.
|
|
|
|
|
|
When dealing with performance issues, such as recently reported by a customer, who experienced 14 leases/sec with mysql, we don't have any effective means to pinpoint the problem. In principle, the DB interaction is split into two phases: host reservation lookups and lease lookups. It would be useful to have easy to use statistics that would let us figure out what area is causing problems. Things like:
|
|
|
When dealing with performance issues, such as recently reported by a customer, who experienced 14 leases/sec with mysql, we don't have any effective means to pinpoint the problem. In principle, the DB interaction is split into two phases: host reservation lookups and lease lookups. It would be useful to have easy to use statistics that would let us figure out what area is causing problems. Things like:
|
|
|
|
|
|
- looking for reservations took X us,
|
|
|
- looking for leases took Y us.
|
|
|
- Z queries per packet were conducted.
|
|
|
- looking for reservations took X us,
|
|
|
- looking for leases took Y us.
|
|
|
- Z queries per packet were conducted.
|
|
|
- W total queries performed by backend, average response time was A.
|
|
|
- possibly stats by query type (getLease4byHWAddr, getLease4ByAddr, etc.)
|
|
|
- possibly query by SQL type (A number of SELECTs, B number of INSERTs, C number of DELETEs) |