php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15746 Process exec() is slow from webserver - running from shell is ok ...
Submitted: 2002-02-26 22:29 UTC Modified: 2002-09-21 02:10 UTC
Votes:42
Avg. Score:4.6 ± 1.0
Reproduced:38 of 38 (100.0%)
Same Version:12 (31.6%)
Same OS:19 (50.0%)
From: nigel at green-bean dot com Assigned:
Status: No Feedback Package: Performance problem
PHP Version: 4.1.1 OS: Windows 2000 Server
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: nigel at green-bean dot com
New email:
PHP Version: OS:

 

 [2002-02-26 22:29 UTC] nigel at green-bean dot com
Summary:

Running a PHP script which calls exec() from withing Apache runs terribly slow or times out.  Running same from the command prompt returns in seconds.

Details:
I (and other NT users) have run into performance issues running PHP 4.1.1 with the NETPBM distribution.    When running thumbnailing operations via. webpages, the performance (throughtput) of the system is dismal.

Running the same PHP script manually from the command shell completes operations in under a second which usually timeout when executed from a webpage.

A full "ready to run" repro of this problem is available via. a small ZIP file at http://www.green-bean.com/bugfiles/slowrepro.zip.   This contains the required NETPBM files.   If these are already installed on your system, you can run the script below with slight modifications.

Thanks,
Nigel.
----
Repro:

<?
// Full repro kit including executables available from http://www.green-bean.com/bugfiles/slowrepro.zip
//

// Location of your NETPBM distribution
// We're using http://prdownloads.sourceforge.net/gallery/netpbm1.1-gallery1.0-win32.tgz
// 
$pbmroot = "netpbm";

// JPG input file (from http://www.green-bean.com/DallasChristmasHat.jpg)
$file = "DallasChristmasHat.jpg";


function fs_exec($cmd, &$results, &$status, &$time) {
    // We can't redirect stderr with Windows.  Hope that we won't need to.
    $time_st = time();
    $x = exec("$cmd", $results, $status);
    $time = time() - $time_st;
}

$quiet = "-quiet";

// JPEG to PNM
$cmd_to_pnm    = "$pbmroot\\jpegtopnm $quiet $file > out\\$file.pnm";

print "<br>Exec: $cmd_to_pnm\n";
fs_exec($cmd_to_pnm, $results, $status, $elapsed);
print "<br>Elapsed: $elapsed secs\n<br>Status: $status";

// PNM to scaled PNM
$cmd_scale_pnm = "$pbmroot\\pnmscale  $quiet -xysize 150 150 out\\$file.pnm > out\\$file.scale.pnm";

print "<br>Exec: $cmd_scale_pnm\n";
fs_exec($cmd_scale_pnm, $results, $status, $elapsed);
print "<br>Elapsed: $elapsed secs\n<br>Status: $status";

// PNM scaled to JPG
$cmd_to_jpg    = "$pbmroot\\ppmtojpeg $quiet out\\$file.scale.pnm --quality=150 > out\\tn_$file";

print "<br>Exec: $cmd_to_jpg\n";
fs_exec($cmd_to_jpg, $results, $status, $elapsed);
print "<br>Elapsed: $elapsed secs\n<br>Status: $status";

?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-28 14:24 UTC] bharat at menalto dot com
This is a frequently reported problem on the Gallery Users mailing list (http://gallery.sourceforge.net/)
 [2002-05-23 02:09 UTC] dj_TOW at gmx dot net
hi all,

just wanted to add to this:

im running windows 2000 (german), apache 1.3.24 with php 4.2.1. (php4apache.dll). i have the same issue described above, with netpbm just timing out, even when trying to do a simple "-version" in a script. since i need to use netpbm for a gallery i run (which ran fine on omnihttpd btw), i would like to know if there is a workaround, or if this bug will be fixed anytime soon.
 [2002-05-23 06:10 UTC] wez@php.net
Could one of you guys try a CVS snapshot and alter the scripts to use the new proc_open function?
It's possible that it might have better performance,
(and you can then redirect stderr too!)

 [2002-05-23 06:22 UTC] wez@php.net
By the way: PHP doesn't do anything any different (with regards to executing files) if it is running as a module or as a cgi.  Does perl have a similar issue? 
 [2002-05-23 11:21 UTC] dj_TOW at gmx dot net
i'd really like to do that, but im pretty inexperienced coding php. a script i wrote, that utilized imagemagick for graphics conversion/thumbnailing worked just fine ! thanks for the help anyways.
 [2002-05-23 16:44 UTC] nigel at green-bean dot com
Wez - I can try reproducing the issue if you can provide a pointer to a compiled PHP kit?   I'm not in a position to compile the whole project.
 [2002-05-23 17:01 UTC] derick@php.net
Win 32 snapshots: snaps.php.net/win32/
You want the non-STABLE one.

Derick
 [2002-06-24 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
 [2002-07-09 17:33 UTC] ollie at oliverc dot com
I don't know if anyone got any further (guessing not...) but I've taken the non-stable CVS snapshot, installed it, and modified the gallery script that makes an exec call to use proc_open.  Unfortunatly it doesn't make any difference.  The following (mess!) is the code I've used to test the call:

	$descriptorspec = array(
	   1 => array("pipe", "w")  // stdout is a pipe that the child will write to
//	   2 => array("file", "/tmp/error-output.txt", "a"), // stderr is a file to write to
	);
	msg("CALLING PROC_OPEN");
	$process = proc_open("cmd.exe /c $cmd", $descriptorspec, $pipes);
	msg("PROC OPEN DONE");
	if (is_resource($process)) {
		msg("SUCCESS");
	    // $pipes now looks like this:
	    // 0 => writeable handle connected to child stdin
	    // 1 => readable handle connected to child stdout
	    // Any error output will be appended to /tmp/error-output.txt

	    while(!feof($pipes[1])) {
	        msg("+");
	        echo fgets($pipes[1], 2);
	        msg("-");
	    }

	    fclose($pipes[1]);
   		$return_value = proc_close($process);
		echo "RETURNED: $return_value";
	}

Basically my output window does nothing for about 50 seconds after printing the first + symbol before the actual output from the command starts to appear.  Running the identical command in a command prompt takes less than one second to complete.

I'm running WinXP (home) with Apache 1.3.26 btw (and have the same problem people have reported above obviously).
 [2002-07-10 10:33 UTC] nigel at green-bean dot com
Ollie tried the suggested workaround with the same (negative) results.
 [2002-07-16 05:51 UTC] jonohlsson at hotmail dot com
I have tried every netpbm-distr there is, even mixing different versions and still it takes forever to upload jpeg files (gifs work like a charm)...it MUST be a PHP-bug
/Jon
 [2002-07-16 14:23 UTC] sniper@php.net
Try this snapshot first:

http://snaps.php.net/win32/php4-win32-latest.zip


 [2002-07-17 04:26 UTC] jonohlsson at hotmail dot com
Well Im running PHP 4.2.1/Apache 2.0.36...I didn't download that php_win32_latest.zip because after some further tweaking IT STARTED WORKING!

I really cannot reconstruct any detailed info about what I did but now I can upload jpegs really fast. Every jpeg-image takes about 1 sec.

I think I used the latest netpbm release (10.3) and then I may have used the jpegtopnm.exe from the 9.25 release (not sure). I used the cyg*.dlls from the 9.25 release though. At first there was no improvement BUT THEN I TURNED MY NORTON FIREWALL OFF AND VOILA...IT STARTED WORKING LIKE 'SNAPPING YOUR FINGERS'.

Sorry I cannot be of more help...if you like i could zip all files im using for you to analyse...

/jon
 [2002-07-17 04:36 UTC] jonohlsson at hotmail dot com
Other interesting facts: the problem previously was time-outs. Every added jpeg took like forever to upload. but if you studied the taskmanager there was a pattern. Every jpegtopnm.exe call was idle (cpu 0 %) for about 30 secs...then the cpu jumped to 100% for about 1 sec. So there must have been some 30 sec parameter somewhere making the call rest. I dont know: I've checked every parameter there is in php.ini and congig.php (for gallery) and httpd.conf. Could it really be a firewall-issue...? ...it feels strange..BUT alas it works now.
/jon
 [2002-07-19 15:18 UTC] gallery at bianco dot net
Winnt4 sp6
Apache 1.3.26 (win32)
PHP 4.2.1 (win32) (exe timeout set to 300sec)
Gallery 1.3
netpbm-gallery 1.1 Microdist
Celeron 466/196MB

I am experiencing the same slowness using gallery's PHP scripts to call the netpbm binaries.  Each 1.2 MB image takes about five minutes to have a thumb and resized version created.  At first I thought it was due to the celeron, but after watching TaskMan, the netpbm exe's are idle most of the time.. they take available CPU once every few minutes.. Something is causing a wait/timeout in the process.

I am not behind a firewall, so Im not sure that is the issue.  It is possible that using the netpbm/gallery microdist is causing the slowness.  I have been unable to get the standard netpbm dist working.

Thanks,
Chris
 [2002-07-19 15:21 UTC] nigel at green-bean dot com
Jon (jonohlsson@hotmail.com) was able to get Gallery and NetPBM running with a mixture of binaries (v10.3 of NetPBM).   I had him zip up his installion so I could see if this worked for me.   It did not - I still have the same issue as everyone else.

Nigel.
 [2002-07-21 04:51 UTC] gallery at bianco dot net
Win32 - Full netpbm dist runs at acceptable speed.

Was able to fix problem by swithing to full netpbm release (10.5).  I only experience the idle CPU problem with the netpbm-gallery 1.1 release, distributed on the gallery site. So it may not be a PHP exec() bug after all.

In order to use the full netpbm dist, I needed to make changes to Gallery's config.php:

Change: 
$gallery->app->pnmtojpeg = "ppmtojpeg";

To:
$gallery->app->pnmtojpeg = "pnmtojpeg";

ppmtojpeg.exe does not exist in netpbm 10.5.

Chris
 [2002-07-26 14:05 UTC] wez@php.net
Have you guys considered that it might be a cygwin problem?
Cygwin does a lot of magic, some of it depends on obscure things like your CYGWIN environmental variable.
Perhaps you should all confer and compare your cygwin setups?
 [2002-08-27 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, 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".
 [2002-08-27 10:09 UTC] nigel at green-bean dot com
Wez, no one is using cygwin in the current setup.  This is all run directly from under IIS.
 [2002-08-27 11:47 UTC] wez@php.net
Err, so whats with the cygwin dlls in your netpbm distro??
Cygwin is a unix emulation library for windows.

Please try a newer distro, such as the full netpbm release (10.5) mentioned by Chris (gallery@bianco.net).
 [2002-09-21 02:10 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.


 [2008-11-04 08:45 UTC] sherzad at hotmil dot com
kh;jgfj,n mtgejyrtsx
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Dec 27 11:01:30 2024 UTC