php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #31332 unserialize() works terribly slow on huge strings compared to 4.3.9
Submitted: 2004-12-29 12:30 UTC Modified: 2005-01-16 09:51 UTC
Votes:38
Avg. Score:4.9 ± 0.3
Reproduced:38 of 38 (100.0%)
Same Version:24 (63.2%)
Same OS:21 (55.3%)
From: marekm at apnet dot pl Assigned:
Status: Closed Package: Performance problem
PHP Version: 4CVS, 5CVS (2005-01-04) OS: *
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: marekm at apnet dot pl
New email:
PHP Version: OS:

 

 [2004-12-29 12:30 UTC] marekm at apnet dot pl 
Description:
------------
I keep big multidimensional arrays serialize()'d into strings in database.
After upgrade from 4.3.9 -> 4.3.10 I noticed, that unserialize() function on some of them work even 20 times slower. On other the slowdown is minimal. 

Reproduce code:
---------------
<?
function getmicrotime() 
{ 
    list($usec, $sec) = explode(" ", microtime()); 
    return ((float)$usec + (float)$sec); 
} 

$f=fopen("serialized.txt","r");
$l1=fgets($f,1000000);
fclose($f);

$t1=getmicrotime();
$a=unserialize($l1);
echo(getmicrotime()-$t1);
?>

The tested "serialized.txt" file can be downloaded from http://ap.aptus.pl/serialized.txt

Expected result:
----------------
The above script working as fast as in 4.3.9

Actual result:
--------------
The script works about 20x slower.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-12-30 10:13 UTC] chris-php at bolt dot cx 
Pretty sure we're getting hit by this as well. We use serialize a lot (memcached), and upgrading from PHP 4.3.9 to 4.3.10 tripled our servers' load averages.
 [2005-01-09 15:11 UTC] ralf dot praschak at gmx dot net 
i use vbulletin 3.0.5. the forumcache is also unserialized.
i tracked this with the nusphere profiler.

with php 4.3.9 (or 5.0.2) it takes around 300ms.
with php 4.3.10 (or 5.0.3) it takes 17s and more !!!

the cache is around 2.5 megs big ;(
 [2005-01-10 13:43 UTC] kier at vbulletin dot com 
I can confirm this problem from my experience with 4.3.10 and 5.0.3.

Unserialize() under the latest versions appears to be massively slower than was previously so.

We have had wide reports of vBulletin installations running significantly slower since we recommended that customers upgrade to 4.3.10 / 5.0.3.

Hoping for a quick resolution to this problem, as it affects so many people so drastically.
 [2005-01-13 21:11 UTC] gik at zap dot cl 
The excessively high load average of a server recently updated to php 4.3.10 was driving me nuts.  This bug is critical for many php based systems as drupal, vBulletin and others.

Gik.
 [2005-01-14 09:05 UTC] derick@php.net 
Sorry to say... but abusing serialize for this is not a good idea in the first place. It's not meant for storing data in this way in the first place. But of course the slowdown shouldn't have been this much.
 [2005-01-14 13:52 UTC] gik at zap dot cl 
As far as I know, objects stored in shared memory using shm_put_var() are stored serialized.  I haven't looked at the  sources yet, but the problem affecting unserialize() should also degrade the performance of shm_put_var() which is vastly used to store arrays or other objects in shared memory for _quick_ access.  I don't know if there are other functions which use this method internally.

I wouldn't call it an abuse to serialize and store an array with 1000 elements in shm, as this is a very efficient way to do data caching.  The performance degradation is large enough to make a web server collapse, because of the extra time required to process each request.
 [2005-01-14 14:40 UTC] john at jelsoft dot com 
I would agree with what Gik just said.

To quote from the PHP manual: 
"serialize --  Generates a storable representation of a value"
Or later:
"serialize() returns a string containing a byte-stream representation of value that can be stored anywhere.

This is useful for storing or passing PHP values around without losing their type and structure."

I tried some comparisons a while back on different ways to store PHP array data in a DB. I tried storing it in a form where I could run eval($data) and it turned out to be a lot slower than unserialize($data). (Perhaps this would be different given this bug). serialize() seems to be ideal for this situation where large array or object data is to be stored in a DB or shm.

So I was surprised that the usages outlined above are 'abuses', as they seem to be using serialize() for exactly what it was intended for. Perhaps the manual needs clarifying if this isn't the case?
 [2005-01-14 18:17 UTC] dondop at gmail dot com 
It has been quite some time now and this is really an important bug to fix. 

I understand that open source means that development is done when someone feels like it, but as this is crumbling big shared hosting solutions where sites run on this PHP which use unserialize() I really a fix is developed soon. 

Comon devs, wake up and smell some coffee :)
 [2005-01-14 22:47 UTC] chris at fast4gl dot com 
I'd agree, this is a huge performance issue in 4.3.10/5.0.3 which really needs to be fixed ASAP.  I've seen many servers with performance issues because of this bug since upgrading PHP.
 [2005-01-15 19:55 UTC] sesser@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

Please try this with the next snapshot that is build at 19:30 GMT. I made some changes to unserialize() that should have restored its speed.
 [2005-01-15 23:27 UTC] gik at zap dot cl 
I've compiled the latest snapshot of PHP_4_3 and it seems to be behaving much better on real-life applications (I haven't tried the test program attached to this thread yet).  I'll keep testing for a few more days to be sure the server's performance has returned to normal levels. 

Thanks for the prompt reaction.
 [2005-01-15 23:38 UTC] marekm at apnet dot pl 
I've tested the Win32 snapshot on my serialized data I attached to the bug report and it seems that it works as fast as it used to work in 4.3.9.
Thanks for solving this problem!
 [2005-01-16 09:51 UTC] sesser@php.net 
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Tue Nov 04 10:00:02 2025 UTC