Re: squid performance
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 the reload button and the browser sends the request with 'pragma: no-cache'. I'll try to expand a bit on the details: 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 types of content are coming from the same proxy server (as far as NS/IE is concerned) then they will intermix the requests and the slow page could hold up several images queued behind it. I actually suspect IE5 is cleverer about this, but you still know more than it does. By putting them on different hostnames the browser will open a second set of parallel connections to that server and keep the two types of requests separate. 2) static images won't be delayed when the proxy gets bogged down waiting on the backend dynamic server. Picture the following situation: The dynamic server normally generates pages in about 500ms or about 2/s; the mod_perl server runs 10 processes so it can handle 20 connections per second. The mod_proxy runs 200 processes and it handles static requests very quickly, so it can handle some huge number of static requests, but it can still only handle 20 proxied requests per second. Now something happens to your mod_perl server and it starts taking 2s to generate pages. The proxy server continues to get up to 20 requests per second for proxied pages, for each request it tries to connect to the mod_perl server. The mod_perl server can now only handle 5 requests per second though. So the proxy server processes quickly end up waiting in the backlog queue. Now *all* the mod_proxy processes are in "R" state and handling proxied requests. The result is that the static images -- which under normal conditions are handled quicly -- become delayed until a proxy process is available to handle the request. Eventually the backlog queue will fill up and the proxy server will hand out errors. This is a good idea because it is easy to move to a different machine if the load makes it necessary. However, a simple approach is to use a non-mod_perl apache as a non-caching proxy front end for the dynamic content and let it deliver the static pages directly. A short stack of RewriteRules can arrange this if you use the [L] or [PT] flags on the matches you want the front end to serve and the [P] flag on the matches to proxy. That's what I thought. I'm trying to help others avoid my mistake :) Use a separate hostname for your pictures, it's a pain on the html authors but it's worth it in the long run. -- greg
Re: squid performance
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 types of content are coming from the same proxy server (as far as NS/IE is concerned) then they will intermix the requests and the slow page could hold up several images queued behind it. I actually suspect IE5 is cleverer about this, but you still know more than it does. They have a maximum number of connections they will open at once but I don't think there is any concept of queueing involved. 2) static images won't be delayed when the proxy gets bogged down waiting on the backend dynamic server. Picture the following situation: The dynamic server normally generates pages in about 500ms or about 2/s; the mod_perl server runs 10 processes so it can handle 20 connections per second. The mod_proxy runs 200 processes and it handles static requests very quickly, so it can handle some huge number of static requests, but it can still only handle 20 proxied requests per second. Now something happens to your mod_perl server and it starts taking 2s to generate pages. 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). The proxy server continues to get up to 20 requests per second for proxied pages, for each request it tries to connect to the mod_perl server. The mod_perl server can now only handle 5 requests per second though. So the proxy server processes quickly end up waiting in the backlog queue. If you are using squid or a caching proxy, those static requests would not be passed to the backend most of the time anyway. Now *all* the mod_proxy processes are in "R" state and handling proxied requests. The result is that the static images -- which under normal conditions are handled quicly -- become delayed until a proxy process is available to handle the request. Eventually the backlog queue will fill up and the proxy server will hand out errors. But only if it doesn't cache or know how to serve static content itself. Use a separate hostname for your pictures, it's a pain on the html authors but it's worth it in the long run. That depends on what happens in the long run. If your domain name or vhost changes, all of those non-relative links will have to be fixed again. Les Mikesell [EMAIL PROTECTED]
Re: squid performance
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 however where "something" can and does happen. Developers accidentally put untuned SQL code in a new page that takes too long to run. Database backups slow down normal processing. Disks crash slowing down the RAID array (if you're lucky). Developers include dependencies on services like mail directly in the web server instead of handling mail asynchronously and mail servers slow down for no reason at all. etc. The proxy server continues to get up to 20 requests per second for proxied pages, for each request it tries to connect to the mod_perl server. The mod_perl server can now only handle 5 requests per second though. So the proxy server processes quickly end up waiting in the backlog queue. If you are using squid or a caching proxy, those static requests would not be passed to the backend most of the time anyway. Please reread the analysis more carefully. I explained that. That is precisely the scenario I'm describing faults in. -- greg
Re: squid performance
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 network buffer size for outgoing HTTP and FTP connections, for increased throughput. It has to be greater than 512 or set to 0 to indicate that the system's default buffer size should be used. /QUOTE So what's the application buffer parameter? A hardcoded value? 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 it's an OS issue. I've patched my frontend server so that there are two buffer sizes: ProxyReceiveBufferSize sets the socket buffer size ProxyInternalBufferSize sets the application buffer size This meant renaming ap_breate() to ap_bcreate_size() and adding a size parameter, which defaults to IOBUFSIZE if 0 is passed. Then add #define ap_bcreate(p,flags) ap_bcreate(p,flags,0) and add a new ap_bcreate() which calls ap_bcreate_size() for binary compatibility (actually I haven't added the new ap_bcreate() yet, and I never got round to sending this to the Apache development group). This is all necessary because some of the proxied pages on my site are large PDF and PS files which can't be cached due to security resaons. I have the socket buffer set to the max allowed 64K (on Solaris), with a 1M application buffer. In my opinion, ProxyReceiveBufferSize should be called ProxySocketBufferSize, leaving the old name free for my new use. This would also remove some of the confusion about what it actually does. -- Peter Haworth [EMAIL PROTECTED] "Save the whales. Feed the hungry. Free the mallocs."
Re: squid performance
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 components on a separate server. There are two reasons that you really really want to be serving images from another server (possibly running on the same machine of course). 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 the reload button and the browser sends the request with 'pragma: no-cache'. 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. 2) static images won't be delayed when the proxy gets bogged down waiting on the backend dynamic server. Is this under NT where mod_perl is single threaded? Serving a new request should not have any relationship to delays handling other requests on unix unless you have hit your child process limit. Eg, if the dynamic content generation becomes slow enough to cause a 2s backlog of connections for dynamic content, then a proxy will not protect the static images from that delay. Netscape or IE may queue those requests after another dynamic content request, and even if they don't the proxy server will eventually have every slot taken up waiting on the dynamic server. A proxy that already has the cached image should deliver it with no delay, and a request back to the same server should be serviced immediately anyway. So *every* image on the page will have another 2s latency, instead of just a 2s latency for the entire page. This is worst in Netscape of course course where the page can't draw until all the images sizes are known. Putting the sizes in the IMG SRC tag is a good idea anyway. This doesn't mean having a proxy is a bad idea. But it doesn't replace putting your images on pics.mydomain.foo even if that resolves to the same address and run a separate apache instance for them. This is a good idea because it is easy to move to a different machine if the load makes it necessary. However, a simple approach is to use a non-mod_perl apache as a non-caching proxy front end for the dynamic content and let it deliver the static pages directly. A short stack of RewriteRules can arrange this if you use the [L] or [PT] flags on the matches you want the front end to serve and the [P] flag on the matches to proxy. Les Mikesell [EMAIL PROTECTED]
Re: squid performance
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 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 components on a separate server. There are two reasons that you really really want to be serving images from another server (possibly running on the same machine of course). 1) Netscape/IE won't intermix slow dynamic requests with fast static requests on the same keep-alive connection 2) static images won't be delayed when the proxy gets bogged down waiting on the backend dynamic server. Both of these result in a very slow user experience if the dynamic content server gets at all slow -- even out of proportion to the slowdown. Eg, if the dynamic content generation becomes slow enough to cause a 2s backlog of connections for dynamic content, then a proxy will not protect the static images from that delay. Netscape or IE may queue those requests after another dynamic content request, and even if they don't the proxy server will eventually have every slot taken up waiting on the dynamic server. So *every* image on the page will have another 2s latency, instead of just a 2s latency for the entire page. This is worst in Netscape of course course where the page can't draw until all the images sizes are known. This doesn't mean having a proxy is a bad idea. But it doesn't replace putting your images on pics.mydomain.foo even if that resolves to the same address and run a separate apache instance for them. -- greg
Re: squid performance
"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 single number exists. You need to monitor your system and tune. In theory you can calculate it by knowing the size of the average request, and the latency to generate an average request in the backend. If your pages take 200ms to generate, and they're 4k on average, then they'll take 1s to spool out to a 56kbs link and you'll need a 5:1 ratio. In practice however that doesn't work out so cleanly because the OS is also doing buffering and because it's really the worst case you're worried about, not the average. If you have the memory you could just shoot for the most processes you can handle, something like 256:32 for example is pretty aggressive. If your backend scripts are written efficiently you'll probably find the backend processes are nearly all idle. 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 thing apache could do, so as soon as it decided it needed a new process it slowed down the existing processes and put itself into a feedback loop. I prefer to force apache to start a fixed number of processes and just stick with that number. -- greg
Re: squid performance
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 thing apache could do, so as soon as it decided it needed a new process it slowed down the existing processes and put itself into a feedback loop. I prefer to force apache to start a fixed number of processes and just stick with that number. This shouldn't happen if you preload most or all your code that you use. The fork is very effective on modern OSes, and since most use copy-on-write methodm the spawning of a new process should be almost unnoticeable. ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
RE: squid performance
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, picks 8k of data every time and sends down the wire. Yes. Or at least the mod_perl gets released quickly, also for responses 8KB. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 60M impressions per day, http://valueclick.com
Re: squid performance
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 much as you like in one gulp then write it.. Having done that, I am now pretty happy - mod_rewrite mod_proxy mod_forwarded_for in front of modperl works great.. just a handful of mod_perls can drive scores of slow readers! I think that is better than squid for those with this particular problem. -Justin On Mon, Jan 17, 2000 at 07:56:33AM -0800, Ask Bjoern Hansen wrote: 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 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 childs busy with very few active mod_perl childs. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 60M impressions per day, http://valueclick.com
Re: squid performance
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 hosts, then squid---at least recent versions---can do this as well. Mind you, the FAQ doesn't explain this at all, but the Users Guide at http://www.squid-cache.org/Doc/Users-Guide/detail/accel.html. Gives you all the details. You have to have a redirector process, but there are several out there (squirm, a couple of others), and the specs for building your own are really trivial---like five lines of perl for a basic shell. Now I've not done bench tests to see which of these options does the best (quickest, lowest load, etc) job, and of course familiarity with the configuration options counts for a lot---but I have to say (not that it's entirely pertinent) that even though I spend a lot more time with apache than squid, the times I've had to play with acls, I've found squid easier than apache. Now if you meant something else, well, I don't know what to say other than I think there are drugs that can help... Mike.
Re: squid performance
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 say "multiple personalities", you mean virtual hosts, then squid---at least recent versions---can do this as well. (plain) Apache can also serve static files (maybe after language/whatever negotiations etc), run CGI's and much more - as Vivek mentioned. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 60M impressions per day, http://valueclick.com
Re: squid performance
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 sets the socket options and therefore should do the same job (as far as the OS supports it). 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 Linux says: "The system places an absolut limit on these values", but doesn't says where this limit will be? On Solaris, default seems to be 256K ... tcp_max_buf Specifies the maximum buffer size a user is allowed to specify with the SO_SNDBUF or SO_RCVBUF options. Attempts to use larger buffers fail with EINVAL. The default is 256K. It is unwise to make this parameter much larger than the maximum buffer size your applications require, since that could allow malfunctioning or malicious applications to consume unreasonable amounts of kernel memory. I needed to buffer up to 3M files, which I did by dynamically allocating space in ap_proxy_send_fb. I didn't know that you could up the tcp_max_buf at the time, and would be interested in anyone's experience in doing so, whether this can actually be used to buffer large files. Save me a source tweak in the future. ;) -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
RE: squid performance
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 Linux says: "The system places an absolut limit on these values", but doesn't says where this limit will be? For 2.2 kernels the max limit is in /proc/sys/net/core/rmem_max and the default value is in /proc/sys/net/core/rmem_default. It's good to note the following comment from the kernel source: "Don't error on this BSD doesn't and if you think about it this is right. Otherwise apps have to play 'guess the biggest size' games. RCVBUF/SNDBUF are treated in BSD as hints." 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, otherwise you might be thinking that by calling setsockopt you increased it to say 1 MB, but in fact the RCVBUF size is still 65535. HTH, Radu Greab
Re: squid performance
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 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 childs busy with very few active mod_perl childs. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 60M impressions per day, http://valueclick.com
Re: squid performance
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! I needed to buffer up to 3M files, which I did by dynamically allocating space in ap_proxy_send_fb. For such large transfers between proxy and server, is there any reason why one shouldn't just dump it into a tempfile in a ramdisk for the proxy to deal with at its leisure, and let the OS take care of all the virtual and sharing stuff? After all, that's what it's for... 73 Ged.
Re: squid performance
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 mod_proxy childs busy with very few active mod_perl childs. Would it be breaching any confidences to tell us how many kilobyterequests per memorymegabyte or some other equally daft dimensionless numbers? 73, Ged.
RE: squid performance
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 it's ok, it could be added to the Guide, which already mentions how to change it in FreeBSD.
RE: squid performance
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 have much experience with /proc, but this seems to work. Yes, that's the way described in Linux kernel documentation and I use myself. So you should put this into /etc/rc.d/rc.local ? If it's ok, it could be added to the Guide, which already mentions how to change it in FreeBSD. I'd also like to see this info added to the Guide. Of course! Thanks for this factoid! ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: squid performance
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 childs busy with very few active mod_perl childs. Would it be breaching any confidences to tell us how many kilobyterequests per memorymegabyte or some other equally daft dimensionless numbers? Uh, I don't understand the question. The replies to the requests are all redirects to the real content (which is primarily served by Akamai) so it's quite non-typical. - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 60M impressions per day, http://valueclick.com
RE: squid performance
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 for outgoing HTTP and FTP connections, for increased throughput. It has to be greater than 512 or set to 0 to indicate that the system's default buffer size should be used. /QUOTE So what's the application buffer parameter? A hardcoded value? 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 it's an OS issue. Which means that setting of ProxyReceiveBufferSize higher than 8k is usless unless you modify the sources. Am I right? (I want to make it as clear as possible i in the Guide) ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
RE: squid performance
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 socket, so it's an OS issue. Which means that setting of ProxyReceiveBufferSize higher than 8k is usless unless you modify the sources. Am I right? (I want to make it as clear as possible i in the Guide) No, that means that Apache reads (and writes) the data of the request in chunks of 8K, but the OS is providing a buffer with the size of ProxyReceiveBufferSize (as far as you don't hit a limit). So the proxied request data is buffered by the OS and if the whole page fit's inside the OS buffer the sending Apache should be imediately released after sending the page, while the proxing Apache can read and write the data in 8 K chunks as slow as the client is. That's the result of the discussion. I didn't tried it out myself until now if it really behaves this way. I will do so the next time and let you know if I find any different behaviour. Gerald
RE: squid performance
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 it's an OS issue. Which means that setting of ProxyReceiveBufferSize higher than 8k is usless unless you modify the sources. Am I right? (I want to make it as clear as possible i in the Guide) No, that means that Apache reads (and writes) the data of the request in chunks of 8K, but the OS is providing a buffer with the size of ProxyReceiveBufferSize (as far as you don't hit a limit). So the proxied request data is buffered by the OS and if the whole page fit's inside the OS buffer the sending Apache should be imediately released after sending the page, while the proxing Apache can read and write the data in 8 K chunks as slow as the client is. Gerald, thanks for your answer. 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, picks 8k of data every time and sends down the wire. 2) a mod_perl process generates a response of 64k, a proxy request reads from mod_perl socket by 8k chunks and sends down the socket, No matter what's the client's speed the data gets buffered once again at the socket. So even if the client is slow the proxy server completes the proxying of 64k data even before the client was able to absorb the data. Thus the system socket serves as another buffer on the way to the client. 3) neither of them Also if the scenario 1 is the right one and it looks like: [ socket ] [mod_perl] = [ ] = [mod_proxy] = wire [ buffer ] When the buffer size is of 64k and the generated data is 128k, is it a shift register (pipeline) alike buffer, so every time a chunk of 8k is picked by mod_proxy, new 8k can enter the buffer. Or no new data can enter the buffer before it gets empty, i.e. all 64k get read by mod_proxy? As you understand the pipeline mode provides a better performance as it releases the heavy mod_perl process as soon as the amount of data awaiting to be sent to the client is equal to socket buffer size + 8k. I think it's not a shift register buffer type... Thank you! That's the result of the discussion. I didn't tried it out myself until now if it really behaves this way. I will do so the next time and let you know if I find any different behaviour. Gerald ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: squid performance
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 1000 for apache. I've experienced the same results with accelerating small static files. However, we still use squid on our site (www.eziba.com) because our httpd processes are so heavy, and to save a trip to the database for documents that are cachable, such as product images. We've found that the net performance gain to be noticeable. However, if all you are serving is static files that live on the same tier as the apache server, you'll probably be better of without squid. 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? Perhaps a modperl module that implements caching of files based on Expires headers? -DeWitt
Re: squid performance
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... 100 requests/second vs almost 1000 for apache. I've experienced the same results with accelerating small static files. However, we still use squid on our site (www.eziba.com) because our httpd processes are so heavy, and to save a trip to the database for documents that are cachable, such as product images. We've found that the net performance gain to be noticeable. However, if all you are serving is static files that live on the same tier as the apache server, you'll probably be better of without squid. 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? Perhaps a modperl module that implements caching of files based on Expires headers? How about mod_backhand? http://www.backhand.org/. It is capable of not only buffering, but also load balancing and failover. If all you want is buffering, it would be very easy to write a small program that accepted http requests and forwarded them to another daemon, then buffered the response. Perhaps this would be a good weekend project for one of us. I've been tinkering with the idea of writing an httpd. As much as I like Apache, there are many things I don't like about it, and a ton of functionality that I won't ever need. All I really want is a web server that: 1) Is multithreaded or otherwise highly parallel. 2) Has a request stage interface like Apache's 3) Uses async I/O Number 3 would releive us of this squid hack that we are all using. That doesn't seem too hard. I think I will write it. I'll need someone to hook in the Perl interpreter, though :) -jwb
Re: squid performance
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 implementing this in both Java and perl. Since the perl version will be used most in a multi-process environment (like apache/modperl) we'll back-end this on mmap. The java version will be used in both our middle tier (a single-process threaded server) and in a servlet implementation of our front-end, which also runs in a single process. Right now, I do cache data in each httpd process, but since I haven't implemented a TTL, I rely on the apache process dying naturally to clean up the data. Obviously, this creates *huge* httpd processes (50+ MB) with non-shared but redundant data, and isn't particularly predictable. Our site is a little different that most ecommerce sites, because we have a very low depth of inventory, and have to keep all the state in the database, so that customers will rarely see out-of-date product data. Ultimately, I hope to open up our entire source tree under the GPL anyway, but I'll try to get the generic caching code out there earlier, if possible. I'll keep this list posted. Unless someone has already done this, that is. -DeWitt
Re: squid performance
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. -jwb
RE: squid performance
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 http://www.morebuiness.com and http://govcon.morebusiness.com These are on the same server, and all images and CGI's run on the small apache, and the page contents are dynamically generated by a heavy back-end proxied transparently. The front end apache proxies to a different back-end based on the hostname it is contacted under. Do you know how does this work with slow clients compared to squid. I always thought (but never tried) one benfit of squid is, that it temporaly caches (should be better say buffers?) the output generated by mod_perl scripts, so the script can run as fast as possible and deliver it's output to squid, while squid delivers the output to a slower client, the the process running mod_perl can already serve the next request, therfore keeping the number of mod_perl processes small. Does this work in this way with squid? I don't think this will work with Apache and a simple ProxyPass... Gerald
