ID: 39826 Updated by: [EMAIL PROTECTED] Reported By: 1413 at blargh dot com -Status: Open +Status: Bogus Bug Type: Performance problem Operating System: Linux PHP Version: 5.2.0 New Comment:
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 http://www.php.net/support.php 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. Previous Comments: ------------------------------------------------------------------------ [2006-12-13 23:43:26] 1413 at blargh dot com 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 this bug report at http://bugs.php.net/?id=39826&edit=1
