On Fri, 19 Jan 2001, Sam Horrocks wrote:
You know, I had brief look through some of the SpeedyCGI code yesterday,
and I think the MRU process selection might be a bit of a red herring.
I think the real reason Speedy won the memory test is the way it spawns
processes.
Please take
I think the major problem is that you're assuming that just because
there are 10 constant concurrent requests, that there have to be 10
perl processes serving those requests at all times in order to get
maximum throughput. The problem with that assumption is that there
is only one CPU - ten
I guess as I get older I start to slip technically. :) This helps me a bit,
but it doesn't really help me understand the final arguement (that MRU is
still going to help on a fully loaded system).
With some modification, I guess I am thinking that the cook is really the
OS and the CPU is
I have a wide assortment of queries on a site, some of which take several minutes to
execute, while others execute in less than one second. If understand this analogy
correctly, I'd be better off with the current incarnation of mod_perl because there
would be more cashiers around to serve the
I guess as I get older I start to slip technically. :) This helps me a bit,
but it doesn't really help me understand the final arguement (that MRU is
still going to help on a fully loaded system).
With some modification, I guess I am thinking that the cook is really the
OS and the
There is no coffee. Only meals. No substitutions. :-)
If we added coffee to the menu it would still have to be prepared by the cook.
Remember that you only have one CPU, and all the perl interpreters large and
small must gain access to that CPU in order to run.
Sam
I have a wide
I have just gotten around to reading this thread I've been saving for a
rainy day. Well, it's not rainy, but I'm finally getting to it. Apologizes
to those who hate when when people don't snip their reply mails but I am
including it so that the entire context is not lost.
Sam (or others who
Les Mikesell wrote:
[cut]
I don't think I understand what you mean by LRU. When I view the
Apache server-status with ExtendedStatus On, it appears that
the backend server processes recycle themselves as soon as they
are free instead of cycling sequentially through all the available
Sam Horrocks wrote:
A few things:
- In your results, could you add the speedycgi version number (2.02),
and the fact that this is using the mod_speedycgi frontend.
The version numbers are gathered at runtime, so for mod_speedycgi,
this would get picked up if you registered it in
Let me just try to explain my reasoning. I'll define a couple of my
base assumptions, in case you disagree with them.
- Slices of CPU time doled out by the kernel are very small - so small
that processes can be considered concurrent, even though technically
they are handled
Sam Horrocks wrote:
Don't agree. You're equating the model with the implemntation.
Unix processes model concurrency, but when it comes down to it, if you
don't have more CPU's than processes, you can only simulate concurrency.
[...]
This url:
Does this mean that mod_perl's memory hunger will curbed in the future using some of
the neat tricks in Speedycgi?
Perrin Harkins wrote:
Sam Horrocks wrote:
Don't agree. You're equating the model with the implemntation.
Unix processes model concurrency, but when it comes down to it,
Buddy Lee Haystack wrote:
Does this mean that mod_perl's memory hunger will curbed in the future using some of
the neat tricks in Speedycgi?
Yes. The upcoming mod_perl 2 (running on Apache 2) will use MRU to
select threads. Doug demoed this at ApacheCon a few months back.
- Perrin
- Original Message -
From: "Sam Horrocks" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: "mod_perl list" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Saturday, January 06, 2001 6:32 AM
Subject: Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts
th
Sam Horrocks wrote:
Don't agree. You're equating the model with the implemntation.
Unix processes model concurrency, but when it comes down to it, if you
don't have more CPU's than processes, you can only simulate concurrency.
Hey Sam, nice module. I just installed your SpeedyCGI for
Right, but this also points out how difficult it is to get mod_perl
tuning just right. My opinion is that the MRU design adapts more
dynamically to the load.
How would this compare to apache's process management when
using the front/back end approach?
Same thing applies.
A few things:
- In your results, could you add the speedycgi version number (2.02),
and the fact that this is using the mod_speedycgi frontend.
The fork/exec frontend will be much slower on hello-world so I don't
want people to get the wrong idea. You may want to benchmark
- Original Message -
From: "Sam Horrocks" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; "mod_perl list" [EMAIL PROTECTED]
Sent: Saturday, January 06, 2001 4:37 PM
Subject: Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts
th
Are the speedycgi+Apache processes smaller than the mod_perl
processes? If not, the maximum number of concurrent requests you can
handle on a given box is going to be the same.
The size of the httpds running mod_speedycgi, plus the size of speedycgi
perl processes is
Sorry for the late reply - I've been out for the holidays.
By the way, how are you doing it? Do you use a mutex routine that works
in LIFO fashion?
Speedycgi uses separate backend processes that run the perl interpreters.
The frontend processes (the httpd's that are running
t: Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts
that contain un-shared memory
Are the speedycgi+Apache processes smaller than the mod_perl
processes? If not, the maximum number of concurrent requests you can
handle on a given box is going to be the same.
The
Hi Sam,
I think we're talking in circles here a bit, and I don't want to
diminish the original point, which I read as "MRU process selection is a
good idea for Perl-based servers." Your tests showed that this was
true.
Let me just try to explain my reasoning. I'll define a couple of my
base
Gunther Birznieks wrote:
Sam just posted this to the speedycgi list just now.
[...]
The underlying problem in mod_perl is that apache likes to spread out
web requests to as many httpd's, and therefore as many mod_perl interpreters,
as possible using an LRU selection processes for picking
I think you could actually make speedycgi even better for shared memory
usage by creating a special directive which would indicate to speedycgi to
preload a series of modules. And then to tell speedy cgi to do forking of
that "master" backend preloaded module process and hand control over to
Perrin Harkins wrote:
[cut]
Doesn't that appear to be saying that whichever process gets into the
mutex first will get the new request? In my experience running
development servers on Linux it always seemed as if the the requests
would continue going to the same process until a request
Gunther Birznieks wrote:
Sam just posted this to the speedycgi list just now.
[...]
The underlying problem in mod_perl is that apache likes to spread out
web requests to as many httpd's, and therefore as many mod_perl interpreters,
as possible using an LRU selection processes for
Folks, your discussion is not short of wrong statements that can be easily
proved, but I don't find it useful.
I don't follow. Are you saying that my conclusions are wrong, but
you don't want to bother explaining why?
Would you agree with the following statement?
Under apache-1,
At 09:16 PM 12/21/00 +0100, Stas Bekman wrote:
[much removed]
So the moment mod_perl 2.0 hits the shelves, this possible benefit
of speedycgi over mod_perl becomes irrelevant. I think this more or less
summarizes this thread.
I think you are right about the summarization. However, I also think
I've put your suggestion on the todo list. It certainly wouldn't hurt to
have that feature, though I think memory sharing becomes a much much smaller
issue once you switch to MRU scheduling.
At the moment I think SpeedyCGI has more pressing needs though - for
example multiple scripts in a
I really wasn't trying to work backwards from a benchmark. It was
more of an analysis of the design, and the benchmarks bore it out.
It's sort of like coming up with a theory in science - if you can't get
any experimental data to back up the theory, you're in big trouble.
But if you can at least
[EMAIL PROTECTED] (Perrin Harkins) wrote:
Hi Sam,
[snip]
I am saying that since SpeedyCGI uses MRU to allocate requests to perl
interpreters, it winds up using a lot fewer interpreters to handle the
same number of requests.
What I was saying is that it doesn't make sense for one to need
31 matches
Mail list logo
