On Thu, 2017-11-02 at 09:08 +0100, Michael Ströder wrote: > William Brown wrote: > > On Wed, 2017-11-01 at 20:33 +0100, Michael Ströder wrote: > > > Tim wrote: > > > > I've used the python-ldap library to simulate other varieties > > > > of > > > > interactions successfully, but when it comes to binds, each > > > > interaction seems to generate a substantial amount of traffic > > > > behind the scenes, so suspect that *things* are happening that > > > > is > > > > artificially limiting the bind rate/s.>> > > > > > > python-ldap itself is a pretty thin wrapper on top of libldap. > > > Especially if you're using LDAPObject.simple_bind() or > > > LDAPObject.simple_bind_s() [1] there is definitely no "traffic > > > behind > > > the scenes". > > > > > > So if you have overhead on the client side I suspect your own > > > Python > > > code adds this. > > > > python-ldap is very thin, but it does have a global mutex that can > > prevent you "really hitting" the ldap server you are testing. > > Yes, you're right. But not sure whether you really hit the GIL limit > since python-ldap releases GIL whenever it calls libldap functions. > And of course when running a multi-threaded client each thread should > have its own LDAPObject instance. > (I assume here that Python is built with thread support and python- > ldap > was built against libldap_r. Otherwise all calls into libldap > (without > _r) are serialized with a global lock.) Yeah, the GIL isn't the issue, it's the global lock. You need to start multiple separate python interpreters to really generate this load. We have a python load test, but you have to start about 16 instances of it to really stress a server. I've always wondered what the purpose of the ldap lock was, but that's a topic for it's own thread I think :) > > Ciao, Michael. > -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part