[OPENDJ-6956] Replace Grizzly LDAP transport with RX transport Created: 06/Feb/20  Updated: 06/Oct/20

Status: Dev in Progress
Project: OpenDJ
Component/s: core apis
Affects Version/s: 7.0.0
Fix Version/s: 7.1.0

Type: Task Priority: Blocker
Reporter: Matthew Swift Assignee: Matthew Swift
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Depends
depends on OPENDJ-6743 Implement new home grown NIO based tr... Dev in Progress
is required by OPENDJ-6174 Make X509CertificateBuilder a public ... Dev backlog
is required by OPENDJ-7193 Consider splitting out ASN.1 and Byte... Dev backlog
Epic Link: Replace Grizzly
Story Points: 5
Dev Assignee: Matthew Swift

 Description   

This issue can be closed once the following criteria have been met:

  • the LDAP SDK uses the new RX base transport
  • the Grizzly LDAP layer has been removed
  • there are no significant performance regressions in basic functionality:
    • searchrate for single entries
    • searchrate for searches returning many entries (~1000)
    • modrate
    • searchrate for single entries, reconnecting each time
    • all of the above but over SSL.

It is reasonable to expect some regressions, say around 10%, given that Grizzly was pretty mature and optimized, whereas the new RX transport is not. The priority is to get the new IO layer in and stressed in order to iron out any bugs, etc. We can optimize incrementally afterwards.



 Comments   
Comment by Matthew Swift [ 06/Oct/20 ]

RX transport update:
the feature toggle works: it is easy to switch between transports!
searchrate: AsyncRX = started at 100K/s and dropped to 75K/s, Grizzly = started at 145K/s and dropped to 125K/s

Numbers are much closer with the SyncRX transport, but it doesn't scale to many connections server side. It looks like the AsyncRX transport is using very many threads and also offloading many writes to the IO threads instead of the worker threads. This results in lots of context switches which we know heavily impacts performance from previous tuning experiences .

Generated at Sat Oct 31 01:42:35 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.