php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22880 Performance loss of 50% form 4.0 to 4.3?
Submitted: 2003-03-25 12:43 UTC Modified: 2003-05-09 07:33 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:3 (100.0%)
From: project dot draco at gmx dot net Assigned:
Status: Closed Package: Performance problem
PHP Version: 4.3.2-RC OS: win98//freebsd//any?
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: project dot draco at gmx dot net
New email:
PHP Version: OS:

 

 [2003-03-25 12:43 UTC] project dot draco at gmx dot net
I switched from php 4.0.6 to 4.3.1 lately. I run php as cgi on an win98-apache 1.3.20-php-mysql system.

I think i missed all versions in between, but now i realize a performance loss of about 50% (execution time nearly doubled without ANY code changed, simply giving Apache a different cgi)
I was able to catch up partly by tuning the php.ini (i never did this before!) but still expirience serious performance loss.

This mostly seems to take place on database and filesystem operations, but i'm not sure of this.

Could someone measure this out?


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-25 14:48 UTC] wez@php.net
Please try using this CVS snapshot:

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

There was a performance problem for file() and file_get_contents() on systems without memory mapping support; this has been fixed in the stable snapshots.

Please give it a try.
 [2003-03-30 05:10 UTC] project dot draco at gmx dot net
Gave it a try.

Didn't work, sorry. As slow as before...

So now im going to make some testings to find out, where the performance loss originates from.

I already localized some strange side effects, wich point to the conclusion, that it is in fact something with the memorymanagment.
The same script, executed as standalone is much faster, than executed within a huge script.

Ill be back with some more accurate bug-report soon.

so long

mir
 [2003-03-31 02:13 UTC] sniper@php.net
Still waiting for the feedback of more detailed information.

 [2003-04-05 09:39 UTC] project dot draco at gmx dot net
ok,ok

did some testing and found at least the following behaviour:
i kept track of includ_once times in my script and ran a couple of times the same script, wich includes havily about 300 kB.

While 4.0.6 did this job with an avarage time of 0.4 ms per kB included script, the 4.3.1 and 4.3.2 versions show an increasing amount of time use to include_once the scripts.

Some values

sumsize	avg 406	avg 432
		
0	0,55	0,47
16660	0,54	0,49
32859	3,92	3,65
57138	0,57	0,80
62766	0,46	0,74
83208	0,46	0,77
106302	0,44	0,69
114039	0,56	0,93
119067	0,57	1,17
129474	0,62	1,08
150891	0,90	1,70
161932	1,46	1,74
167775	0,43	0,83
182655	0,42	1,06
209909	0,47	1,63
246752	0,49	1,51
269711	0,42	1,61
330045	0,48	1,85
346306	0,41	1,64


The three bigger values (3.92,0.90,1.46 at the avg406 col) are scripts that do initial executions and db-queries, so we ommit them.
the rest is simple classdefs, no initializing done.

As you can see, the 432 avg times increase with increasing filesize
(the sizes are summed up so 346306 is the full scriptsize that is run)

Can you read anything helpful out of this posting???

ps Testing was done on win98/php-cgi/apache 1.3.20 systemenvironment.

gruss
mir
 [2003-04-05 11:31 UTC] sniper@php.net
You need to provide us the same script to test this with.
Just testing on one machine does not give reliable results.

 [2003-04-06 06:24 UTC] project dot draco at gmx dot net
thx for keeping me busy :-)
i will email the zipped script to sniper (6k, ok?), hope you get it going.

dont bother if i'm a bit quiet next days, but i got a daytime job as a social worker, so be patient.
good testing meanwhile.

gruss
mir
 [2003-04-23 04:34 UTC] sniper@php.net
Please try using this CVS snapshot:

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

Can't get any performance loss. Might be something wrong
with your code.

 [2003-04-28 11:14 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-04-28 11:26 UTC] wez@php.net
Most likely a dup of Bug #22721; fixed in the latest stable snapshot.
 [2003-04-29 09:12 UTC] project dot draco at gmx dot net
Sorry for being lazy, i will download the latest stable release (this may take about years on my phonemodem...)
and give it a try.
Think the #22721 trace maybe right, it sounds like similar problems.
The last snapshot (26-Mar-03) of win32 php did not solve the problem.
do swedanaja paka
 [2003-05-09 07:33 UTC] sniper@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, 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/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 23:01:28 2024 UTC