Subject: Component Matching Performance

From: Sang s Lim <[email-masked]>
Date: Fri, 3 Dec 2004 21:11:34 -0500

Attached is a preliminary performance numbers of Component Matching. We 
compared the performance of Component Matching and the existing 
certificateExactMatch implementation of OpenLDAP which utilizes openssl 
certificate decoder. We were able to use the DirectoryMark benchmarking 
tool for Component Matching because DirectoryMark clients naturally 
support component matching without modification.

Experimental platform
        - Server: IBM BladeCenter blade node with 2x2.4G HT Xeon, Linux 
Kernel 2.4.20
        - Client: IBM BladeCenter blade node with 2x2.4G HT Xeon, Windows 
2000
        - Network: 1Gbps Ethernet
 
Directory
        - 100,000 entry DIT
        - Each entry is a person entry with one userCertificate attribute
        - Operations: Random searches on tbsCertificate.serialNumber 
(serialNumber in userCertificate)
        - Indexing: tbsCertificate.serialNumber

Result (average of 3 runs)
        - Component Matching: 
                - Throughput: 3273.66 ops/sec
                - Max latency: 20ms
        - certificateExactMatch in OpenLDAP
                - Throughput: 3674.73 ops/sec
                - Max latency: 18ms
 
The performance numbers show that the overhead of Component Matching is 
around 10% which we attribute to the component filter parsing overhead. 
However, we expect that Component Matching performs on par with the custom 
openssl matching when the attribute aliasing mechanism is used in 
Component Matching because this will eliminate the additional component 
filter parsing steps.

Sang Seok Lim

IBM T.J Watson Research Center
Enterprise Linux Group
[email-masked]

---

From: Andrew Sciberras <[email-masked]>
Date: Mon, 06 Dec 2004 14:15:43 +1100

Hi,

>        - Indexing: tbsCertificate.serialNumber

I haven't used OpenLDAP or explored its Component Matching capabilities 
yet, so I'm going to take the content of the operation mentioned above 
literally.
The mention of 'tbsCertificate' is both surprising and confusing...  The 
userCertificate attribute within LDAP and X.500 does not have a syntax 
of Certificate as defined within RFC3280; it has a syntax of Certificate 
as defined with X.509. This is stated in both RFC2252 and Kurt's 
individual submission of "LDAP X.509 Certificate Schema" 
(draft-zeilenga-ldap-x509-00.txt).
Even though these definitions may be syntactically equivalent, an 
LDAP/X.500 userCertificate does not have a tbsCertificate component.

It is my opinion that the component tbsCertificate should not be used 
within an LDAP search for the userCertificate attribute and in doing so 
should result in zero entries being returned.

Regards,
Andrew Sciberras
eB2Bcom

---

From: Sang s Lim <[email-masked]>
Date: Mon, 6 Dec 2004 11:22:48 -0500

Andrew,

>LDAP/X.500 userCertificate does not have a tbsCertificate component.

The ASN.1 specification defined in RFC 3280 was used in our experiment. 
During development, we initially had a separate componentCertificate 
attribute with an experimental syntax for Component Matching. It was only 
recently that it was merged to userCertificate. We have yet to reflect 
this change to the ASN.1 specification in OpenLDAP. Nevertheless, the 
search was performed without any problem and the experimental result 
should be valid, because they are equivalent and the component reference 
used the identifier defined in the ASN.1 specification. Although we need 
update the ASN.1 specification in OpenLDAP Component Matching to use X.509 
syntax, the performance results should not be affected by this change.

Sang Seok

Sang Seok Lim

---

From: Sang s Lim <[email-masked]>
Date: Mon, 6 Dec 2004 12:17:41 -0500

>I must apologize, I probably should have started a new thread.
>I wasn't questioning the accuracy of your performance testing, my 
>concerns were based around interoperability issues.

Regarding the interoperability issues, you are right. We will update our 
ASN.1 specification in OpenLDAP.

Sang Seok
Regards.

---

From: Andrew Sciberras <[email-masked]>
Date: Tue, 07 Dec 2004 03:31:11 +1100

Sang,

Regards,
Andrew Sciberras.