Attachment Processing Metrics
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.
OS
Ubuntu 13_10 x64_64, virtualised on XenServer 6.1
Hardware
CPU | 6 physical core i7-3930K @ 3.2GHz |
|---|---|
Memory | 3GB |
Disk | SSD |
Database | local Postgres |
Version 1.5.68
Protocol | 1MB | 2MB | 4MB | 8MB | 16MB | 24MB |
|---|---|---|---|---|---|---|
POP | 4901mS | 8892mS | 14922mS | 34576mS | 62429ms |
|
|
|
|
|
|
|
|
Example 16MB case
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 |
Events
Message Received
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.
Audit Event written
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.
Get Body Content
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.
All processing
The core JEMH processing is pretty quick.