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 prerequisite.
Fastcgi
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:
Working on making a
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
instead of mod_php is
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
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 hardly
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 only
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 that what is meant
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 Spek
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 document
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't it???
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 a
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 point
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
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
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, liking it so
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
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
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
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 about
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 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 file system?
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
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 mean
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 away
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
/could/
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 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 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 that
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 general
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 lot of
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 it, but it
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
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 greatly. On
34 matches
Mail list logo
