On 14 Jun 2011, at 14:28, Murray S. Kucherawy wrote:
> On Tue, 14 Jun 2011, Nigel Horne wrote:
>> Mark's example hardly uses the Mail::OpenDKIM module, by which I mean the data goes straight through the Mail::OpenDKIM layer with little processing; most of the time he measures is spent within the OpenDKIM library. It is therefore better for one of the OpenDKIM library maintainers to talk about benchmark issues than me.
>>
>> [...]
>
> Certainly calling any of the interfaces numerous times where a single call to dkim_chunk() is sufficient will degrade performance.
Indeed. I have used Devel::NYTProf on the submitted test program to verify that the bulk of the time spent is in the C library (dkim_chunk and dkim_eom), when the program at
http://marc.info/?l=amavis-user&m=130773268712771&w=2 is run. I suggest that the author try reducing the number of calls to Mail::OpenDK
IM::Signer->PRINT, perhaps by saving the area in a temporary buffer. It would be interesting to see what where to be the results of the comparison of Perl against C if the buffer size (16K) where to be far larger.
>
> The last time I did any profiling of the library in terms of performance, most of the processing time fell on the openssl hashing and encryption functions. I'll have to find some time (or help) to repeat that work to see if something's crept in that slows us down. But if that's still the case then I'm not sure what we could do to improve it.
If there's anything I can do to help, please feel free to ask.
-Nigel
>
> The other data feed interface, using dkim_header(), dkim_eoh(), dkim_body() and dkim_eom(), is slower but is meant to mimic the milter API directly since that was the origin of the work. It's likely not as performant.
>
> Another drop happens when you use relaxed vs. simple, since there's an extra layer of text processing that has to occur when using that canonicalization. Further penalty occurs if any features are enabled that cause I/O to occur (i.e., writing the canonicalized form to a temporary file).
>
> Anyway, I'll try to make some time for profiling work in the near future.
>
> -MSK
Received on Thu Jun 16 2011 - 14:43:18 PST