php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #7747 after opening a socket and while reading from it php start growing CPU/MEM usag
Submitted: 2000-11-10 10:42 UTC Modified: 2001-11-10 08:42 UTC
From: pov at club-internet dot fr Assigned:
Status: Closed Package: Performance problem
PHP Version: 4.0.3pl1 OS: FreeBSD 4.0-RELEASE Apache 1.3.1
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: pov at club-internet dot fr
New email:
PHP Version: OS:

 

 [2000-11-10 10:42 UTC] pov at club-internet dot fr
I use a small script grabbed from fopen to get a ftp file since fopen is buggy when dealing with ftp:// urls with encoded path name (ie using abc%20def for example).

		$datei = fsockopen("localhost", 3128, &$errno, &$errstr);
		if( !$datei )
		{
			echo "proxy not available !";
			fclose($resultfile);
			exit();
		}
		else
		{
			fputs($datei,"GET $url HTTP/1.0\n\n");
			set_time_limit(0);
			fpassthru($datei);
		}

The result is that as fpassthru sends the info from socket the mem usage grows dangerously and so does the CPU usage (up to 75% of CPU on a P100 after sending 4 Megs). Doing a "while" with a "print fgets" is even worth (but that sounds logical at least). Another "interesting" behavior of this, is that when I don't add a set_time_limit, the httpd child which delivers the info is killed with a signal 11 after 2-3 minutes and 40-45 sec. of CPU time, even though my default time-limit is 30sec.

That's all I see for now.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-10-20 21:48 UTC] sniper@php.net
Does this happen with PHP 4.0.6 ?

 [2001-11-10 08:42 UTC] sander@php.net
No feedback. Closing.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed May 07 09:01:27 2025 UTC