help-gnutls
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-gnutls] Re: Performance of gnutls_record_recv(session, &c, 1)?


From: Simon Josefsson
Subject: [Help-gnutls] Re: Performance of gnutls_record_recv(session, &c, 1)?
Date: Thu, 06 Mar 2008 12:32:09 +0100
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Nikos Mavrogiannopoulos <address@hidden> writes:

> Martin Lambers wrote:
>> Hi all,
>>
>> Dimitrios Apostolou reported a large performance difference between the
>> OpenSSL and GnuTLS versions of mpop, a POP3 client, when querying the
>> status of a large POP3 mail box (>70000 messages).
>>
>> In this situation, mpop needs to read a large amount of data (size
>> listings and UIDs, but not the mails itself). This takes 1m15s with
>> GnuTLS and only about 15s with OpenSSL. The 1m15s are completely spent
>> at 100% CPU.
>>
>> Mpop uses gnutls_record_recv(session, &c, 1) for reading the data, i.e.
>> it reads the characters one at a time. It does not do any buffering
>> because the TLS library needs to do buffering internally anyway.
>> The OpenSSL variant of mpop does the equivalent: SSL_read(ssl, &c, 1).
>>
>> Can this performance difference be caused by different TLS session
>> parameters? If so, which parameters would that be? Should mpop
>> perform additional buffering and read larger chunks of data
>> with gnutls_record_recv()?
>
> Indeed gnutls_record_recv wasn't written for 1 byte reads. Currently
> it has quite an overhead for reading few bytes.

I've added a ticket for this:

http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/19

This could be one sub-project when we start to optimize things.  Before
I start optimize things personally, I'd like to have more benchmark data
available so that we know I attack the important parts.  If someone else
would like to solve this particular problem now, that would be very
useful.  I don't think it is difficult to solve, it should be easy to
reproduce and profile.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]