I was kinda hoping the fast-cgi version would enable the best of both
worlds; however, I have been unable to get it to work under apache at
this point. Any comments ?
-----Original Message-----
From: Brian Foddy [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 30, 2001 9:18 PM
To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]; Rod K
Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.
That sounds like it would work also. People would have
to build PHP for both modules and CGI, but if they
are willing to do that...
Works for me.
Brian
On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote:
>Couldn't one just run a cgi and module version simultaneously? Set an
add
>type directive to pass an extension, say .cphp, to the cgi instead of
the
>module. Then those scripts that use extensive memory could be extended
with
>.cphp???
>
>-----Original Message-----
>From: Brian Foddy [mailto:[EMAIL PROTECTED]]
>Sent: Monday, April 30, 2001 11:56 PM
>To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>freed.
>
>
>Perhaps another possible solution is this...
>For those 1 in 300 web hits that the developer knows is
>going to use gobs of memory and assuming they can't
>be re-engineered to use less (through temp files, etc),
>create a simple function that is callable in PHP that
>will cause the parent apache process to exit (if it doesn't
>exist already) It will be immediately replaced by another much smaller
>version ready to handle the remaining 299 web hits.
>
>This gives the performance benefit for most hits of
>the apache module, but the memory benefits of the
>cgi behavior.
>
>But before I'd do that, I'd make sure the big page
>can't be re-engineered first.
>
>Brian
>
>On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote:
>
>>I too have experienced this problem and can reproduce, I just changed
to
>>the cgi version instead to eliminate the problem, which I would agree,
>>it is. I have one page on a site of hundreds of pages that produces
the
>>large process, 30MB+ and this is on a heavily used server with more
than
>>300 processes. So if I don't run the cgi-version the server will
crash
>>in a matter of time as the memory is not freed and eventually will
swap
>>itself to death. So while the cgi-version is slightly slower, I have
>>reliability.
>>
>>John Hamlik
>>
>>-----Original Message-----
>>From: Brian Moon [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, April 30, 2001 3:20 PM
>>To: [EMAIL PROTECTED]; Andi Gutmans
>>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>>freed.
>>
>>
>>But the reverse side of this is that I might have one script out of
1000
>>that needs that much memory. But since 20 of my httpd processes have
>>run
>>that script, they all have that much memory and are not going to let
it
>>go
>>no matter what.
>>
>>I basically sounds like a flaw that memory can not be freed. Reuse in
>>the
>>same process is not free memory, it is reused memory. And it sounds
>>like
>>there is nothing that the PHP team can do about it.
>>
>>Brian Moon
>>----------------------------------------------------------------------
--
>>-
>>Phorum Dev Team - http://phorum.org
>>Making better forums with PHP
>>----------------------------------------------------------------------
--
>>-
>>
>>Look for my presentation at ApacheCon 2001.
>>"Caching Dynamic Web Content to Increase Dependability and
Performance"
>>http://www.apachecon.com/
>>
>>
>>
>>----- Original Message -----
>>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>>To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>>Sent: Monday, April 30, 2001 5:02 PM
>>Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
>>freed.
>>
>>
>>> At 04:59 PM 4/30/2001 -0500, Brian Moon wrote:
>>> >This is the answer I had previously received. IMHO, this sucks.
We
>>don't
>>> >do SQL queries on our production site. It is all cached. So, SQL
is
>>not
>>> >the problem. It is most likely because of the storage of large
>>arrays or
>>> >something of that nature.
>>>
>>> Well maybe you should try and see what in your script is taking up
>>lots of
>>> memory.
>>>
>>>
>>> >I guess we will continue to use MaxRequestsPerChild until one day
the
>>people
>>> >that wrote that memory allocation system get a clue.
>>>
>>> They are very clue full. A program which uses X MB of memory is very
>>likely
>>> to use X MB of memory again at a later time. For example, how does
it
>>help
>>> you if your 14 MB were shrunk back to 10 MB on each request. The
next
>>> request would probably make it grow back to 14 MB.
>>> There might be some memory management libraries that shrink the
memory
>>back
>>> but I doubt you can gain much from it especially as memory
>>fragmentation
>>> can severally limit the amount of memory you can reclaim and because
>>of
>>the
>>> point I made before, it's probably just not worth it.
>>>
>>> If you can find a case where you really think PHP is using much too
>>much
>>> memory let me know and we can try and check together if there's a
way
>>to
>>> improve the situation.
>>> Andi
>>>
>>>
>>
>>
>>--
>>PHP Development Mailing List <http://www.php.net/>
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>To contact the list administrators, e-mail:
[EMAIL PROTECTED]
>>
>>
>>--
>>PHP Development Mailing List <http://www.php.net/>
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>To contact the list administrators, e-mail:
[EMAIL PROTECTED]
>>
>
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail:
[EMAIL PROTECTED]
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail:
[EMAIL PROTECTED]
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
