Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-19 Thread Perrin Harkins
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-18 Thread Sam Horrocks
> 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

RE: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-18 Thread Stephen Anderson
> -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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-17 Thread Sam Horrocks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-17 Thread Sam Horrocks
> 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-17 Thread Buddy Lee Haystack
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 "

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-17 Thread Gunther Birznieks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-17 Thread Sam Horrocks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-13 Thread Gunther Birznieks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-08 Thread Keith G. Murphy
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-07 Thread Joshua Chamas
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Les Mikesell
- 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Sam Horrocks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Sam Horrocks
> > 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Joshua Chamas
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Les Mikesell
- 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Perrin Harkins
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Buddy Lee Haystack
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Perrin Harkins
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-06 Thread Sam Horrocks
> 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-05 Thread Sam Horrocks
> > > 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-04 Thread Perrin Harkins
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-04 Thread Les Mikesell
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2001-01-04 Thread Sam Horrocks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Ken Williams
[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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Sam Horrocks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Sam Horrocks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Gunther Birznieks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Sam Horrocks
> 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,

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Sam Horrocks
> 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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Keith G. Murphy
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Gunther Birznieks
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

Re: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

2000-12-21 Thread Perrin Harkins
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