Bug 54699 - Improve performance of UDM REST API
Improve performance of UDM REST API
Status: NEW
Product: UCS
Classification: Unclassified
Component: UDM - REST API
UCS 5.0
Other Linux
: P5 normal (vote)
: ---
Assigned To: UMC maintainers
UMC maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-04-28 19:22 CEST by Florian Best
Modified: 2023-06-20 20:43 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Large environments, UCS Performance
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2022-04-28 19:22:11 CEST
The speed of the UDM REST API should be improved.

Michael gave some ideas:

Better LDAP Connection Handling:
- [ ] Local connections of the UDM always via LDAPI:
  - saves TCP-3-way-handshake
  - saves TLS negotiation
  - larger LDAP PDUs possible
- [ ] LDAPS instead of LDAP with StartTLS ext.op.
- [ ] if necessary use TLSv1.3 for remote accesses
- [x] persistent LDAP connection per UDM process
- [ ] use proxy auth instead of individual binds

MDB tuning if it's really the write accesses
- [ ] various MDB parameters
- [ ] Avoid over-indexing

- [ ] More caching of metadata in the UDM. With this, the UDM apparently spends several round trips per UDM request.
Comment 1 Daniel Tröder univentionstaff 2022-04-29 08:41:49 CEST
Please make the LDAP connection target configurable → Bug 54623.
In a high-load environment that enables load balancing for read operations (at the expense of issues with replication latency).
Comment 2 Daniel Tröder univentionstaff 2022-04-29 08:45:08 CEST
A request parameter could be to not open() objects.
For users/user objects that saves a lot of time, when only simple, non-extended attributes are of interest to the client (like reading the firstname + lastname of a user).
That should be the default for search operations. (Is it already?)
Comment 3 Florian Best univentionstaff 2022-10-25 13:52:59 CEST
(In reply to Daniel Tröder from comment #2)
> A request parameter could be to not open() objects.
> For users/user objects that saves a lot of time, when only simple,
> non-extended attributes are of interest to the client (like reading the
> firstname + lastname of a user).
This exists already since the beginning via ?properties=firstname&properties=username&properties=lastname.
But e.g. ?properties=groups does not work because when properties are specified no open() call is done.
open() has nothing to do with extended attributes. All extended attributes are available without open().
open() is only for hooks and resolving of external references.

> That should be the default for search operations. (Is it already?)
No it's not and we shouldn't change the default.