Being useful make me really happy. Yeah for me to discover that logging can pretty big problem - in default info logging and not asyc on very high messages per second dramatically lower throughput rate and even can make spikes. Caching working good yeah. I dont sure how it exactly was done cuz there was so much decompilation with, but i find that so much flexibility there i cant find in others email servers solutions. In extreme high msg/sec zgc shows better (lower latency). Yeah silo doing one man, but as i see doing good. I dont mind :) just dont know what exactly do.
вт, 22 сент. 2026 г., 19:44 Benoit TELLIER <[email protected]>: > Hi Terskov > > Thanks for this really cool job, it was a delight to review it on github. > > I went through the readme of https://github.com/prosgarz35/james-fast and > I think there is a couple of very interesting changes that would deserve to > land in Apache James. Out of my head: > - logback.xml configuration improvment (async, neverBlock) > - r2dbc configuration improvment (pool warmup, prepared statement cache > size > > Regarding the cache: > - domains already should have one: > https://james.staged.apache.org/james-project/3.10.0/servers/postgres/configure/domainlist.html > read.cache.* > if it do not work well enough contribution are welcomed > - we could add a cache for PGUsersDAO. My main concern is cache > invalidation. This kind of optimization can IMO land in James code base but > should be turned of by default. > > Regarding Java options, at linagora we operate with G1GC and an > aggressively low pause time objective. We keep clear of ZGC that we > perceive as designed for larger heaps, and the GC is anyway not the > limiting factor in most of our benches (more oriented on IMAP reads I > confess). > > Thanks for the S3 Silo discovery. That is nice to see alternatives for > MinIO, though it looks like a single maintainer project... > > Alast, Artemis is a significant code change: don't you mind signing > formally an Individual Contributor License Agreement (ICLA) ? > https://www.apache.org/licenses/contributor-agreements.html > This would be needed for intelectual property reasons. > -- > > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM. > Product owner for Twake-Mail product. > Chairman of the Apache James project. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > On Sep 22, 2026 5:40 AM, from Quan Tran Hong <[email protected]>Hi > Terskov, > > Thank you very much for triaging James and optimizing its performance! > > > Offloading blobs to S3 Silo (a MinIO fork). > > Yes. Relying on Postgres for blobs (especially big blobs) is not as good as > proper object storage. > We developed the Postgres app so it could work either in standalone mode > (for people who just need simplicity in deployment), or in a distributed > mode (can work with RabbitMQ, OpenSearch, S3 object storage) for better > performance and scalability. > > > I’ve shared the code and documentation in the following repositories: > > Your benchmark and the way you optimized James' Postgres performance are > very interesting! > Is it possible to record this somehow more formally, to share the > experience with the James community better? Either in the james-project > Antora documentation or an article/post? > > Thank you a lot again for using James! > Regards, > Quan > > > On Tue, Sep 22, 2026 at 10:29 AM Терсков Илья Андреевич < > [email protected]> > wrote: > > > Hi everyone, > > > > I've been closely following the project's development and saw the recent > > update from Benoit Tellier, which improved performance and reduced > > latencies in the postgres-app version by about 40%. Great work, but in > > my testing, the throughput still hit a ceiling at around 400 messages > > per second. Furthermore, running basic James entirely on PostgreSQL 17 > > resulted in only around 25–30 messages per second. > > > > Through some architectural adjustments, I managed to push throughput > > past 2,000 messages per second. The key changes: > > 1. Migrating to Apache ActiveMQ Artemis. In my experience, Artemis was > > the main differentiator thanks to its asynchronous architecture, whereas > > classic ActiveMQ seemed capped at around 400 msg/s even with tuning. > > 2. Offloading blobs to S3 Silo (a MinIO fork). > > 3. Several minor tweaks and optimizations across the setup. > > > > All tests were run on the following hardware: > > • CPU: Intel Core i5-9500 > > • RAM: 24 GB DDR4 > > • Storage: Samsung 860 EVO SSD > > > > I’ve shared the code and documentation in the following repositories: > > • Integration with Artemis: > > github.com/prosgarz35/james-project-fast > > • Ready-to-test standalone bundle (built for Windows): > > github.com/prosgarz35/james-fast > > > > I'm really glad to see James actively evolving and hope these findings > > and repositories prove helpful to the team. Any feedback is welcome! > > > > С уважением, > > Руководитель ИТ > > ООО «КПС-Технологии» > > Терсков Илья Андреевич > > Моб.: +7 (996) 415-16-29 <+7%20996%20415-16-29> > > E-mail:[email protected] > > > > УВЕДОМЛЕНИЕ О КОНФИДЕНЦИАЛЬНОСТИ: > > Это электронное сообщение и любые документы, приложенные к нему, > > содержат > > конфиденциальную информацию. Настоящим уведомляем Вас, что если это > > сообщение > > не предназначено Вам, использование, копирование и распространение > > информации, > > содержащейся в настоящем сообщении, а также осуществление любых действий > > на > > основе этой информации строго запрещено. Если Вы получили это сообщение > > по > > ошибке, пожалуйста, сообщите об этом отправителю по электронной почте и > > удалите данное сообщение. > > > > CONFIDENTIALITY NOTICE: > > This email and any files attached to it are confidential. If you are not > > the > > intended recipient, you are notified that using, copying, distributing, > > or taking > > any action in reliance on the contents of this information is strictly > > prohibited. > > If you have received this email in error, please notify the sender and > > delete this > > message. > > >
