On 8/16/07, Jen mlists <[EMAIL PROTECTED]> wrote:
> Is it possible to write speed limit module (for file downloading) by
> modperl rather than using Apache's official module?
Yes, you have the full Apache API available to you from mod_perl. If
you look on CPAN, you may find so
Hello list,
Is it possible to write speed limit module (for file downloading) by
modperl rather than using Apache's official module?
Thanks.
Octavian Rasnita wrote:
I don't think this is the problem, because that site shows more articles,
and each article has a counter that appears on the page. I am trying only
articles that have the counter 0, so nobody visited that page so MySQL
couldn't make a cache of that specific query.
My bes
ers so slow.
> Could be that MySQL has the queries cached in memory for some pages which
would be a substantial
> speed increase. Other times, these queries might not be cached.
Depending on how much memory
> you have available for the DB and how often the queries get used
determines whats cu
On Mon, 2005-08-22 at 20:47 +0300, Octavian Rasnita wrote:
> No. Unfortunately not. The server has no load, because it is a test server
> and I am the only user.
> It works locally, so the internet connection speed is not an issue either.
Sounds like an HTTP browser-compatibility prob
be a substantial
speed increase. Other times, these queries might not be cached. Depending on
how much memory
you have available for the DB and how often the queries get used determines
whats currently in the cache.
--
END
What doesn'
From: "Randy Kobes" <[EMAIL PROTECTED]>
Subject: Re: speed
>
> I assume, for the delay problem, you've ruled out
> correlations with a (momentary) high server load?
>
No. Unfortunately not. The server has no load, because it is a test server
and I am the on
Randy Kobes wrote:
At least for linux, the Apache::DB module (see especially
Apache::SmallProf) may help in tracking down where the
script is spending most of its time.
Actually, I'm thiking you mean Apache::DProf just make sure you look it EARLY
enough
as Perrin has said before to other poster
On Sat, 20 Aug 2005, Octavian Rasnita wrote:
Hi,
I have made a site using mod_perl with ModPerl::Registry.
It works much faster than using a simple cgi script, but
it still works slow sometimes and I would like to change
some things.
There are 3 situations:
1. The page is displayed pretty
Please tell me how I can test:
- Why that 404 error appears
- Why sometimes it takes so long to display the same kind of page
other
times displays much faster
- How can I test where the script hangs, which part of the script
is so slow
I'd look into your apache error logs
you can also d
Hi,
I have made a site using mod_perl with ModPerl::Registry.
It works much faster than using a simple cgi script, but it still works slow
sometimes and I would like to change some things.
There are 3 situations:
1. The page is displayed pretty fast (less than a second)
2. The same kind of pag
UPDATE: I hadn't done much testing when I wrote this... Well, after a bit
more testing they don't wait for each other apparently...
Sorry for filling up your mailbox...
But the actual question remains: How to optimize this web app? I'll send
more questions later with more details...
Thanks f
Hi all,
My mod_perl web app uses memcached to cache most of the (MySQL) database
query results and as the session storage (Apache::Session::Memcached). When
doing performance tests with httperf, I found that apache processes waits
for each other. I mean: all requests are accepted (apache forks
First, give dprofpp the flag that makes it sort by wall time, not by CPU
time. Otherwise, things that take most of the time in the average program,
like I/O, will appear to be very fast.
Second, make sure you initialize the debugger before loading any of the
code that you want to profile, l
On Mon, 15 Aug 2005 11:42:52 -0400
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> Frank Wiles wrote:
> > Give Apache::SmallProf a try. Where Apache::DProf shows you the
> > subroutine calls, SmallProf will show you a profile on a line by
> > line basis. This should help you zero in on what is
Frank Wiles wrote:
Give Apache::SmallProf a try. Where Apache::DProf shows you the
subroutine calls, SmallProf will show you a profile on a line by line
basis. This should help you zero in on what is causing the slowness.
I'd say just the opposite in most cases. Usually you want to see
Badai Aqrandista wrote:
I doubt the ApacheHandler::handler subroutine runs that long, because it
only shows the accumulated time used by other subroutines it calls. That
makes the profile isn't really accurate. How do I make it to show the
statistics of the subroutines called from the handler?
On Mon, 15 Aug 2005 14:59:00 +1000
"Badai Aqrandista" <[EMAIL PROTECTED]> wrote:
> I doubt the ApacheHandler::handler subroutine runs that long, because
> it only shows the accumulated time used by other subroutines it
> calls. That makes the profile isn't really accurate. How do I make it
> to
n't really accurate. How do I make it to show the
statistics of the subroutines called from the handler?
Thank you...
---
Badai Aqrandista
Cheepy (?)
From: "Philip M. Gollucci" <[EMAIL PROTECTED]>
To: Badai Aqrandista <[EMAIL PROTECTED]>
CC: modperl@perl.apache.o
(I only try to improve the speed of the code, so the use of proxy
shouldn't be relevant here - I think, I could be wrong).
You might try using
Apache::DProf
and/or
Apache::SmallProf
available here to see where your code is spending its time
http://search.cpan.org/~fwiles/Apache-DB
4 months. The older version uses
Apache::Registry, slightly modified cgi scripts and procedural perl modules.
Whereas the new version is a rewrite of all those into object oriented
modules, with Template Toolkit as the templating system. The code has become
much more manageable now.
However,
d create a simple perl script (like "$x++ for (1..100)")
> and Benchmark them on both hosts.
Hi all,
Thanks for all the advice. I found out what the problem was - it
wasn't related to mod_perl at all (web4 was hard-coded to retrieve
some dynamic data from an old, slow backe
Run "perl -V" on both hosts and check if there are any differences
between the output, mainly on "Platform" and "Compile-time options" sections.
Also, you could create a simple perl script (like "$x++ for (1..100)")
and Benchmark them on both hosts.
HTH,
Sergio.
On Thu, 6 Jan 2005, Alex G
On Thu, 2005-01-06 at 12:39 -0800, Jay Scherrer wrote:
> With FC3 and SElinux threads are more prevalent. I thought thats why I
> was upgrading to Apache2. Use of better threading technology.
On Linux, I recommend you use preforking, not threads, with mod_perl 2.
It uses far less memory than th
Why are you using Apache1.3?
Have tried compiling Apache2 with MP2?
With FC3 and SElinux threads are more prevalent. I thought thats why I
was upgrading to Apache2. Use of better threading technology.
On Thursday 06 January 2005 10:15 am, Alex Greg wrote:
> Hi,
>
>
> Recently I've upgraded on
ompiler for a little
> more speed, would that mean that mod_perl would also have to be
> compiled with the Intel compiler?
I think that's a wonderful idea. Do Perl, mod_perl, and Apache for
the whole package.
According to http://www.intel.com/software/products/compilers/
On Thu, 06 Jan 2005 14:40:20 -0500, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-01-06 at 19:35 +, Alex Greg wrote:
> > Any further advice would be appreciated, before I take the next step
> > and compile my own Perl.
>
> The final variable here is the kernel. There may be somethi
cting location available for
download. Hmmm, if it was compiled with Intel's compiler for a little
more speed, would that mean that mod_perl would also have to be compiled
with the Intel compiler?
- Perrin
onfig --list on the FC3 box is as follows:
If these are servers I would also turn off the following:
atd (unless you use it)
netfs (unless of course you use it)
gpm
kudzu (you can always turn it back on when you change hardware)
autofs
autofs will help speed up things a touch,
On Thu, 2005-01-06 at 19:35 +, Alex Greg wrote:
> Any further advice would be appreciated, before I take the next step
> and compile my own Perl.
The final variable here is the kernel. There may be something about the
kernel differences between the releases that favors apache's process
model.
On Thu, 6 Jan 2005 12:40:01 -0600, Frank Wiles <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Jan 2005 18:15:27 +
> Alex Greg <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> >
> > Recently I've upgraded one of our mod_perl servers to Fedora Core 3
> > (the others are all running Fedora Core 1).
> >
> >
> >
On Thu, 06 Jan 2005 12:01:35 -0700
"John D. Sanders" <[EMAIL PROTECTED]> wrote:
> Sorry for butting in here but you have piqued my curiosity. Is it
> better to do a minimal install of RHAS and build up from there with
> source or should I use what ships and just add to it.
This is starting t
In message <[EMAIL PROTECTED]>, Perrin Harkins wr
ites:
>How can you tell, and what can you do about it? Any specific info would
>be greatly appreciated.
OS issues might be best pinpointed by benchmarking the two httpd's on the
two Fedora's but w/o modperl loaded.
John
[EMAIL PROTECTED]
On Thu, 06 Jan 2005 13:56:11 -0500
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-01-06 at 12:40 -0600, Frank Wiles wrote:
> > While I agree recompling Perl will help, you might also look into
> > whether or not SELinux is slowing you down.
>
> How can you tell, and what can you do
Sorry for butting in here but you have piqued my curiosity. Is it
better to do a minimal install of RHAS and build up from there with
source or should I use what ships and just add to it.
On Thu, 2005-01-06 at 12:40 -0600, Frank Wiles wrote:
While I agree recompling Perl will he
On Thu, 2005-01-06 at 12:40 -0600, Frank Wiles wrote:
> While I agree recompling Perl will help, you might also look into
> whether or not SELinux is slowing you down.
How can you tell, and what can you do about it? Any specific info would
be greatly appreciated.
Regarding recompiling perl,
On Thu, 6 Jan 2005 18:15:27 +
Alex Greg <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
> Recently I've upgraded one of our mod_perl servers to Fedora Core 3
> (the others are all running Fedora Core 1).
>
>
> What I've found is that the Fedora Core 3 machine is consistently
> slower to respond than
In message <[EMAIL PROTECTED]>, Alex Greg writes:
>We're using the Fedora Perl packages (perl-5.8.3-16 on FC1,
>perl-5.8.5-9 on FC3), but I have compiled Apache and mod_perl on all
>the machines from source, with the following command:
If you build your own Perl from source, you can remove the pot
Hi,
Recently I've upgraded one of our mod_perl servers to Fedora Core 3
(the others are all running Fedora Core 1).
What I've found is that the Fedora Core 3 machine is consistently
slower to respond than the Fedora Core 1 machines:
[EMAIL PROTECTED] root]# for f in web1 web2 web3 web4; do ec
_script_aliases2.0.conf
>
> LoadModule perl_module modules/mod_perl.so"
so I made the switch and that did the trick.
400% speed up going from 2 RPS to 8 RPS!
./ab -n 32 -c 4 http://web2.nrlmry.navy.mil:/nexsat-bin/nexsat.cgi
Requests per second:1.87 [#/sec] (mean)
To
./ab -n 3
Kent, Mr. John (Contractor) wrote:
Greetings ModPerl Gurus,
Not seeing any significant speed up in my cgi scripts using mod-perl (3.5 RPS) over
straight
Apache (3.2 RPS), unlike in the past.
So figure I must have something configured incorrectly. Hopefully someone can tell
me what I have wrong
Greetings ModPerl Gurus,
Not seeing any significant speed up in my cgi scripts using mod-perl (3.5 RPS) over
straight
Apache (3.2 RPS), unlike in the past.
So figure I must have something configured incorrectly. Hopefully someone can tell
me what I have wrong.
Successfully built:
[Fri Jul 09
42 matches
Mail list logo
