This PR consists of 3 main changes to address a performance bottleneck in the Amplitude client:
(1) Pass sendThreadPool to sendEvents
(2) Allow users to set sendThreadPool and retryThreadPool
(3) Increase default sendThreadPool fixed size from 20 -> 40
During performance testing it was found Amplitude client would bottleneck on the default ForkJoinPool invoked indirectly via CompletableFuture.supplyAsync(runnable) which is not ideal for I/O:
Many threads were parked due to Amplitude during testing and increasing the fork join pool resolved the issue.
Also increasing the default pool size from 20->40 (i.e double) since the sendEventsWithRetry -> sendEvents path now invokes sendThreadPool.execute twice due to the shared threadpool.
Checklist
[x] Does your PR title have the correct title format?
Summary
Issue https://github.com/amplitude/Amplitude-Java/issues/108
This PR consists of 3 main changes to address a performance bottleneck in the Amplitude client: (1) Pass
sendThreadPooltosendEvents(2) Allow users to setsendThreadPoolandretryThreadPool(3) Increase defaultsendThreadPoolfixed size from 20 -> 40During performance testing it was found Amplitude client would bottleneck on the default ForkJoinPool invoked indirectly via
CompletableFuture.supplyAsync(runnable)which is not ideal for I/O:Many threads were parked due to Amplitude during testing and increasing the fork join pool resolved the issue.
Also increasing the default pool size from 20->40 (i.e double) since the
sendEventsWithRetry -> sendEventspath now invokessendThreadPool.executetwice due to the shared threadpool.Checklist