New to this list, so I'm sure that this has been covered, but hoping
someone can point me in the right direction. Hope this doesn't make you
laugh too hard, being such a newbie. Don't know where to turn, but don't
want to abandon this project.
I've been unsuccessful at trying to get mod_perl to
Tom,
I never build on RedHat, I consider it a
prepackage type distribution; If the package you need is not available you are
out of luck.
If you want to build tools, go to a
distribution set up with a clean build environment: I recommend slackware or one
of these derivatives.
I
Hi Tom
Here's the install script that I walk through to install Apache 2,
mod_perl 2 and libapreq. Done it on a number of machines including
redhat, and it works for me.
You may get errors along the way because of missing libraries. Just
install them and repeat the last step.
It installs apach
Tom,
I've had no trouble with Red Hat packages and Apache or mod_perl in
the past.. but last time I did that, RH9 was just out. I can recommend
the following installation plan for Apache. It always worked for me,
on various linux dists.
http://www.delouw.ch/linux/apache.phtml
There is also a XA
All this stuff (apache, mod_perl, etc) builds fine on Redhat.
You certainly don't need to change from Redhat to some other
distribution just to build apache and mod_perl.
All you need to do is *ignore* the Redhat packages.
Simply download and build apache and mod_perl, just as you
would anywhere
Hi,
I've been looking for a good technique to find out what module is
using all my memory.
Imagine some sneaky user creates this module:
package MemoryHog;
my %big_hash;
sub handler {
my $r = shift;
foreach (1..1_000_000) {
$big_hash{$_} = $_ * 5;
}
On Thu, 22 Jun 2006 10:27:32 -0500
Chris Werner <[EMAIL PROTECTED]> wrote:
> Tom,
> I never build on RedHat, I consider it a prepackage type
> distribution; If the package you need is not available you are out of
> luck.
That's not really fair to RH in my opinion. If the package doesn't
exi
Patrick Rutkowski wrote:
Are the t/apr-ext/*.t tests supposed to fail? No matter how hard to try
I always get this on OpenBSD 3.9 with perl 5.8.8, Apache-2.2.2 and
mod_perl-2:
I think its due a lack of testing on openbsd. I don't think any of the
developers
have an openbsd box handy. I do at
Sagar R. Shah wrote:
t/apache/content_length_header.t 271 3.70% 17
t/api/status.t 62 33.33% 4-5
These are expected and fixed already in SVN (me). 2.0.3 will include this.
No code changes, just test changes as to account for httpd compl
Ed Eddington wrote:
-8<-- Start Bug Report 8<--
1. Problem Description:
After doing a subrequest, the ENV hash is being cleared of everything
except MOD_PERL and MOD_PERL_API_VERSION. The ENV is normal within the
subrequest and immediately after, but ENV
On Thu, 22 Jun 2006, mark wrote:
> Date: Thu, 22 Jun 2006 09:06:59 -0700
> From: mark <[EMAIL PROTECTED]>
> To: Chris Werner <[EMAIL PROTECTED]>
> Cc: Tom Weber <[EMAIL PROTECTED]>, modperl@perl.apache.org
> Subject: Re: Basic Help, RedHat
>
> All this stuff (apache, mod_perl, etc) builds fine
On Thu, 2006-06-22 at 11:20 -0700, Jay Buffington wrote:
> I'm considering writing a PerlLogHandler that will print out the
> memory usage (using GTop) before and after each request so I can find
> the offending code path.
That's what I would do. You could also keep track of the size in a
global
On Mon, 2006-06-19 at 22:48 -0500, Matthew wrote:
>We are finally ready to move to our mod_perl2 handler. I just
> finished running some tests against our old CGI (no PerlRun, no
> Registry, just plain jane CGI).
>
>The results were basically the same. I did 500 requests, 2
> concurents
How could a CGI using ModPerl::Registry be faster than a Perl-Script
running under mod_perl? When I say 'faster', I'm talking a few tenths
of a second to half a second using Apache Benchmark (ab).
What really gets the water boiling is that the CGI is coded 'worse' (ie:
no strict, no warning,
Both are reporting:
Will look into Apache::DProf
-Matthew
Perrin Harkins wrote:
On Mon, 2006-06-19 at 22:48 -0500, Matthew wrote:
We are finally ready to move to our mod_perl2 handler. I just
finished running some tests against our old CGI (no PerlRun, no
Registry, just plain jane CGI).
On Thu, 2006-06-22 at 18:04 -0500, Matthew wrote:
> What really gets the water boiling is that the CGI is coded 'worse' (ie:
> no strict, no warning, every var a global var, etc..).
There must be something in your new code that is coded in a way that
makes it slow. A profiler like Apache::DProf
Hello,
A few months ago, I wrote to this group because
external redirects for requests from internal
redirects were not working while redirects from normal
requests worked fine. I was running in registry mode
and was told that that was probably the source of the
problem. However, I have changed
17 matches
Mail list logo