[ https://issues.apache.org/jira/browse/JAMES-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17115825#comment-17115825 ]
Benoit Tellier commented on JAMES-3191: --------------------------------------- > Did you run a profiler or use glowroot APM to have some insights on where the > time is spent exactly ? Well, I used the glowroot APM but observation in rabbitMQ admin api shows messages are not consumed fast enough and queues are growing, and Grafana boards also support this analysis. I posted all relevant details in a (private) Linagora operational ticket. > I have serious doubt that raising channel number from 3 to 10 will change > latency from several minutes to some milliseconds > 1. How did you discovered it was related to the channel number? That's a blind proposition that of course need to be fact checked. (I have no real better idea to be honnest) > Why do we need RabbitMQ for a SELECT? Easy. Because: - 1. You need propagating IMAP unsolicitated notifications, that happens upon changes triggered by another protocol session - 2. Maintain the IMAP MSN <-> UID mapping So SelectedMailboxImpl is a mailbox that can be registered to get updates for that given mailbox. > Maybe it is not the channel problem, but the lock time, in this case, we > might do more than just sending a message over RabbitMQ, and we should > prepare the message, then request the channel. That could be related to the change removing the ".block() call" in ReactorRabbitMQChannelPool::borrow(). 4d0da67 `JAMES-2774 Avoid nested block in ReactorRabbitMQChannelPool` is IMO a suspect... > Key registration is slow > ------------------------ > > Key: JAMES-3191 > URL: https://issues.apache.org/jira/browse/JAMES-3191 > Project: James Server > Issue Type: Improvement > Components: eventbus, IMAPServer > Affects Versions: master > Reporter: Benoit Tellier > Priority: Major > Labels: perf > > We noticed that on *master* SELECT IMAP command is significatively slow > (several minutes) on top of the distributed profile. (See attached > instrumentation average time and percentiles) > A quick performance review links this to listener registration (by key). > A code review leads to: > - The low channel number (3) maybe this count can be safely raised to a > higher number? Like 10? Maybe even configurable? > - EventBus::Register operation is handling IO but is synchronous. The > reactor scheduler backing it up is unspecifed (thus is likely the parrallel > one). We should let the caller specify the scheduler he whishes to run. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org