|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #39826 ldap_bind is very slow with SSL
Submitted: 2006-12-13 23:43 UTC Modified: 2006-12-17 18:32 UTC
From: 1413 at blargh dot com Assigned:
Status: Not a bug Package: Performance problem
PHP Version: 5.2.0 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
45 - 27 = ?
Subscribe to this entry?

 [2006-12-13 23:43 UTC] 1413 at blargh dot com
While testing with binding to LDAP sources using SSL, it goes through all the certificates like the command line, but gets increasingly slower for each one.  With 65 certificates installed, it takes 39 seconds to go through it.  The command line OpenLDAP utilities, while going through the same certificate search, do not slow down.

Reproduce code:

ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
$conn = ldap_connect("ldaps://<ldap server>");
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_bind($conn, "<dn>", "<password>");


Expected result:
It should finish very quickly.

Actual result:
$ time php ./test-ldap.php
ldap_url_parse_ext(ldaps://<ldap server>)
ldap_connect_to_host: TCP <ldap server>:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying <numeric ldap server>:636
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
ldap_int_sasl_open: host=<ldap server>
TLS certificate verification: depth: 0, err: 0, subject: <ldap server certificate info>
ldap_open_defconn: successful
ldap_result msgid 1
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
wait4msg (infinite timeout), msgid 1
wait4msg continue, msgid 1, all 1
** Connections:
* host: <ldap server>  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Wed Dec 13 15:22:12 2006

** Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
** Response Queue:
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
read1msg: msgid 1, all 1
ldap_read: message type bind msgid 1, original id 1
new result:  res_errno: 0, res_error: <>, res_matched: <>
read1msg:  0 new referrals
read1msg:  mark request completed, id = 1
request 1 done
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection: refcnt 1

ldap_free_connection: actually freed

real    0m38.939s
user    0m36.746s
sys     0m0.216s

Now for the command line doing a bind AND a search to the exact same system, parameters, etc.:
$ time ldapsearch -x -H "ldaps://<ldap server>" -D "<dn>" -w "<password>" -b "<basedn>" -P 3 "(uid=<same user>)"
# extended LDIF
# LDAPv3
# base <basedn> with scope subtree
# filter: (uid=<same user>)
# requesting: ALL

<expected search record>

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

real    0m0.345s
user    0m0.096s
sys     0m0.044s

When I run strace on the php version, it drastically slows down on accessing the SSL certificates portion (ldap_int_sasl_open on the LDAP debug), with the CPU chugging at 100%.  The strace shows no system function causing a delay, just an increasing pause between one munmap and the next stat64 call.

I see other people reporting the same bug that have been dismissed (35610, 36145) with "We only wrap around the openldap library and openssl. If those fail, it's not our problem.".  I'm hoping I've shown above that it appears PHP is failing, while neither OpenLDAP nor OpenSSL are (because the command line utility works fine).  I freely admit this is strange as I imagine PHP is calling the same functions, but something is going horribly wrong somewhere with PHP that is not with the command line utils.

My ulimit -a is:
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

So should not be an open files issue (although I have tried bumping it to 8192).  The machine is not running out of memory.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-12-17 18:32 UTC]
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The ldap_int_sasl_open() function is a ldap lib function over 
which PHP has no control over. The fact that it is the 
function that is eating all the cpu implies that this is not a 
PHP issue.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Fri Jun 25 04:01:31 2021 UTC