[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Strange TLS behaviour with slapd 2.3.30 on Debian Etch
Howard Chu <hyc@symas.com> writes:
> Yes, callgrind is pretty cool, much more useful than old gprof-style
> profilers. Though as you note, the runtimes of any valgrind tool can
> be pretty extreme. My tweaked version of FunctionCheck is also useful
> when you can afford to compile an instrumented version of your
> code. Faster runtimes in exchange for extra compile time - frequently
> it's a worthwhile tradeoff.
>
> http://highlandsun.com/hyc/#fncchk
Interesting, does the code still run and is useful? The latest comment
about it was from 2005. To be able to use it, I need to set up a useful
benchmark environment first though.
>>> Not being an TLS/SSL expert, I'm wondering why you need to add all
>>> those certificates in the first place. I thought the whole point of
>>> all those<subject hash>.<serial> links in /etc/openssl/certs (or
>>> whatever) was that a client could find a CA certificate simply by
>>> hashing the subject.
>>
>> GnuTLS doesn't support hashed certificate directories. Further, TLS
>> servers need to send a list of names of trusted certificates to clients,
>> so the server has to open and parse all local trust roots anyway. Right
>> now, this is done for clients too, since the relevant code in GnuTLS
>> doesn't know whether it will be used as a client or server. I hope the
>> new code will be fast enough so that it isn't a bottle-neck. I suppose
>> that it could be optimized further, so that it isn't done for clients at
>> all, but let's not optimize prematurely.
>
> You're already approaching GnuTLS version 2.4. If optimizing now is
> premature, when will it actually be time to optimize?
If anyone wants to contribute by profiling/optimizing something in
GnuTLS, doing it now is fine with me.
/Simon