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.