On Jan 28, 2008 9:57 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek wrote:
> >
> > I agree that FastCGI is the better technical solution, I'm just
> > stating that neither the Apache documentation nor the PHP
> > documentation seems to state that. Even worse, they hardly do
On Jan 28, 2008, at 15:41, Akins, Brian wrote:
On 1/28/08 3:29 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
I agree that FastCGI is the better technical solution, I'm just
stating that neither the Apache documentation nor the PHP
documentation seems to state that. Even worse, they hardl
Olaf van der Spek wrote:
I agree that FastCGI is the better technical solution, I'm just
stating that neither the Apache documentation nor the PHP
documentation seems to state that. Even worse, they hardly document
the FastCGI way at all.
FastCGI is a technically subpar way to execute trusted,
On 1/28/08 3:29 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
> I agree that FastCGI is the better technical solution, I'm just
> stating that neither the Apache documentation nor the PHP
> documentation seems to state that. Even worse, they hardly document
> the FastCGI way at all.
The onl
On Jan 28, 2008 9:22 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> >> http://www.php.net/manual/en/
> >> faq.installation.php#faq.installation.apache2
> >
> > "If you feel you have to use a threaded MPM, look at a FastCGI
> > configuration where PHP is running in its own memory space."
> >
> > Is
On Jan 28, 2008, at 2:35 PM, Olaf van der Spek wrote:
On Jan 28, 2008 8:04 PM, Eric Covener <[EMAIL PROTECTED]> wrote:
On Jan 28, 2008 12:36 PM, Olaf van der Spek <[EMAIL PROTECTED]>
wrote:
On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]>
wrote:
On 1/24/08 3:14 PM, "Olaf van der Sp
On Jan 28, 2008 8:04 PM, Eric Covener <[EMAIL PROTECTED]> wrote:
> On Jan 28, 2008 12:36 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote:
> > > On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > >
On Jan 28, 2008 12:36 PM, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote:
> > On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Working on making a FastCGI based setup the recommended approach
> > > inste
On Jan 25, 2008 6:18 PM, Akins, Brian <[EMAIL PROTECTED]> wrote:
> On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
>
>
> > Working on making a FastCGI based setup the recommended approach
> > instead of mod_php is probably more important then async. Actually,
> > it's a prerequis
On 1/24/08 3:14 PM, "Olaf van der Spek" <[EMAIL PROTECTED]> wrote:
> Working on making a FastCGI based setup the recommended approach
> instead of mod_php is probably more important then async. Actually,
> it's a prerequisite.
Fastcgi is the "recommended way of using php and httpd 2, AFAIK. Isn'
> We were using normal worker MPM with keepalives for this test. The current
> "stable" event would have helped with idle keepalive threads, but the system
> didn't seem to care.
But when using mod_php, worker is not recommended, right?
I doubt prefork scales as well as worker.
Working on making
On 1/20/08 10:44 AM, "Graham Leggett" <[EMAIL PROTECTED]> wrote:
> In terms of space, caches are not infinite in size, but then neither are
> the majority of backend websites either.
73GB is pretty big for a reverse proxy cache. And fast SAS drives are
pretty cheap.
> Sure, but I think the po
On 1/19/08 6:29 PM, "Davi Arnaut" <[EMAIL PROTECTED]> wrote:
> This is true for expensive hardware and very well designed operating
> systems and file systems.. and the space is not infinite.
It depends on your definition of "expensive." All of our servers are fairly
"commodity." The new linux
Davi Arnaut wrote:
This is true for expensive hardware and very well designed operating
systems and file systems.. and the space is not infinite.
Not at all - commodity hardware will serve just as well.
The real killer in this case is the slow client, which can be one, two
or three orders of
Graham Leggett wrote:
> Davi Arnaut wrote:
>
>>> The proxy that the LiveJournal folks wrote, I think, copies all the data
>>> from the origin server into a file and then uses sendfile to send to the
>>> client...
>> Doesn't this limit the network bandwidth to the bandwidth of the disk
>> and/or fi
lör 2008-01-19 klockan 09:57 -0500 skrev Davi Arnaut:
> Doesn't this limit the network bandwidth to the bandwidth of the disk
> and/or file system?
Depends on the working set and your amount of memory.
If it's just temporary storage then no, as most data won't even hit the
disk.
If it's more o
fre 2008-01-18 klockan 16:17 -0500 skrev Akins, Brian:
> Paul Q and I have been kicking around the idea that even if we go to a
> completely async core, etc. that modules could mark some hooks as "blocking"
> and they would run basically how they do today. (One day, Paul, I'll
> actually think abo
Davi Arnaut wrote:
The proxy that the LiveJournal folks wrote, I think, copies all the data
from the origin server into a file and then uses sendfile to send to the
client...
Doesn't this limit the network bandwidth to the bandwidth of the disk
and/or file system?
Yes, and the effective band
On Jan 18, 2008, at 2:16 PM, Justin Erenkrantz wrote:
On Jan 18, 2008 10:52 AM, Akins, Brian <[EMAIL PROTECTED]> wrote:
Which is why I hate to see a ton of work go into async core if it
actually
does very little to help performance (or if it hurts it) and makes
writing
modules harder. It b
On Jan 18, 2008, at 12:03 PM, Akins, Brian wrote:
This is just some ramblings based on some observations, theories,
and tests.
Partially "devil's advocate" as well.
Most of us seem to have convinced our self that high performance
network
applications (including web servers) must be asynchr
Akins, Brian wrote:
> On 1/18/08 3:07 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote:
>> That's not even a consideration,
>> async is really for dynamic content, proxies, and other non-sendfile
>> content.
>
> For dynamic stuff, "X-sendfile" works well. (Just really starting to play
> with that
Akins, Brian wrote:
The proxy that the LiveJournal folks wrote, I think, copies all the data
from the origin server into a file and then uses sendfile to send to the
client...
The proxy enhancements that Niklas contributed do exactly this as well.
It has a number of other advantages, such as
On Fri, 18 Jan 2008, Ruediger Pluem wrote:
The proxy that the LiveJournal folks wrote, I think, copies all the data
from the origin server into a file and then uses sendfile to send to the
client...
Erm, so does the one we wrote, mod_disk_cache ;p
IMHO it doesn't for the first request of the
On Jan 18, 2008 2:30 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> IMHO it doesn't for the first request of the entity (the request that causes
> the entity to be cached)
I'd expect the predominance of large numbers would reduce the impact
of the one-time performance hit...but that conversion aw
On 01/18/2008 10:29 PM, Colm MacCarthaigh wrote:
> On Fri, Jan 18, 2008 at 04:17:16PM -0500, Akins, Brian wrote:
>> For dynamic stuff, "X-sendfile" works well. (Just really starting to play
>> with that, liking it so far).
>
> It's not a solve-all though, I mean even though CGI's or whatever
> /
On Fri, Jan 18, 2008 at 04:17:16PM -0500, Akins, Brian wrote:
> For dynamic stuff, "X-sendfile" works well. (Just really starting to play
> with that, liking it so far).
It's not a solve-all though, I mean even though CGI's or whatever
/could/ write their output to a file and then call X-sendfile,
On 1/18/08 3:07 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote:
> That's not even a consideration,
> async is really for dynamic content, proxies, and other non-sendfile
> content.
For dynamic stuff, "X-sendfile" works well. (Just really starting to play
with that, liking it so far).
The proxy
On Fri, Jan 18, 2008 at 02:31:11PM -0500, Akins, Brian wrote:
> On 1/18/08 2:20 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote:
>
> > I think so, in some environments anyway. If you have a server tuned for
> > high throughput accross large bandwidth-delay product links then you
> > have the ge
On 1/18/08 2:20 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote:
> I think so, in some environments anyway. If you have a server tuned for
> high throughput accross large bandwidth-delay product links then you
> have the general problem of equal-priority threads sitting around with
> quite a lo
On 1/18/08 2:16 PM, "Justin Erenkrantz" <[EMAIL PROTECTED]> wrote:
> Speaking for myself, I think writing and using buckets with serf is
> more straightforward than our complicated bucket brigade system with
> mixed push/pull paradigms.
It very well may be.
Async may be easy. Except when my db
On Fri, Jan 18, 2008 at 01:52:02PM -0500, Akins, Brian wrote:
> On 1/18/08 12:18 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote:
> > Hmmm, it depends what you mean by scale really. Async doesn't help a
> > daemon scale in terms of concurrency or throughput, if anything it might
> > even impede i
On Jan 18, 2008 10:52 AM, Akins, Brian <[EMAIL PROTECTED]> wrote:
> Which is why I hate to see a ton of work go into async core if it actually
> does very little to help performance (or if it hurts it) and makes writing
> modules harder. It braindead simple nowadays to write well behaved high
> pe
On 1/18/08 12:18 PM, "Colm MacCarthaigh" <[EMAIL PROTECTED]> wrote:
> Hmmm, it depends what you mean by scale really. Async doesn't help a
> daemon scale in terms of concurrency or throughput, if anything it might
> even impede it, but it certainly can help improve latency and
> responsivity grea
On Fri, Jan 18, 2008 at 12:03:02PM -0500, Akins, Brian wrote:
> Most of us seem to have convinced our self that high performance network
> applications (including web servers) must be asynchronous in order to scale.
> Is this still valid? For that matter, was it ever?
Hmmm, it depends what you mea
This is just some ramblings based on some observations, theories, and tests.
Partially "devil's advocate" as well.
Most of us seem to have convinced our self that high performance network
applications (including web servers) must be asynchronous in order to scale.
Is this still valid? For that mat
35 matches
Mail list logo
