ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> modperl
modperl
RE: Modperl/Apache deficiencies... Memory usage.
by Valter Mazzola other posts by this author
Apr 19 2000 8:28PM messages near this date
RE: Proxy hijackers? | Re: Implementing security in CGI
> From: "Jeff Stuart" <jstuart@[...].net>
> To: "Gunther Birznieks" <gunther@[...].com>, <modperl@[...].org>
> Subject: RE: Modperl/Apache deficiencies... Memory usage.
> Date: Tue, 18 Apr 2000 02:07:24 -0400
> 
> I understand that.  :)  And that was something that I had to learn myself.
> :)  It's a BAD thing when suddenly your httpd process takes up 100 MB.  :)
> It's just that it sounded like Shane was saying that his httpds were
> starting OUT at 4 to 6 MB.  That sounded a little unusual to me but then
> again, I've pared down my httpd config so that I don't have things in that 
> I
> don't need.
> 
> I'm just curious as to what he has in there.

Why not post here the .conf files and then compare them ?

> 
> --
> Jeff Stuart
> jstuart@[...].net
> 
> -----Original Message-----
> From: Gunther Birznieks [mailto:gunther@[...].com]
> Sent: Tuesday, April 18, 2000 1:24 AM
> To: modperl@[...].org
> Subject: RE: Modperl/Apache deficiencies... Memory usage.
> 
> If you aren't careful with your programming, an apache HTTPD can always
> grow pretty quickly because Perl never releases the RAM it allocates
> previously. While it does that reference count garbage collection, that is
> internal to the RAM that was allocated.
> 
> Let's say you need to sort a record set returned from a DBI call in an
> unusual perl-like way. If you do this "in memory", you need an array to
> hold the entire recordset in memory at once. If you do this, though, you
> will allocate the RAM for that one request that sorted the array and then
> the HTTPD will remain that size forever.
> 
> Keeping the higher RAM allocation is good for performance if you have the
> RAM of course. So this is one of those design tradeoffs. And Perl was not
> really written to be a persistent language, so again, the tradeoff of
> operational speed seems to make sense versus persistent memory usage.
> 
> Later,
>     Gunther
> 
> At 12:25 AM 4/18/00 -0400, Jeff Stuart wrote:
>  >Shane, question for you.  No offense intended here at all but what do you
>  >have in your apache servers (other than mod_perl) that use 4 to 6 MB?  
> I've
>  >got one server that I'm working on that handles close 1 Mil hits per day
>  >than runs WITH mod_perl that uses 4 to 6 MB.  ;-)  Without mod_perl, it
>  >takes up around 500 to 800 KB.   Now on another server my mod_perl server
>  >uses about 13 Mb per but it's my devel machine so I've got a lot of stuff
>  >loaded that I wouldn't have in a production server.
>  >
>  >--
>  >Jeff Stuart
>  >jstuart@[...].net
>  >
>  >-----Original Message-----
>  >From: shane@[...].com [mailto:shane@[...].com]
>  >Sent: Saturday, April 15, 2000 6:46 PM
>  >To: Perrin Harkins
>  >Cc: modperl@[...].org
>  >Subject: Re: Modperl/Apache deficiencies... Memory usage.
>  >
>  >Your apache processes would be the size of a stock
>  >apache process, like 4-6M or so, and you would have 1 process that
>  >would be 25MB or so that would have all your registry in it.
> 
> __________________________________________________
> Gunther Birznieks (gunther.birznieks@extropia.com)
> Extropia - The Web Technology Company
> http://www.extropia.com/
> 

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved