Edit report at http://bugs.php.net/bug.php?id=37840&edit=1
ID: 37840 Comment by: Mikhail dot V dot Gavrilov at gmail dot com Reported by: diego at caravana dot to Summary: uniqid() without more_entropy extremely slow Status: No Feedback Type: Bug Package: Performance problem Operating System: Linux 2.4.21 PHP Version: 5.1.4 Block user comment: N New Comment: Comfirm this issue. PHP 5.3.3 Linux and Windows Previous Comments: ------------------------------------------------------------------------ [2007-08-09 13:03:41] franz dot sedlmaier at gmx dot net I can confirm this issue for newest PHP version (5.2.3). ------------------------------------------------------------------------ [2006-11-21 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". ------------------------------------------------------------------------ [2006-11-13 22:41:08] il...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip ------------------------------------------------------------------------ [2006-06-18 17:21:08] diego at caravana dot to Description: ------------ See #37106 first. Ok, this may be "bogus", but is there a workaround or some other unique id generator in PHP? I've spent 2 days trying to figure out why my webapp was *so slow* on production server, when on develop/test environments it was acceptable... At last, I profiled (APD) it and discovered that uniqid() was terribly slow. I searched for some big problem in my app then, without any other clue, I commented out the usleep() call in uniqid.c: magically, a page that took 10 seconds now responded under 1 sec! I tried with the following lines instead of usleep(), but with the same problem: struct timespec tsq; tsq.tv_sec = 0; tsq.tv_nsec = 1; nanosleep(&tsq, NULL); FYI, I "patched" PHP 5.1.4, and the server with the problem runs an updated RHEL 3 (Linux 2.4.21-40.ELsmp). ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=37840&edit=1
