Re: speed of Net::LDAP

[Mark W. <mew...@un...>]

haven't tested this particular routine, but here's atop of my head
Callback:
$ldap->(
       base => "ou=people,dc=unt,dc=edu",
       scope => "sub",
       filter => "uid=mewilcox",
       callback => \&callback()
      );

sub callback
{
  my ($mesg,$entry) = @_;

  $entry->dump() if (ref $entry eq 'Net::LDAP::Entry');
  
  $mesg->shift_entry(); 
}

As for the other LDAP modules:
1) Net::LDAPapi is completely dead. Clayton turned that over to Netscape
2) PerLDAP (aka the Mozilla LDAP module) hasn't been updated in quite a
long time. I'd say it's mostly dead. It should still work, but there's not
a lot of help out there and I have no idea if/when next version will be
coming out (though admittedly I haven't been on the mozilla LDAP newsgroup
in a long time).

As you can probably see is that the biggest penalty is paid during
startup. Thus if you can eliminate the startup costs, then you'll most
likely be fine. What I would recommend then is to put it entirely via HTTP
and use mod_perl so that the script is loaded once & run forever. 

You could also be a bit paranoid :). For example if the ultimate users who
use the application don't have anything else to compare it to, they likely
won't know or care (as long as it runs in something under an hour ;). We
use Net::LDAP for everything here at UNT with LDAP and performance has
never been a factor (e.g. we've never said, gee I wish it would run
faster). Like Chris Ridd said, portability and ease of use are much more
important to us.

Mark
          


On Thu, 27 Jul 2000, Luke Kanies wrote:

> Mark Wilcox wrote:
> > 
> > Well, duhhhhh :) (and what's one of the greatest Perl phrases, "You might
> > write faster code in C, but you'll write code faster in Perl"). Net::LDAP is
> > written in pure Perl, thus it will be slower than anything written in C. Now
> > we know where the bulk of the speed problems are and they are in
> > Convert::ASN1 because everything in LDAP must be encoded/decoded from BER
> > before transport. At some future point, Graham (or someone else??) may write
> > an optional C backend for ASN1 (e.g. it would compile in C if you had a C
> > compiler, otherwise it would remain pure Perl). But that will come after
> > Net::LDAP is more complete.
> 
> I understand that perl will be slower than C, but I didn't think that it
> would be an order of magnitude slower...
> 
> > Now there are some things you can do to improve performance and efficiency,
> > namely callbacks. They'll reduce the amount of memory you consume & will
> > enable you to process results as soon as Net::LDAP gets them, instead of
> > having to wait until the end.
> 
> What is a callback?  I have done most of my perl coding in what amounts
> to a vacuum, I guess.  I have seen callbacks mentioned in a couple email
> responses to my question, so what are they and how do I use them?
> 
> > Speed is also in the eye of the beholder and CPU. For example, if most your
> > application delay is going to be in network latency regardless of language,
> > then write in C becuase it won't really matter. If the program is run in
> > batch mode, where perhaps the Perl program takes an extra 15 minutes to run,
> > but you can write it in less than 20 minutes, as opposed to an hour or more
> > in C,. is that worth it?
> 
> Well, I am writing a suite of tools which will allow my admins (I'm an
> engineer at an ISP) to more easily maintain user accounts in our LDAP
> database; it pretty much needs to be synchronous, so I can't do it in
> batch mode, and I am willing to spend dev time now to avoid run time
> later.  Except that I really am not very good in coding anything other
> than perl (I learned it first, basically, and now I am spoiled).
> 
> > As for the other Perl modules, well, we're really the only one left :).
> > PerLDAP hasn't seen a release in over a year and I don't anticipate one
> > anytime soon. Plus the user community has dried up, heck the guy who wrote
> > the original code that PerLDAP is based on, uses us because it's so much
> > easier & functional (the next version will have real support for controls &
> > DSML & SSL!).  And we test against just about every LDAP server you'll ever
> > encounter.
> 
> What about the mozilla ldap module?  Is it still being worked on?  
> 
> > Thus, the performance isn't going to dramatically improve anytime soon
> > (unless you go from a 200 MHZ to a 800MHZ CPU ;), but there are things that
> > can make your program to appear to run faster. Or you are free to work with
> > us to try to add the C backend to the ASN1 module.
> 
> Uh, no, I don't think you'd want my help writing C...  You could do more
> in an hour than I could in a week.
> 
> > I'm also willing to help you optimize your application (for example if it's
> > CGI based, use mod_perl instead of traditional CGI, keep a static connection
> > open to the server).
> 
> Well, some of my scripts will be CGI based, but the script that prompted
> me to send this mail is actually command line, so that's not an issue.
> 
> > Net::LDAP may not be a total speed deamon, but I've been using it for over 2
> > years and it's portability has come in more handy than any speed concerns.
> 
> As I said, I did expect Net::LDAP to be slower, I just didn't expect it
> to be that much slower.  And portability isn't really a concern for me,
> since (a) my company uses solaris/sparc exclusively, and (b) this suite
> of tools will be run on only a few machines.
> 
> This is the second or third time I have tried to develop a bunch of
> tools using perl to talk to LDAP.  The first time was when I was first
> learning LDAP, and I basically just got frustrated; Net::LDAP was too
> slow to do what I needed it to do, Net::LDAPapi's api was so confusing
> that I never got it figured out (although I seem to be able to
> understand it much better now), and there didn't seem to be any other
> choices.  I ended up just running command line searches and parsing
> through them, but that means having passwords run as flags on the
> command line, and that's bad.
> 
> And then I went and destroyed all of that code accidentally.  Yay.
> 
> I took a hiatus for quite a while, but am now revisiting the problem,
> and I would like to do it right.  But I can't wait 20 seconds for a
> command line app to finish its very first search, much less do all the
> work it needs to.
> 
> Thanks for the quick response, BTW.
> 
>