Eugene,
LOL It is never what one thinks it might be ... I've been able to reproduce
your results, and the problems you encountered were in none of the places I
had expected. I didn't get a single one right. :-)
At the moment, it appears that the biggest part of the delay comes from:
AbstractJdbcUsersRepository.getUserByName(String, boolean)
For 2500 users, it takes ~30ms per call, two calls per call to an existing
mailbox. The first time that a mailbox is used, there is a 40ms in overhead
setting it up. Actually, those figures are for a system that has already
been jitted. Earlier on those figures can be 2x - 3x higher. Those figures
total to about 100ms per message, matching your 10 messages per second
value. When I changed from 2500 users to 5000, the cost of getUserByName
went to ~50ms. When I went to 10,000 users, the cost of getUserByName went
to ~80ms, also tracking your experience. So that is something to look at,
since the code within James should not be sensitive to the size of the
repository.
AbstractJdbcUsersRepository.getUserByName is too slow considering the
frequency with which it is called. A user cache based upon a ReferenceMap
might help. The drawback is that changes made directly via SQL would not be
picked up until the record is re-read, either due to gc or restart.
The memory problem doesn't appear to be what I had expected, either. I'm
running the test again with -Xrunhprof enabled, and will look in the morning
to see what shows up.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
