> 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
> > 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
> 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
> This doesn't affect the argument, because the core of it is that:
>
> a) the CPU will not completely process a single task all at once; instead,
> it will divide its time _between_ the tasks
> b) tasks do not arrive at regular intervals
> c) tasks take varying amounts of time to complete
he "quick cups of coffee" 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,
#x27;mod_perl|speedy|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
t; Could you clarify this with a simpler example? Maybe 4 processes and a
> sample timeline of what happens to those when there are enough requests to
> keep all 4 busy all the time for speedyCGI and a mod_perl backend?
>
> At 04:32 AM 1/6/01 -0800, Sam Horrocks wrote:
> > &g
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
> 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
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 if
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
yCGI uses MRU, mod_perl-2 will eventually use 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'
fast websites, then you will get more people looking for more
> power, and by extension more people using mod_perl.
>
> Whoops... here we go with the advocacy thing again.
>
> Later,
> Gunther
>
> At 02:50 AM 12/21/2000 -0800, Sam Horrocks wrote:
> > > Gunth
> 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
17 matches
Mail list logo
