Hi there,
On Wed, 18 Jun 2003, Trevor Phillips wrote:
Whether it's i686 or i386 - both mod_perl and FastCGI are using the same
compile of perl - so what difference should there be?
Must have got my wires crossed somewhere - I thought you must be using
different Perls.
73,
Ged.
Trevor Phillips [EMAIL PROTECTED] writes:
[...]
On my main dev box, ab gives an average of 8.8secs for the mod_perl
run, and 7.2secs for the FastCGI run. The internal timer and printed
output reflects these results too.
How does the cgi/command-line version stack up? AFAICT your test isn't
Joe Schaefer wrote:
Trevor Phillips [EMAIL PROTECTED] writes:
[...]
On my main dev box, ab gives an average of 8.8secs for the mod_perl
run, and 7.2secs for the FastCGI run. The internal timer and printed
output reflects these results too.
How does the cgi/command-line version stack up?
Stas Bekman wrote:
Joe Schaefer wrote:
I doubt that this makes any difference. I think what makes the
difference is
the fact that the mod_perl handler is setup via .htaccess. Have you
tried setting it in httpd.conf? Otherwise it's parsed on each request,
no surprises that it's slower.
Eh? How
On Friday 13 June 2003 23:00, you wrote:
[ please keep it on the list ]
Oops. Sorry. Used to mail lists auto-replying to the list. ^_^;;
On Fri, 2003-06-13 at 03:23, Trevor Phillips wrote:
I don't think so. Pretty standard Debian install, Perl 5.6.1...
And you compiled both mod_perl and
Hi there,
On Tue, 17 Jun 2003, Trevor Phillips wrote:
[snip]
The speed problem is not a connect time problem - it's actual run-time of the
Perl code.
[snip]
The only common thing between all the systems with the problem is they're
using the i686 Debian package for mod_perl.
Do you know
On Tuesday 17 June 2003 18:18, Ged Haywood wrote:
Do you know for sure that the Per was compiled for i686? Maybe it was
compiled for i386, so it would run on just about anything but it can't
use a lot of the faster features found in later processors.
Whether it's i686 or i386 - both
On Wednesday 18 June 2003 11:30, Trevor Phillips wrote:
On my main dev box, ab gives an average of 8.8secs for the mod_perl run,
and 7.2secs for the FastCGI run. The internal timer and printed output
reflects these results too.
Oops! The internal timer wasn't accurate: Swap lines 35 36 of
Is there anything I may be missing about the general configuration or
environment of mod_perl which may be causing this strange situation?
Try profiling...
Some time ago I found my modperl app to be fairly slow because I
turned on use Carp (and was carping errors and warnings). After
Trevor Phillips wrote:
Benchmarking was done using an internal before and after check using
Time::HiRes (as well as various stages during processing) as well as using
ab to do multiple hits in succession.
If you use multiple threads in ab, a sub-optimal setting for the number
of processes can
On Friday 13 June 2003 13:57, Stas Bekman wrote:
Since your question is too broad to be able to easily pinpoint any problems
without spending some time with it, I'd suggest reading:
http://perl.apache.org/docs/1.0/guide/performance.html
if you haven't done that yet.
I have. Although it was
Trevor Phillips wrote:
On Friday 13 June 2003 13:57, Stas Bekman wrote:
Since your question is too broad to be able to easily pinpoint any problems
without spending some time with it, I'd suggest reading:
http://perl.apache.org/docs/1.0/guide/performance.html
if you haven't done that yet.
I
On Fri, Jun 13, 2003 at 01:16:48PM +0800, Trevor Phillips wrote:
On Friday 13 June 2003 12:26, Perrin Harkins wrote:
You're not giving us much to go on here. What kind of changes did you
make? Can you verify that you are running the correct versions of the
modules under mod_perl? Are
[ please keep it on the list ]
On Fri, 2003-06-13 at 03:23, Trevor Phillips wrote:
Two other possibilities are using a different version of Perl (like one
with theads and one without), or accidentally using the wrong version of
your modules.
I don't think so. Pretty standard Debian
I am baffled!
I have a quite complex application. Actually, it's more like a language. (Yes,
a language written in Perl... ^_^) I've written it as Perl Modules, and I
have a number of front-ends: normal CGI, FastCGI, command line, and Apache
Module.
When doing development, I predominantly work
Quoting Trevor Phillips [EMAIL PROTECTED]:
However, when I used the revised modules with the Apache Module, I'm only
getting a marginal performance increase!
Since the bulk of the work is being done by modules common to the Apache and
FastCGI front-ends, I am at a loss as to explain why
Trevor Phillips wrote:
My latest
set of changes have resulted in optimisation and given a decent speed
increase of up to 25% (depending on the exact usage) for complex pages.
However, when I used the revised modules with the Apache Module, I'm only
getting a marginal performance increase!
On Friday 13 June 2003 12:14, Cees Hek:
I'm far from new to mod_perl, so yes, I've checked all the obvious stuff.
- Are you only checking the first time you load the page? mod_perl still
needs to load all the perl modules on the first request to a page, unless
you have specifically
Trevor Phillips wrote:
[...]
Since your question is too broad to be able to easily pinpoint any problems
without spending some time with it, I'd suggest reading:
http://perl.apache.org/docs/1.0/guide/performance.html
if you haven't done that yet.
By the way, I don't understand your comment about
19 matches
Mail list logo
