franz1981 commented on issue #2582: Revert "ARTEMIS-2240 ActiveMQThreadPoolExecutor should use LinkedTransferQueue" URL: https://github.com/apache/activemq-artemis/pull/2582#issuecomment-472514883 Nudge nudge @michaelandrepearce I have performed some single-producer single-consumer tests with 100 bytes messages and no persistence (core protocol) and I have found several interesting things: 1. the new thread pool theoretically should scale way better then the original: there are no more locks associated to the tail/head of the linked blocking task queue 2. the new thread pool try to reuse dormient and existing threads, but it means that with few producers/consumers then avaialble threads the cost to wakeup them will add a huge latency hit (the percentiles show it for small burst) :( This is a regression if compared with other commits: - 7dfa0fe7f43012f2f4ee5715049878019fe0bef7 - 71d549434591715c1f02359000e424e4d7dfbfda - https://github.com/apache/activemq-artemis/tree/2.6.4 I suggest anyone that has enough cores to perform tests on these commits and check the latencies/throughput, because although on my box the throughput is not that different, the performance regression is evident on latency side. Shame on me that I have trusted that a lock-free q would have performed better in any case: the cost to scale better is just too high and I think is better to work after the release to improve the thread pool.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
