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.
>
> Ple
> Hello Sam and others
>
> If I haven't overseen, nobody so far really mentioned fastcgi. I'm
> asking myself why you reinvented the wheel. I summarize the
> differences I see:
>
> + perl scripts are more similar to standard CGI ones than with
> FastCGI (downside: see next point)
Agr
> -Original Message-
> From: Sam Horrocks [mailto:[EMAIL PROTECTED]]
> Sent: 17 January 2001 23:37
> To: Gunther Birznieks
> Cc: [EMAIL PROTECTED]; mod_perl list; [EMAIL PROTECTED]
> Subject: Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl
> withscripts t
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 assortmen
> 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 an
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 CPU is reall
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 proce
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 ma
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 availabl
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 i
- 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 bett
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
> > 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 appl
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
- 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 bett
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
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
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:
>
> http://www.oreilly.com/catalog/li
> 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 ser
> > > 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 p
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 as
sday, January 04, 2001 6:56 AM
Subject: 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
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 mod_speedycg
[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
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
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 single
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
> 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,
> 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 pr
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 reque
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
t
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 pickin
33 matches
Mail list logo
