Leslie Mikesell [EMAIL PROTECTED] writes:
I agree that it is correct to serve images from a lightweight server
but I don't quite understand how these points relate. A proxy should
avoid the need to hit the backend server for static content if the
cache copy is current unless the user hits
According to Greg Stark:
1) Netscape/IE won't intermix slow dynamic requests with fast static requests
on the same keep-alive connection
I thought they just opened several connections in parallel without regard
for the type of content.
Right, that's the problem. If the two
Leslie Mikesell [EMAIL PROTECTED] writes:
The 'something happens' is the part I don't understand. On a unix
server, nothing one httpd process does should affect another
one's ability to serve up a static file quickly, mod_perl or
not. (Well, almost anyway).
Welcome to the real world
Gerald Richter wrote:
No, that's the size of the system call buffer. It is not an
application buffer.
So how one should interpret the info at:
http://www.apache.org/docs/mod/mod_proxy.html#proxyreceivebuffersize
QUOTE
The ProxyReceiveBufferSize directive specifies an explicit
According to Greg Stark:
I think if you can avoid hitting a mod_perl server for the images,
you've won more than half the battle, especially on a graphically
intensive site.
I've learned the hard way that a proxy does not completely replace the need to
put images and other other static
Vivek Khera [EMAIL PROTECTED] writes:
Squid does indeed cache and buffer the output like you describe. I
don't know if Apache does so, but in practice, it has not been an
issue for my site, which is quite busy (about 700k pages per month).
I think if you can avoid hitting a mod_perl
"G.W. Haywood" [EMAIL PROTECTED] writes:
Would it be breaching any confidences to tell us how many
kilobyterequests per memorymegabyte or some other equally daft
dimensionless numbers?
I assume the number you're looking for is an ideal ratio between the proxy and
the backend server? No
On 20 Jan 2000, Greg Stark wrote:
I tried to use the minspareservers and maxspareservers and the other similar
parameters to let apache tune this automatically and found it didn't work out
well with mod_perl. What happened was that starting up perl processes was the
single most cpu intensive
On Tue, 18 Jan 2000, Stas Bekman wrote:
I'm still confused... which is the right scenario:
1) a mod_perl process generates a response of 64k, if the
ProxyReceiveBufferSize is 64k, the process gets released immediately, as
all 64k are buffered at the socket, then a proxy process comes in,
I looked at mod_proxy and found the pass thru buffer size
is IOBUFSIZ, it reads that from the remote server then
writes to the client, in a loop.
Squid has 16K.
Neither is enough.
In an effort to get those mod_perl daemons to free up for long
requests, it is possible to patch mod_proxy to read as
Vivek Khera [EMAIL PROTECTED] writes:
This has infinite more flexibility than squid, and allows me to have
multiple personalities to my sites. See for example the sites
http://www.morebuiness.com and http://govcon.morebusiness.com
If when you say "multiple personalities", you mean virtual
On 17 Jan 2000, Michael Alan Dorman wrote:
Vivek Khera [EMAIL PROTECTED] writes:
This has infinite more flexibility than squid, and allows me to have
multiple personalities to my sites. See for example the sites
http://www.morebuiness.com and http://govcon.morebusiness.com
If when you
Gerald Richter wrote:
I have seen this in the source too, that's why I wrote it will not work with
Apache, because most pages will be greater the 8K. Patching Apache, is one
possibility, that's right, but I just looked after the
ProxyReceiveBufferSize which Oleg pointed to, and this one
On Mon, 17 Jan 2000, Gerald Richter wrote:
Look at proxy_http.c line 263 (Apache 1.3.9):
if (setsockopt(sock, SOL_SOCKET, SO_RCVBUF,
(const char *) conf-recv_buffer_size, sizeof(int))
I am not an expert in socket programming, but the setsockopt man page on my
On Sun, 16 Jan 2000, DeWitt Clinton wrote:
[...]
On that topic, is there an alternative to squid? We are using it
exclusively as an accelerator, and don't need 90% of it's admittedly
impressive functionality. Is there anything designed exclusively for this
purpose?
At ValueClick we can't
Hi there,
On Mon, 17 Jan 2000, Joshua Chamas wrote:
On Solaris, default seems to be 256K ...
As I remember, that's what Linux defalts to. Don't take may word for
it, I can't remember exactly where or when I read it - but I think it
was in this List some time during the last couple of months!
Hi there,
On Mon, 17 Jan 2000, Ask Bjoern Hansen wrote:
At ValueClick we can't use the caching for obvious reasons so we're using
a bunch of apache/mod_proxy processes in front of the apache/mod_perl
processes to save memory.
Even with our average 1KB per request we can keep hundreds of
So, if you want to increase RCVBUF size above 65535, the default max
value, you have to raise first the absolut limit in
/proc/sys/net/core/rmem_max,
Is "echo 131072 /proc/sys/net/core/rmem_max" the proper way to do this? I don't have
much experience with /proc, but this seems to work. If
On Mon, 17 Jan 2000, Markus Wichitill wrote:
So, if you want to increase RCVBUF size above 65535, the default max
value, you have to raise first the absolut limit in
/proc/sys/net/core/rmem_max,
Is "echo 131072 /proc/sys/net/core/rmem_max" the proper way to do
this? I don't
On Mon, 17 Jan 2000, G.W. Haywood wrote:
At ValueClick we can't use the caching for obvious reasons so we're using
a bunch of apache/mod_proxy processes in front of the apache/mod_perl
processes to save memory.
Even with our average 1KB per request we can keep hundreds of mod_proxy
No, that's the size of the system call buffer. It is not an
application buffer.
So how one should interpret the info at:
http://www.apache.org/docs/mod/mod_proxy.html#proxyreceivebuffersize
QUOTE
The ProxyReceiveBufferSize directive specifies an explicit network buffer
size
Hi Stas,
Yes, as Joshua posted today morning (at least it was morning in
germany :-),
the application buffer size is hardcoded, the size is 8192 (named
IOBUFSIZE). You will find it in proxy_util.c:ap_proxy_send_fb().
The ProxyReceiveBufferSize set the receive buffer size of the
Yes, as Joshua posted today morning (at least it was morning in
germany :-),
the application buffer size is hardcoded, the size is 8192 (named
IOBUFSIZE). You will find it in proxy_util.c:ap_proxy_send_fb().
The ProxyReceiveBufferSize set the receive buffer size of the socket, so
On Fri, 14 Jan 2000 [EMAIL PROTECTED] wrote:
Hi, I am switching my modperl site to squid in httpd acclerator mode
and everything works as advertised, but was very surprised to find
squid 10x slower than apache on a cached 6k gif as measured by
apache bench... 100 requests/second vs almost
DeWitt Clinton wrote:
On Fri, 14 Jan 2000 [EMAIL PROTECTED] wrote:
Hi, I am switching my modperl site to squid in httpd acclerator mode
and everything works as advertised, but was very surprised to find
squid 10x slower than apache on a cached 6k gif as measured by
apache bench...
On Sun, 16 Jan 2000, Steven Lembark wrote:
given you have the core to support it... try using libmm and
a tied hash to just stash the stuff until it's asked for.
Actually, we are currently developing a generic object caching interface
that will support a TTL based on expiration dates, and
Vivek Khera wrote:
Woulnd't running mod_perl on the front end kinda defeat the whole
purpose of an accelerator?
Perhaps not. The thing that adds the most heft to my httpd processes is
the Oracle libraries. Mod_perl processes can be very small if they
aren't linking in a bunch of libraries.
Lately I've been using apache on the front end with mod_rewrite and
mod_proxy to send mod_perl-required page requests to the heavy back
end. This has infinite more flexibility than squid, and allows me to
have multiple personalities to my sites. See for example the sites
28 matches
Mail list logo
