------art_252302_11291360.1177705559339
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 4/27/07, dacat <fdacat / gmail.com> wrote:
>
> The basic premise of this test was to see how long it would take to do
> the following:
>
> 1000 Basic lookups on a known attribute/value pair over an unencrypted
> connection using anonymous bind for each library.
>
> This post is for informational purposes, I knew the NET::LDAP lib
> would be slower but I wanted to see by how much.
> {if you are new to ruby, the reason it is slower is because its a TRUE
> ruby implementation of the LDAP rfc. while on the other hand the ruby/
> ldap lib is a C front end to the openldap library}



I'm not entirely sure how to interpret your reported benchmark since the
system and user times are so different for the two libraries. (I don't know
how benchmark reports time spent inside liblber and libldap or how it
measured time spent waiting for the network.) If I may assume that the
"real" column gives the amount of elapsed wall time for the two tests, then
I'll say these results (a ratio of about 1.7) more or less square with my
expectations. On a test like this, the pure-Ruby library should take between
1.4 and 1.6 times as long to complete. (Before an extensive optimization I
did several months ago, I would have expected three times longer or more.) I
repeated your test and I got roughly 1.4.

I then modified your test to use Net::LDAP#open rather than Net::LDAP#new.
Somewhat in the manner of File#open, Net::LDAP#open makes a network
connection, binds, and then performs all ldap operations within a block on
the same connection. Doing the test this way, the pure-Ruby library took
about half as much time as before. (This squares with expectations since I'm
using an encrypted link to the LDAP server and the network activity is an
important part of the runtime profile.)

The performance tradeoff between pure-Ruby and compiled C code is of course
real, and will be compelling for some applications. In general, the reasons
to prefer the pure-Ruby are the same as ever: no installation of client
libraries, better platform independence, somewhat better conformance with
the RFCs (for example, as regards LDIF handling), and fully-documented
handling of the network. (libldap is known for hiding the underlying socket
descriptors and doing unexpected things with them, leading to resource leaks
and other bizarre bugs.)

I recently completed work on a Ruby-scriptable LDAP server, built on
Net::LDAP and the EventMachine library. This project is intended for
enterprise use as a caching proxy for an A/D global catalog. So far
performance has not been a problem.

I've also used Net::LDAP in an identity-aggregator for a large enterprise,
simultaneously querying and aggregating results from a large number of LDAP
directories. In this application, performance *was* a problem, especially
compared to ldapsearch (which uses libldap). Careful tuning of Net::LDAP
made the performance acceptable, but it was still noticeably less. However
we went with the pure-Ruby version because it was easier to script, and
actually quite a bit less buggy, especially with coded binary data.

------art_252302_11291360.1177705559339--