Hi,
On my test server running Red Hat Linux 7.1 Linux version 2.4.2-2
shared memory is 18.71 MB
On my production server Red Hat Linux 7.3 Linux version 2.4.20-20.7
shared memory is 4.32 MB
use GTop;
my $gtop = GTop->new;
my $share = $gtop->proc_mem($$)->share;
I've also noticed the same diff
Hi,
On my test server running Red Hat Linux 7.1 Linux version 2.4.2-2
shared memory is 18.71 MB
On my production server Red Hat Linux 7.3 Linux version 2.4.20-20.7
shared memory is 4.32 MB
use GTop;
my $gtop = GTop->new;
my $share = $gtop->proc_mem($$)->share;
I've also noticed the same di
Hi,
On my test server running Red Hat Linux 7.1 Linux version 2.4.2-2
shared memory is 18.71 MB
On my production server Red Hat Linux 7.3 Linux version 2.4.20-20.7
shared memory is 4.32 MB
use GTop;
my $gtop = GTop->new;
my $share = $gtop->proc_mem($$)->share;
I've also noticed the same diff
We are concerned about how much memory we are using now
that we are moving to modperl.
Are there any good tools/procedures that we could use to
determine how much memory our application is currently using – and then
using that as a benchmark, determine how much more or less memory we ar
Hello list,
I'm developing a quite large project, using SOAP::Lite and some more
modules using mod_perl.
My main problem is: Memory Usage.
Currently, the apache processes take (each) about 150 MB memory,
what's quite a lot. Now, i've been wondering which module and why it
Hi. I'm trying to estimate (forecast) perl memory requirements for storing
simple lists (hashes) in memory.
If my lists use integers as keys and all values are either integers or
simple scalar strings (of maximum size each), can the total memory size be
estimated by simply factoring the total num
[ Please check your mail setup. This message was posted three times. ]
On Mon, 2004-05-10 at 01:45, Scott Ãlexänder wrote:
> On my test server running Red Hat Linux 7.1 Linux version 2.4.2-2
>
> shared memory is 18.71 MB
>
>
> On my production server Red Hat Linux 7.3 Linux version 2.4.20-20
Is there a way to do large queries that return lots of data without
having my apache process grow by the equivalent size in ram of the
data returned? The only thing I can think of is to run a separate
script outside of mod perl for queries like this.
Chris
hoping for something that can give me a view of all the memory
used and where, without having to click myself
2) I see process grow without stopping, even with reload. i assume
this is from the caveat in "PerlSetVar StatusTerseSizeMainSummary On" ?
3) memory usage on the
I suggest taking a look at the excellent mod_perl performance guide:
http://perl.apache.org/docs/1.0/guide/performance.html
-- Tobias
Zitat von "Daniel B. Hemmerich" <[EMAIL PROTECTED]>:
> We are concerned about how much memory we are using now that we are moving
> to modperl.
>
>
>
> Are ther
On Sep 1, 2006, at 11:15 AM, Daniel B. Hemmerich wrote:
We are concerned about how much memory we are using now that we are
moving to modperl.
Are there any good tools/procedures that we could use to determine
how much memory our application is currently using – and then using
that as a
On Friday 30 March 2007 14:00, Georg Grabler wrote:
> Initially, the apache processes take 42 MB each (i think this should
> be mostly shared memory and a lot of preloaded projects, as usual on
> a developer machine). If i connect using SOAP, the process jumps up
> to 140-150MB, and i just can't th
mode (httpd -X)
4. run the test script i wrote
5. see what apache status has to say.
if memory usage looked ok we can add some more code and retry, and we
might be able to figure out where the problem is.
http://perl.apache.org/docs/1.0/guide/performance.html
g you're
using 1.3.x or 2.x prefork):
*) Stop Apache
*) Change the value of StartServers parameter in http.conf to be equal
to MaxClients (say it's 'N')
*) Do `free -m` and note how much free memory you have (minus buffers/cache)
*) Start Apache, but make no requests yet
*) Do `free -m
On Mar 30, 2007, at 8:00 AM, Georg Grabler wrote:
Hello list,
I'm developing a quite large project, using SOAP::Lite and some more
modules using mod_perl.
My main problem is: Memory Usage.
If you search the archives using my name, you'll fine a ton of stuff
about me complaining
> My main problem is: Memory Usage.
> Currently, the apache processes take (each) about 150 MB memory,
> what's quite a lot. Now, i've been wondering which module and why it
> takes that much memory at all.
Check out this thread:
http://aspn.activestate.com/ASPN/Mail/M
Will Fould wrote:
> Hi. I'm trying to estimate (forecast) perl memory requirements for
> storing simple lists (hashes) in memory.
>
> If my lists use integers as keys and all values are either integers or
> simple scalar strings (of maximum size each), can the total memory size
> be estimated by
Michael Peters wrote:
Any links or discussion would be great.
You really need to benchmark it for yourself using the version you are
targetting and the OS. You can do it outside of apache and just have a simple
Perl script that does nothing but sleep after it's created the large data
struc
Hi Will,
How many keys will your hashes contain?
The main memory wastage with hashes isn't due to the size of what you
keep in them but the number of keys.
If you are using integers as keys, why not just use an array?
Bare in mind that the 'hashspace' is shared between your hashes, so if
you ha
erver gets so bogged
down when it happens that I can't access it to get info on running
processes, memory usage, etc. I have noticed that the memory usage of
each httpd process seems to grow over time, but it's usually very slow
growth, and I can't tell if that's really a
We're implementing a mod_perl module for a pretty high traffic site,
I've run some benchmarks and our mod_perl code, doing the same job as
our current (proprietry module) is 30-40% faster. However, the memory
usage of mod_perl is substantially larger**.
Having tweaked mod_perl
Chris Ochs wrote:
Is there a way to do large queries that return lots of data without
having my apache process grow by the equivalent size in ram of the
data returned?
Yes. Many databases support sending the results a few rows at a time
instead of all at once. For specific advice on this, you mi
Perrin Harkins wrote:
Chris Ochs wrote:
Is there a way to do large queries that return lots of data without
having my apache process grow by the equivalent size in ram of the
data returned?
Yes. Many databases support sending the results a few rows at a time
instead of all at once. For specific
> > Yes. Many databases support sending the results a few rows at a time
> > instead of all at once. For specific advice on this, you might check
> > your DBD documentation or ask on the dbi-users list. You can also have
> > your program schedule the current apache process to exit after finishin
Is there a way to do large queries that return lots of data without
having my apache process grow by the equivalent size in ram of the
data returned?
Yes. Many databases support sending the results a few rows at a time
instead of all at once. For specific advice on this, you might check
your DBD
>
> Also ask yourself if you really need all of the data at
> once. You may be able to filter it down in the query or
> build some incremental data structures using row-by-row
> iteration instead of fetchall_arrayref.
Ya I do, it's basically a customer list export from the database that
I write o
On Mon, 17 Jan 2005 17:46:17 -0800, Chris Ochs wrote:
> It looks like $r->child_terminate does what I need. In the case of
> Postgresql it eats the memory when you execute the query, regardless
> of whether you actually fetch any results.
That can be worked around, however. By using a cursor, you
On Jan 17, 2005, at 11:44 PM, Chris Ochs wrote:
Also ask yourself if you really need all of the data at
once. You may be able to filter it down in the query or
build some incremental data structures using row-by-row
iteration instead of fetchall_arrayref.
Ya I do, it's basically a customer list exp
On Tue, 18 Jan 2005 10:43:02 +, Peter Haworth
<[EMAIL PROTECTED]> wrote:
> On Mon, 17 Jan 2005 17:46:17 -0800, Chris Ochs wrote:
> > It looks like $r->child_terminate does what I need. In the case of
> > Postgresql it eats the memory when you execute the query, regardless
> > of whether you ac
>> > It looks like $r->child_terminate does what I need. In the case of
>> > Postgresql it eats the memory when you execute the query, regardless
>> > of whether you actually fetch any results.
>>
>> That can be worked around, however. By using a cursor, you can specify
>> exactly how much data yo
>> > It looks like $r->child_terminate does what I need. In the case of
>> > Postgresql it eats the memory when you execute the query, regardless
>> > of whether you actually fetch any results.
>>
>> That can be worked around, however. By using a cursor, you can specify
>> exactly how much data yo
On Tue, 18 Jan 2005 10:12:06 -0800, Chris Ochs wrote:
> On Tue, 18 Jan 2005 10:43:02 +, Peter Haworth
> <[EMAIL PROTECTED]> wrote:
> > By using a cursor, you can specify exactly how much data you want
> > at a time:
>
> DBD::Pg doesn't support cursors. From the DBD::PG manpage:
>
> "Although
to interesting times :)
..Theo
-Original Message-
From: Fred Moyer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 18, 2005 2:11 PM
To: Chris Ochs
Cc: Peter Haworth; modperl@perl.apache.org
Subject: Re: DBI memory usage
>> > It looks like $r->child_terminate does what I need. In the
I did some tests, some interesting results
my processes no longer seem to be 300mb. which is good. however,
when that happened, i was seeing a 300mb process and then 6mb in a
child. now i'm back to seemingly unshared memory.
based on my tests below, i *think* that it may have been becaus
Michael - depends on the OS - but you could look at the Apache::SizeLimit
code which allows kills processes when the memory per process gets large
works well for the system we use at work...
If on a unix/linux based system "top" is your friend as it will indicate
the memory usage p
--- On Sun, 6/15/08, James Smith <[EMAIL PROTECTED]> wrote:
> From: James Smith <[EMAIL PROTECTED]>
> Subject: Re: Diagnosing memory usage
> To: "Michael Gardner" <[EMAIL PROTECTED]>
> Cc: modperl@perl.apache.org
> Date: Sunday, June 15, 2008, 11:13
On Sun, 15 Jun 2008 21:09:23 -0500
Michael Gardner <[EMAIL PROTECTED]> wrote:
> Workarounds would be helpful, but naturally I'd prefer to eliminate
> the cause of the problem. I've been looking through the
> documentation, but haven't made much progress so far. How can I get
> to the bottom of t
ternatively any good ways of reducing the memory usage any further,
> I would be very grateful.
Most of the documentation on reducing memory usage is here:
http://perl.apache.org/docs/1.0/guide/performance.html
> The issue arises because we need to run up
> to 800 apache process on ea
Perrin Harkins wrote:
** Yes the obvious solution to this is to go with threaded
Actually, reports so far are that running mod_perl 2 with threaded MPMs
on Linux actually takes more memory because it breaks the copy-on-write
sharing. Preforking is more efficient.
I'd like to second Perrin. Start
Hi, all.
I'm looking for suggestions, information, may be atricles about
different memory usage issues concerned with mod_perl1.
On one Russian forum man posted an review of memory "leaks"(caveats):
sub handler
{
my $r = shift;
$r->send_http_
Greetings,
I have some questions about optimizing memory usage. I could probably
get
some of these answers myself with more study of the mod_perl / perl source,
but I was hoping someone might just know the answer and be able to tell me :)
First off, am I correct in the
Hi. I have a leak somewhere and I'm trying to find it
using Apache2::Status. Individual usage of memory in
the packages and functions doesn't grow, and I'm unable
to use the "memory usage" of Apache2::Status, so I can
see further.
Any hint about solving this issue with A
At 13:36 2003-09-25 +0400, you wrote:
Hi, all.
I'm looking for suggestions, information, may be atricles about different
memory usage issues concerned with mod_perl1.
Hi there,
This contains some pretty good tips...
Code Profiling and Memory Measurement Techniques
On Thu, 2003-09-25 at 05:36, Ruslan U. Zakirov wrote:
> I'm looking for suggestions, information, may be atricles about
> different memory usage issues concerned with mod_perl1.
The best information about this kind of tuning is at
http://perl.apache.org/ and in the book "Practica
On Thu, 2005-12-15 at 01:15 -0600, Chase Venters wrote:
> I could probably get
> some of these answers myself with more study of the mod_perl / perl source,
> but I was hoping someone might just know the answer and be able to tell me :)
Not a great way to start your post. Please read this:
http
On Thursday 15 December 2005 03:35 pm, Perrin Harkins wrote:
> Not a great way to start your post. Please read this:
> http://modperlbook.org/html/ch10_01.html
My apologies. I do own the book and I have read it, but it was some time ago
and I didn't remember that some of my questions were addres
On Fri, 2005-12-16 at 03:33 -0600, Chase Venters wrote:
> Well, I should have been more clear here that I was no longer talking about
> prefork. What I meant by COW here was actually that if you were going to use
> multiplicity with Perl_clone, since the threads would share memory, Perl
> would
And BDB would be dependency creep, which
is quite difficult to fight in perl sometimes (that's just because there are
a zillion useful CPAN modules) :)
Personally, I don't fight it. I just use zillions of CPAN modules.
Amen.
On Fri, 16 Dec 2005, Perrin Harkins wrote:
It will probably be big. Perl structures tend to use several times the
size of the actual data they store.
That's what I'm worried about then I suppose.
is this root hash, its keys / values / etc stored along with variables, or is
it in the op tree
On Fri, 2005-12-16 at 11:52 -0600, Chase Venters wrote:
> I wonder then if Perl would be smart enough to understand that the data is
> constant and not copy it with Perl_clone()?
I'm pretty sure the answer is no. You can try marking things shared
with threads::shared and see if that gets you any
On Fri, 16 Dec 2005 12:51:36 -0500 (EST)
"Philip M. Gollucci" <[EMAIL PROTECTED]> wrote:
>
> >> And BDB would be dependency creep, which
> >> is quite difficult to fight in perl sometimes (that's just because
> >> there are a zillion useful CPAN modules) :)
> >
> > Personally, I don't fight it.
Chase Venters wrote:
> On Thursday 15 December 2005 03:35 pm, Perrin Harkins wrote:
>
>>Not a great way to start your post. Please read this:
>>http://modperlbook.org/html/ch10_01.html
>
>
> My apologies. I do own the book and I have read it, but it was some time ago
> and I didn't remember th
Francesc Guasch wrote:
> So I'm trying to use Apache2::Status "Memory Usage", but It
> won't work with my MP2, look:
install the latest of all of the following modules from CPAN.
B::Graph
B::TerseSize
(particulary this one ... the mp2 api change needs th
Francesc Guasch wrote:
Hi. I have a leak somewhere and I'm trying to find it
using Apache2::Status. Individual usage of memory in
the packages and functions doesn't grow, and I'm unable
to use the "memory usage" of Apache2::Status, so I can
see further.
Francesc, try
Stas Bekman wrote:
> You also need to be aware that shared memory reporting on linux 2.6
> kernel is invalid. I don't know if it was fixed in the most recent
> kernel releases.
2.6.14+ fixes this
--
"Love is not the o
En/na Philip M. Gollucci ha escrit:
Francesc Guasch wrote:
So I'm trying to use Apache2::Status "Memory Usage", but It
won't work with my MP2, look:
install the latest of all of the following modules from CPAN.
B::Graph
B::TerseSize
(particulary this one ... the
En/na Stas Bekman ha escrit:
> Francesc Guasch wrote:
>
>> Hi. I have a leak somewhere and I'm trying to find it
>> using Apache2::Status. Individual usage of memory in
> Francesc, try to bracket your handlers for memory usage using this
> approach:
> http:/
Have setup perl-status according to the information in Practical
mod_perl (Ch9.4), and am using Apache/2.2.3 mod_perl/2.0.2 on a Linux
system running the XAMPP package. All perl-status functions seem to work
OK, except memory usage which generates a 500 error:
[Wed Sep 12 11:45:59 2007
I'm creating some fairly big scalars (6 megs) under mod_perl containing
strings, and was doing some memory profiling using Apache::Status. I
noticed at the end of the memory usage for a particular sub, in a
module, there is a 'PADLIST summary', and that there is some hefty
memory u
uot;-p -sC"
Whan I access perl-status, I get the following menu items:
Environment
Loaded Modules
Inheritance Tree
ISA Tree
HTML::Mason status
Perl Configuration
Compiled Registry Scripts
PerlRequire'd Files
Signal Handlers
Memory Usage
Symbol Table Dump
Everything works fine except
On 9/12/07, Richard Jones <[EMAIL PROTECTED]> wrote:
> Both packages referred to in the error message are installed and up to date
Do you have more than one perl on this system? Maybe XAMPP installs a
separate one.
- Perrin
Perrin Harkins wrote:
On 9/12/07, Richard Jones <[EMAIL PROTECTED]> wrote:
Both packages referred to in the error message are installed and up to date
Do you have more than one perl on this system? Maybe XAMPP installs a
separate one.
Yes, XAMPP has its own Perl, but I ensure I install pack
On 9/12/07, Richard Jones <[EMAIL PROTECTED]> wrote:
> I'm pretty sure the XAMPP Apache server is using its own Perl rather
> than the default /usr/bin/perl as I have a large number of dependencies
> for my mod_perl web apps which do not exist under the default perl lib
> path.
Check it by finding
Perrin Harkins wrote:
On 9/12/07, Richard Jones <[EMAIL PROTECTED]> wrote:
I'm pretty sure the XAMPP Apache server is using its own Perl rather
than the default /usr/bin/perl as I have a large number of dependencies
for my mod_perl web apps which do not exist under the default perl lib
path.
C
On 9/12/07, Richard Jones <[EMAIL PROTECTED]> wrote:
> /opt/lampp/bin/perl -e 'print join "\n", @INC':
No, print @INC from mod_perl, not from the command line.
- Perrin
Perrin Harkins wrote:
On 9/12/07, Richard Jones <[EMAIL PROTECTED]> wrote:
/opt/lampp/bin/perl -e 'print join "\n", @INC':
No, print @INC from mod_perl, not from the command line.
Sorry, yes that was silly. From an equivalent script inside the /perl
directory (which is set in perl.conf to
On 9/13/07, Richard Jones <[EMAIL PROTECTED]> wrote:
> /opt/lampp/lib/perl5/site_perl/5.8.7/Devel/Symdump.pm
Ok, the next thing to try is a permissions check. Become the user who
you run your web server as (often "nobody", but I don't know what
XAMPP does) and try to read this file.
- Perrin
Perrin Harkins wrote:
On 9/13/07, Richard Jones <[EMAIL PROTECTED]> wrote:
/opt/lampp/lib/perl5/site_perl/5.8.7/Devel/Symdump.pm
Ok, the next thing to try is a permissions check. Become the user who
you run your web server as (often "nobody", but I don't know what
XAMPP does) and try
On 9/14/07, RA Jones <[EMAIL PROTECTED]> wrote:
> Yes, user 'nobody' gets a display on 'cat
> /opt/lampp/lib/perl5/site_perl/5.8.7/Devel/Symdump.pm'
Okay, can you try making your own mod_perl handler that loads
Devel::Symdump and see if it works?
- Perrin
Perrin Harkins wrote:
On 9/14/07, RA Jones <[EMAIL PROTECTED]> wrote:
Yes, user 'nobody' gets a display on 'cat
/opt/lampp/lib/perl5/site_perl/5.8.7/Devel/Symdump.pm'
Okay, can you try making your own mod_perl handler that loads
Devel::Symdump and see if it works?
Sorry it's taken a while.
Richard Jones wrote:
> gives me a nice Data::Dumper data structure in the browser window. It
> probably doesn't make much sense as programming logic as I don't
> normally use Devel::Symdump, but I guess it shows the module is OK?
The original error message was this:
[Wed Sep 12 11:45:59 2007] [e
libraries be shared across all
of the programs that use them, or could I reduce the memory usage by merging
all of the programs into one larger program (a maintenance problem, but worth
while if it saves memory)?
I also use a PerlRequire startup.pl to preload most modules (CGI, DBI), but I
Mark Maunder wrote:
I'm creating some fairly big scalars (6 megs) under mod_perl containing
strings, and was doing some memory profiling using Apache::Status. I
noticed at the end of the memory usage for a particular sub, in a
module, there is a 'PADLIST summary', and that ther
I
> > noticed at the end of the memory usage for a particular sub, in a
> > module, there is a 'PADLIST summary', and that there is some hefty
> > memory usage by certain variables.
> >
> > I researched padlist and from what I can gather, perl doesn't ent
ing that makes a lot more things work too.
The only caveat of that, is that 'memory usage' doesn't appear on /
perl-status/ until you visit a symdump page that contains memory-
usage. i don't know why. but that should only happen on situations
already afflicted
ubs->{$keys[0]}->{size};
i'll have more fixes as time progresses
==
Jonathan | 13 Aug 00:56
ok, also found
I also figured this out:
in B::TerseSize, line 634
- my $script = $q->script_name;
+ my $script ;
+ if ( defined $q && $q )
+ {
+ $script = $q->scri
David Scott wrote:
The following patch makes life a lot easier:
in B::TerseSize:
631c631
< my $script = $q->script_name;
---
> my $script = ( defined $q && $q ) ? $q->script_name : $r->uri;
The problem is, the Apache 2 API doesn't use CGI query objects at all so
you can't use the scr
Thomas Hilbig wrote:
I have about a dozen small cgi programs under mod_perl2 that all pretty well
look like this..
use CGI;
use DBI;
use perlchartdir ; # graphing
To think about how this works under mod_perl, pretend that all of your scripts are put together into
1 larger script and all t
--- On Fri, 10/17/08, Michael Peters <[EMAIL PROTECTED]> wrote:
> To think about how this works under mod_perl, pretend that
> all of your scripts are put together into
> 1 larger script and all those "use" statements
> are repeated. Does having multiple "use CGI"
> statements make your script us
I also use a PerlRequire startup.pl to preload most modules (CGI, DBI),
but I thought that was only for quicker startup times and not for sharing
memory. Is that correct?
Preloading helps with speed (you don't get the the initial loading hit for
a module the first time it's used in a specific
--- On Mon, 10/20/08, Carl Johnstone <[EMAIL PROTECTED]> wrote:
> From: Carl Johnstone <[EMAIL PROTECTED]>
> Subject: Re: Reducing memory usage using fewer cgi programs
> To: "Michael Peters" <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Cc: modperl@perl.apache
but "massive" scripts (those that
have large memory structures and take several seconds to execute) is to
place these in a non-mod_perl directory so I can be assured their memory
usage goes away at the end of the response.
<<<<<
There's no reason not to run these unde
Carl Johnstone wrote:
Something else I will do for my low-usage but "massive" scripts (those
that have large memory structures and take several seconds to execute)
is to place these in a non-mod_perl directory so I can be assured their
memory usage goes away at the end of th
On Fri, Oct 24, 2008 at 8:57 AM, Carl Johnstone
<[EMAIL PROTECTED]> wrote:
> If you're really concerned and would rather the child process quits and
> frees additional memory to the OS, then call $r->child_terminate in any of
> your handlers, and the child process will automatically quit at the end
On 24.10.2008 15:03 Michael Peters wrote:
> This is only true if those structures were created during run time and go out
> of scope at run time.
> If they are generated at compile time or attached to global variables or
> package level variables,
> they will not be re-used by Perl.
Wait a mi
our preloading.
You may want to look at Linux::Smaps
http://search.cpan.org/author/OPI/Linux-Smaps-0.06/lib/Linux/Smaps.pm
and at smem.pl (a script which uses Linux::Smaps to print out memory
usage of a process)
http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html
to get some
Michael Lackhoff wrote:
On 24.10.2008 15:03 Michael Peters wrote:
This is only true if those structures were created during run time and go out of scope at run time.
If they are generated at compile time or attached to global variables or package level variables,
they will not be re-used by Pe
On 25.10.2008 13:34 Clinton Gormley wrote:
> I think there was some confusion here about what was being said.
>
> Michael Peters' comment about memory reuse was saying that:
> - if at runtime, you load a large memory structure
> - then let those variables go out of scope
> - then that memory w
On Sat, Oct 25, 2008 at 7:32 AM, André Warnier <[EMAIL PROTECTED]> wrote:
> And they do "remember" some things between consecutive runs of scripts
> or modules. That is usually undesirable, because it can give nasty
> errors : a variable that you declare with "my $var" and that you expect
> to be
On Sat, Oct 25, 2008 at 7:34 AM, Clinton Gormley <[EMAIL PROTECTED]> wrote:
> Michael Peters' comment about memory reuse was saying that:
> - if at runtime, you load a large memory structure
> - then let those variables go out of scope
> - then that memory will be come available for reuse by Perl
I won't try to speak for Michael, but technically that memory does not
become available for reuse by Perl, even if they are lexical variables
and they go out of scope, unless you explicitly undef the variables.
Perl keeps the memory for them allocated as a performance
optimization.
That was the
I am not that far, yet. I am doing all my development work under Windows
and only for production I will use Linux (or Solaris if it needs bigger
iron).
Something to bear in mind then is that apache on Windows is (usually)
multi-threaded rather than multi-process. So a lot of the discussion in t
Hola --
We're playing with a large OO Perl 5 project under mod_perl.
Apache/2.0.48 (Unix) mod_perl/1.99_13 Perl/v5.8.3 mod_ssl/2.0.48 OpenSSL/0.9.7d
Linux 2.4.21-192-default #1 i686 i686 i386 GNU/Linux
(SuSe)
The project is a beast: some 150 OO classes are used to perform operations. The memor
On Fri, 2004-03-19 at 11:51, Jay Hannah wrote:
> If we're using mod_perl (and startup.pl) correctly what ballpark
> memory footprint should we expect to see when we run, say, 10
> simultaneous clients against the server?
>
> Should we expect a RAM footprint something like
>10 30MB httpd's
>
Hi there,
On Fri, 19 Mar 2004, Jay Hannah wrote:
> We're playing with a large OO Perl 5 project under mod_perl.
:(
> Apache/2.0.48 (Unix) mod_perl/1.99_13 Perl/v5.8.3 mod_ssl/2.0.48 OpenSSL/0.9.7d
> Linux 2.4.21-192-default #1 i686 i686 i386 GNU/Linux
> (SuSe)
That's an old kernel, I'd think i
Ged Haywood wrote:
[...]
There's a lot of useful information about performance tuning in the
mod_perl Guide, including suggestions for things like proxy setups
where a few mod_perl servers do the heavy Perl processing and a lot
of small non-mod_perl servers do most of the communicating with clients
96 matches
Mail list logo