The following metrics illustrate 'best case' performance achieved with v 1.5.68, the times listed are total processing time as shown by JEMH audit drill down.
Ubuntu 13_10 x64_64, virtualised on XenServer 6.1
CPU | 6 physical core i7-3930K @ 3.2GHz |
---|---|
Memory | 3GB |
Disk | SSD |
Database | local Postgres |
Protocol | 1MB | 2MB | 4MB | 8MB | 16MB | 24MB |
---|---|---|---|---|---|---|
POP | 4901mS | 8892mS | 14922mS | 34576mS | 62429ms | |
In the 16MB case the following key timestamps were in the log
Timestamp | Duration | Event |
---|---|---|
20:06:40,806 | 0 | Message Received |
20:06:54,341 | 13.5S | Audit Event written |
20:07:42,508 | 48S | Get Body Content, ready to start processing |
20:07:43,323 | 0.8S | All processing |
The clock here started when the message arrived, therefore, transport related delays were not included. The 0 point is when JEMH has been invoked by JIRA.
In order to do awesome things, JEMH serializes the email on receipt as part of creating an audit event. This action rebuilds a structured encoded TEXT document based on the object form email. It takes a while because its converting a 16MB binary file to 7bit encoded text.
In order to locate all manner of non-standard content like inline images that can be embedded within the 'directory like' structure of MIME/Multipart messages, JEMH scans all parts in turn.
TODO: More profiling is required to see what is the chief bottleneck in this case.
The core JEMH processing is pretty quick.