benchmarking mod_gnutls vs mod_ssl

[Simon Josefsson]

Sam Varshavchik <mrsam at courier-mta.com> writes:

> Simon Josefsson writes:
>
>> "Paul Querna" <chip at corelands.com> writes:
>>
>>>> One interesting behaviour I noticed when running the tests was that with
>>>> mod_ssl, the exchanged TCP packets as seen in wireshark were:
>>>>
>>>> -> client hello
>>>> <- server hello, certificate, server key exchange, server hello done
>>>> -> client key exchange, change cipher spec, encrypted handshake message
>>>> <- change cipher spec, encrypted handshake message
>>>> ...
>>>>
>>>> but with gnutls we have:
>>>>
>>>> -> client hello
>>>> <- server hello
>>>> <- certificate
>>>> <- server key exchange
>>>> <- server hello done
>>>> ->client key exchange, change cipher spec, encrypted handshake message
>>>> <- change cipher spec
>>>> <- encrypted handshake message
>>>>
>>>> In other words, gnutls sends each TLS packet in a separate TCP packet.
>>>> This may have some impact on performance, but it is too early to tell
>>>> for sure.
>>>
>>> This might be a bug in mod_gnutls -- we might want to add some smarter
>>> buffering / picking when we do a flush(). Right now I believe we try to
>>> flush every time gnutls says there is data to send.
>>
>> Hm, yes, perhaps mod_gnutls could do some buffering.  Or gnutls could do
>> it internally.
>>
>>> It also would be nice if the gnutls API had a better way to say "flush",
>>> rather than just "here is data", although the current API is simple :-)
>>
>> Aren't there options in the kernel TCP interface to delay sending
>> packets for some time, to wait for more data that could also be sent in
>> the same packet?  I have some vague memory about this.
>
> Yes, TCP_CORK via setsockopt. It's Linux specific.

Thanks for the pointer.  I've read some documentation about it at:

http://linux.die.net/man/7/tcp
http://articles.techrepublic.com.com/5100-22-1050878.html

However, I'm not convinced it is a good idea for mod_gnutls to always
use it.  The first article suggests it may introduce a 200ms delay when
collecting data, which could hurt benchmarking.  Maybe we could try just
as an experiment to see if we get different results.

/Simon