Saturday, 6 January 2007
IMAP Performance - a Good Start
« Buni Begins | Main | Bustin' out the ANTLR-fu »I've spent some of the holiday period looking at IMAP performance and stability. I fleshed out the IMAP unit tests for the IMAP server, which highlighted a couple of bugs and has improved the stability. One aspect of our IMAP implementation is that it was coupled tightly to the folder implementation. The first step in improving the IMAP server was to introduce an API for our folder implemenation. After looking at a couple of options, the folder API uses an interface/proxy approach. The advantage of the proxy approach is that all sorts smart things can be done inside the proxy implemenation without much of an impact on the IMAP server.
Once the API was in place I got a chance to make the first performance improvement. The key issue is related to the loading of messages upon each fetch request. The initial implemenation would load all of the message meta data for each fetch request then filter out the messages that are not required. The fix was to delegate this request down the database. It now generates the EJB-QL based on the IMAP sequence set passed in from the client.
To test this I sent 500 mails to the same mailbox, then retrieved all of the messages (full message 1 by 1) via IMAP. Check out the following charts from jconsole to see the improvement.
Original implemenation.
The first portion of the line is the SMTP delivery, Second portion that jags up to ~128MB is the loading of the messages via IMAP. The time spend receiving the messages via IMAP was 263 seconds.
New Implemenation
The time spent retrieving the messages reduced to 46 seconds and the memory used never gets above 55MB.
Its a good start, and probably the most significant improvement to be made. There are a some more improvements to come, but unlikely to show them same sort of difference on a single user test. All of these changes are in CVS HEAD, IMAP is going to rock in our M7 release.
