[JAVA-3118] Provide an option to use pooled NIO direct buffers to minimise impact on GC Created: 09/Dec/18 Updated: 14/Sep/23 |
|
| Status: | Backlog |
| Project: | Java Driver |
| Component/s: | Performance |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Farzad Pezeshkpour | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | performance | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
When the driver is being used with GridFS to serve binary data ('files) over HTTP, the ByteBuffers that are returned are on-heap. Servers such as vertx are capable of directly serving ByteBuffers, using Netty's ByteBuf abstraction. By using on-heap buffers, we place undue pressure on the JVM GC, as the concurrent load on the service (that's using the driver) increases. Please can we have an option at least to direct the driver to use pooled direct buffers. Thanks. |
| Comments |
| Comment by Jeffrey Yemin [ 10/Dec/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
For #2: yes, please open a separate issue. Thanks, | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Farzad Pezeshkpour [ 10/Dec/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Jeff, Specifically, we use:
We implement the AsyncOutputStream to wrap a vertx RoutingContext as follows (apologies, it's in Kotlin):
Two points: cheers | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 10/Dec/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hi dazraf, there are a number of places where the driver uses byte buffers, some of them internal to the driver. Can you tell me where specifically that you think they are needed for your use case? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Farzad Pezeshkpour [ 09/Dec/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks Jeff, much appreciated. If it helps with prioritisation, the reason why we use the async / reactive drivers is for performance under concurrent load. Something that would be of value to many I hope. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 09/Dec/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Moved to JAVA, since that's where this would have to start. If we do this we'll make sure to expose it in Reactive/Scala drivers. |