There's only one run queue in the kernel. THe first task ready to run is
put
at the head of that queue, and anything arriving afterwards waits. Only
if that first task blocks on a resource or takes a very long time, or
a higher priority process becomes able to run due to an
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 a look at that code again. There's no smoke
a mod_perl backend?
At 04:32 AM 1/6/01 -0800, Sam Horrocks wrote:
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 pro
edy|apache'
apache-1.3.9-4
speedycgi-2.02-1
apache-devel-1.3.9-4
speedycgi-apache-2.02-1
mod_perl-1.21-2
Here are some relevant parameters from my httpd.conf:
MinSpareServers 8
MaxSpareServers 20
StartServers 10
MaxClients 150
MaxRequestsPerChild 1
SpeedyMaxRuns 0
At 03:19 AM 1/17
offee" that many customers
request at my dinner.
Is this correct?
Sam Horrocks wrote:
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
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
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
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
This is planned for a future release of speedycgi, though there will
probably be an option to set a maximum number of bytes that can be
bufferred before the frontend contacts a perl interpreter and starts
passing over the bytes.
Currently you can do this sort of acceleration with script output
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,
here we go with the advocacy thing again.
Later,
Gunther
At 02:50 AM 12/21/2000 -0800, Sam Horrocks wrote:
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
we
MRU.
On Thu, 21 Dec 2000, Sam Horrocks wrote:
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
15 matches
Mail list logo
