From: 1413 at blargh dot com
Operating system: Linux
PHP version: 5.2.0
PHP Bug Type: Performance problem
Bug description: ldap_bind is very slow with SSL
Description:
------------
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:
---------------
<?php
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_create
ldap_url_parse_ext(ldaps://<ldap server>)
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
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_send_server_request
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:
Empty
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
ldap_int_select
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
ldap_free_connection: refcnt 1
ldap_parse_result
ldap_msgfree
ldap_free_connection
ldap_send_unbind
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.
--
Edit bug report at http://bugs.php.net/?id=39826&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39826&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39826&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39826&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39826&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39826&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39826&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=39826&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=39826&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39826&r=support
Expected behavior: http://bugs.php.net/fix.php?id=39826&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39826&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39826&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39826&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39826&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39826&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=39826&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39826&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39826&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39826&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=39826&r=mysqlcfg
