Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Fri, 8 Mar 2002, Graham Leggett wrote: Igor Sysoev wrote: *) make simple fault-tolerance with dns-balanced backends. mod_proxy does this already. No. mod_proxy tries it but code is broken. If connection failed it try to connect with the same socket. It should make new socket. Anyway mod_accel tries another backend if connection failed, backend has not sent header, and backend has send 5xx response. I just checked this code - when a connection fails a new socket is created. Are you sure this has not been fixed since you last checked? I had seen 1.3.23 Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Bill Stoddard wrote: mod_disk_cache does not require knowledge of content length. In principle, do you think this is a problem for a proxy cache provided we can gracefully detect and handle cases where cache thresholds are being exceeded? What does squid and apache 1.3 do? I have no idea what squid does. Apache v1.3 only makes a cached object available after it has been downloaded completely, and I think only objects with content-lengths. This causes the problem of nasty load spikes hitting a backend server when cached content expires. I think the following logic is a compromise: - In mem_cache, objects need content-lengths. Partially cached objects are fetchable, solving the load spike problem. - In disk_cache, objects do not need content-lengths, but attempts to cache may be abandoned once the magic threshhold is reached. - As a result of the above possibility that downloads might be abandoned, partially cached objects should not be fetchable. Does this make sense? Is there a way you can see to make disk_cache support partial responses being fetchable? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Bill Stoddard wrote: mod_disk_cache does not require knowledge of content length. In principle, do you think this is a problem for a proxy cache provided we can gracefully detect and handle cases where cache thresholds are being exceeded? What does squid and apache 1.3 do? I have no idea what squid does. Apache v1.3 only makes a cached object available after it has been downloaded completely, and I think only objects with content-lengths. This causes the problem of nasty load spikes hitting a backend server when cached content expires. I think the following logic is a compromise: - In mem_cache, objects need content-lengths. Partially cached objects are fetchable, solving the load spike problem. I think mem_cache should be able to cache (or begin caching) objects with unknown content length. Perhaps by mirroring the content to a temp file on disk and promoting it to in-mem when the full content is received or garbage collecting it if it exceeds max cache object size thresholds. Many content generators (I am thinking servlets and JSPs) generate small (cacheable) responses but we may not know the length of these responses upon first entry to CACHE_IN. - In disk_cache, objects do not need content-lengths, but attempts to cache may be abandoned once the magic threshhold is reached. Yep. - As a result of the above possibility that downloads might be abandoned, partially cached objects should not be fetchable. Does this make sense? Is there a way you can see to make disk_cache support partial responses being fetchable? Serving partially cached responses seems rather flaky to me. And as you alluded to, handling the case where you are serving a partially cached response that is subsequently abandonded is a really funky problem to solve cleanly. Need to give it some more thought... To solve the backend load spike problem, it would be relatively straight forward to stall threads requesting partially cached objects (with a user defineable sleep time and retry period) to keep those threads from firing requests off to the backend servers. Regards, Graham -- Bill
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: The main reason why Squid is better than Apache is much lesser memory overhead per connection. And of course, Squid has many other proxing features - it's proxy, not webserver. In my experience, use a proxy as a forward proxy (like Squid), and use a webserver as a reverse proxy (like Apache). Do you mean that Squid returns cached gzipped content to client that does not send 'Accept-Encoding' ? mod_proxy 1.3.23 does the same. Would it be changed in 1.3.24 ? It should not do - if it does, it's a bug. I live in real world and many webmasters are too. It's not always possible to redesign backend. Unfortunately while Internet boom too many brain-damaged solutions were born. But Apache tries to be the reference implementation of HTTP/1.1. Although there are features in Apache to compensate for client and server brokenness, trying too hard to accomodate broken design allows too many webmasters to get away with broken design. If the clients fixed all server errors, why bother creating a server that meets spec? Use the ProxyPreserveHost option. I suppose in 1.3.24 ? Someone posted a patch a few weeks ago - no idea which versions it appeared in, other than it's in the head of both 1.3 and 2.0. The idea behind mod_cache was to separate the send threads from the receive thread. This means that if a response is half-way downloaded, and a new request comes in, the new request will be served from the half-cached half-downloaded file, and not from a new request. When the original request is finished, the backend is released, and the receive threads carry on regardless. Would it be work in prefork MPM ? The requirement would be based on the presence of shared memory, and should work in all MPMs. You should have created a separate module for this, and run it alongside mod_accel. This can still be done though. I did not use mod_cgi and Java. But other people do. If the busy locks logic was in it's own module, there would be a lot more use for it out there. Your phrase is like 'mod_rewrite should be patched to do some SSI job' mod_rewrite works with URLs and filenames only. It can not change content. mod_randban changes content on the fly. Then I misunderstood what you were trying to do - fiddling with content on the fly is the job of a separate module entirely, probably a filter. I thought you were manipulating URLs. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: *) make simple fault-tolerance with dns-balanced backends. mod_proxy does this already. No. mod_proxy tries it but code is broken. If connection failed it try to connect with the same socket. It should make new socket. Anyway mod_accel tries another backend if connection failed, backend has not sent header, and backend has send 5xx response. I just checked this code - when a connection fails a new socket is created. Are you sure this has not been fixed since you last checked? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: Do you mean that Squid returns cached gzipped content to client that does not send 'Accept-Encoding' ? mod_proxy 1.3.23 does the same. Would it be changed in 1.3.24 ? Looking into this further, proxy uses the HTTP/1.1 Vary mechanism for determining whether a negoitated response is cacheable or not. HTTP/1.0 requests are not checked for negotiated responses. This is in line with the behaviour of mod_negotiation, which adds Pragma: no-cache to negotiated responses on HTTP/1.0 requests. I assume other webservers have similar behaviour, which is why this hasn't been raised as a problem before. In the v1.3 mod_proxy, if a cached variant turns out not to mach the Vary mechanism, that cached variant is deleted and a new variant is requested. This ensures that the client is not sent the wrong variant. In the v2.0 mod_cache, the capability exists to cache multiple variants of the same URL simultaneously. As a result, should a cached variant fit the client's pushlished capabilities, then that variant will be returned, otherwise a new variant will be requested from the remote server, possibly adding an additional variant to the cache. As mod_cache has built in negotiation capabilities, this should in theory work with both HTTP/1.0 and HTTP/1.1 requests. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Wed, 6 Mar 2002, Graham Leggett wrote: mod_accel is not proxy. It's accelarator. It can not work as usual proxy. I did not even try to implement it - Apache 1.3 is poor proxy. Squid or Oops are much better. Until recently you were not aware that the proxy had been updated - I would look at the code again before passing this judgement ;) The main reason why Squid is better than Apache is much lesser memory overhead per connection. And of course, Squid has many other proxing features - it's proxy, not webserver. For example, you pointed out some problems with Squid and content negotiation - mod_proxy doesn't have these problems. Do you mean that Squid returns cached gzipped content to client that does not send 'Accept-Encoding' ? mod_proxy 1.3.23 does the same. Would it be changed in 1.3.24 ? mod_accel can ignore client's 'Pragma: no-cache' and 'Cache-Control: no-cache'. These headers are sent if you press Reload button in Netscape or Mozilla. By default if mod_accel gets these headers then it does not look cache but send request to backend. Webmaster can set 'AccelIgnoreNoCache on' if he sure that backend did not give fresh data and such requests only overload backend. This design is broken. If the client sent a cache-control or pragma header it was because the client specifically wanted that behaviour. If this causes grief on the backend, then your backend needs to be redesigned so that it does not have such a performance hit. I live in real world and many webmasters are too. It's not always possible to redesign backend. Unfortunately while Internet boom too many brain-damaged solutions were born. Breaking the HTTP protocol isn't the fix to a broken backend. I'm considering mod_accel and backend as single entity. It does not matter for me which protocol I use for communication between them. Clients see nice HTTP protocol. Everything under /blah is proxied, except for everything under /blah/somewhere/else. Yes. But '!' is already implemented ? Yes it is. I suppose in 1.3.24 ? By the way mod_accel's syntax is more flexible - mod_accel can use regexp. *) proxy mass name-based virtual hosts with one directive on frontend: AccelPass / http://192.168.1.1/[PH] [PH] means preserve hostname, i.e. request to backend would go with original 'Host' header. mod_accel does this in one directive, mod_proxy does it in two - but the effect is the same. Should we consider adding a combined directive to mod_proxy the same way mod_accel works...? What are two mod_proxy's directives ? As far as I know mod_proxy always change 'Host' header. Use the ProxyPreserveHost option. I suppose in 1.3.24 ? mod_accel can send part of answer to client even backend has not sent whole answer. But even in this case slow client never block backend - I use nonblocking operations and select(). Would it be possible with mod_cache ? The idea behind mod_cache was to separate the send threads from the receive thread. This means that if a response is half-way downloaded, and a new request comes in, the new request will be served from the half-cached half-downloaded file, and not from a new request. When the original request is finished, the backend is released, and the receive threads carry on regardless. Would it be work in prefork MPM ? Both busy locks and limiting concurrent connections can be useful in a normal Apache server using mod_cgi, or one of the Java servlet connectors. Adding this to proxy means it can only be used in proxy - which is a bad idea. Probably but Apache 1.3.x has not such module and I needed it too much in mod_accel. You should have created a separate module for this, and run it alongside mod_accel. This can still be done though. I did not use mod_cgi and Java. This is the job of mod_rewrite. mod_rewrite can not do it. Then rewrite should be patched to do it. Your phrase is like 'mod_rewrite should be patched to do some SSI job' mod_rewrite works with URLs and filenames only. It can not change content. mod_randban changes content on the fly. Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Bill Stoddard wrote: Haven't thought this through, but there is at least one complicated case to consider and handle correctly. If the backend is chunking a response back to the proxy and that response exceeds the size the proxy is allowed to cache, then the proxy would need to abort the caching, send the partial cached file, cleanup that file, then continue reading from the backend. And would we want to make this behaviour configurable? Are there practicle (non-contrived) cases where it is unacceptable to defer sending bytes to the client? In the default design (I dunno if this has been changed) only responses with content-lengths were able to be cached for this reason. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: mod_accel is not proxy. It's accelarator. It can not work as usual proxy. I did not even try to implement it - Apache 1.3 is poor proxy. Squid or Oops are much better. Until recently you were not aware that the proxy had been updated - I would look at the code again before passing this judgement ;) For example, you pointed out some problems with Squid and content negotiation - mod_proxy doesn't have these problems. mod_accel can ignore client's 'Pragma: no-cache' and 'Cache-Control: no-cache'. These headers are sent if you press Reload button in Netscape or Mozilla. By default if mod_accel gets these headers then it does not look cache but send request to backend. Webmaster can set 'AccelIgnoreNoCache on' if he sure that backend did not give fresh data and such requests only overload backend. This design is broken. If the client sent a cache-control or pragma header it was because the client specifically wanted that behaviour. If this causes grief on the backend, then your backend needs to be redesigned so that it does not have such a performance hit. Breaking the HTTP protocol isn't the fix to a broken backend. In theory mod_proxy (and mod_cache) should allow results to be logged via the normal logging modules. If this is not yet possible, it should be fixed. In theory but not in practice. Then it needs fixing. Everything under /blah is proxied, except for everything under /blah/somewhere/else. Yes. But '!' is already implemented ? Yes it is. *) proxy mass name-based virtual hosts with one directive on frontend: AccelPass / http://192.168.1.1/[PH] [PH] means preserve hostname, i.e. request to backend would go with original 'Host' header. mod_accel does this in one directive, mod_proxy does it in two - but the effect is the same. Should we consider adding a combined directive to mod_proxy the same way mod_accel works...? What are two mod_proxy's directives ? As far as I know mod_proxy always change 'Host' header. Use the ProxyPreserveHost option. No. mod_proxy tries it but code is broken. If connection failed it try to connect with the same socket. It should make new socket. Anyway mod_accel tries another backend if connection failed, backend has not sent header, and backend has send 5xx response. This should be fixed. mod_accel can send part of answer to client even backend has not sent whole answer. But even in this case slow client never block backend - I use nonblocking operations and select(). Would it be possible with mod_cache ? The idea behind mod_cache was to separate the send threads from the receive thread. This means that if a response is half-way downloaded, and a new request comes in, the new request will be served from the half-cached half-downloaded file, and not from a new request. When the original request is finished, the backend is released, and the receive threads carry on regardless. Both busy locks and limiting concurrent connections can be useful in a normal Apache server using mod_cgi, or one of the Java servlet connectors. Adding this to proxy means it can only be used in proxy - which is a bad idea. Probably but Apache 1.3.x has not such module and I needed it too much in mod_accel. You should have created a separate module for this, and run it alongside mod_accel. This can still be done though. This is the job of mod_rewrite. mod_rewrite can not do it. Then rewrite should be patched to do it. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Bill Stoddard wrote: Haven't thought this through, but there is at least one complicated case to consider and handle correctly. If the backend is chunking a response back to the proxy and that response exceeds the size the proxy is allowed to cache, then the proxy would need to abort the caching, send the partial cached file, cleanup that file, then continue reading from the backend. And would we want to make this behaviour configurable? Are there practicle (non-contrived) cases where it is unacceptable to defer sending bytes to the client? In the default design (I dunno if this has been changed) only responses with content-lengths were able to be cached for this reason. Regards, Graham mod_disk_cache does not require knowledge of content length. In principle, do you think this is a problem for a proxy cache provided we can gracefully detect and handle cases where cache thresholds are being exceeded? What does squid and apache 1.3 do? Bill -- - [EMAIL PROTECTED] There's a moon over Bourbon Street tonight...
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: mod_proxy can not do many things that mod_accel can. Some of them can be easy implemented, some not. Keep in mind that mod_proxy is exactly that - a proxy. It does not try to duplicate functionality that is performed by other parts of Apache. (This is the main reason mod_proxy and mod_cache were separated from each other in v2.0) mod_accel can: *) ignore headers like 'Pragma: no-cache' and 'Authorization'. This is the job of mod_headers, not mod_proxy. However: ignoring headers violates the HTTP protocol and is not something that should be included in a product that claims to be as HTTP compliant as possible. If you want to cache heavy data sources, use the Cache-Control header correctly, or correct the design of the application so as to be less inefficient. *) log its results. In theory mod_proxy (and mod_cache) should allow results to be logged via the normal logging modules. If this is not yet possible, it should be fixed. *) pass cookies to backend even response can be cached. Again RFC2616 dictates how this should be done - proxy should support the specification. *) taking cookies into account while caching responses. *) mod_accel has AccelNoPass directive. What does this do? If it allows certain parts of a proxied URL space to be not-proxied, then the following will achieve this effect: ProxyPass /blah http://somewhere/blah ProxyPass /blah/somewhere/else ! Everything under /blah is proxied, except for everything under /blah/somewhere/else. *) proxy mass name-based virtual hosts with one directive on frontend: AccelPass / http://192.168.1.1/[PH] [PH] means preserve hostname, i.e. request to backend would go with original 'Host' header. mod_accel does this in one directive, mod_proxy does it in two - but the effect is the same. Should we consider adding a combined directive to mod_proxy the same way mod_accel works...? *) resolve backend on startup. This is a good idea. *) make simple fault-tolerance with dns-balanced backends. mod_proxy does this already. *) use timeout when it connects to backend. mod_proxy should do this - if it doesn't, it is a bug. *) use temporary file for buffering client request body (there is patch for mod_proxy). What advantage does this give? *) serve byte-range requests. This needs to be fixed in proxy, yes. *) get backend response as soon as possible even it's very big. mod_accel uses temporary file for buffering backend response if reponse can not fill in mod_accel configurable buffer. This kind of thing is fixed in v2.0 in mod_cache. It is too big an architecture change for the v1.3 proxy. *) use busy locks. If there are several the same requests to backend then only one of them would go to backend during specified time. *) limit concurrent connections and waiting processes on per-backend or per Location basis. This is not the job of mod_proxy, but the job of a separate module. Both busy locks and limiting concurrent connections can be useful in a normal Apache server using mod_cgi, or one of the Java servlet connectors. Adding this to proxy means it can only be used in proxy - which is a bad idea. *) mod_accel has mod_randban module that allow to randomize some part of content. For example it can replace '1' number in img src=http://host/path1?place=1key=1234rand=1; with random value. This is the job of mod_rewrite. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Eli Marmor wrote: Then, integration with mod_proxy still needed, because the connection of mod_proxy with the backend server was still done directly, and not through the filtering infrastructure. The v2.0 port has used the filtering infrastructure on the backend since day one - however this backend filter stack was set up hardwired by mod_proxy. This will change soon, so that it will be possible to configure arbitrary filters on the backend (such as mod_headers) exactly as you can on the frontend. Trying to add so many features to mod_proxy, may meet the objection of members here, who want a simple and stable mod_proxy, and may fear that all of these additions may make mod_proxy a monster (even if it's not true). The main objection I have with many of the requested features being added to proxy is that the correct solution is to add these features to *apache* generally, not to proxy specifically. There have been many suggestions, like the busy locks, that people want to add to proxy - but these features are very useful in other apache configurations too - like mod_cgi and mod_jk (and its successors). Therefore adding the functionality to proxy limits the usefulness to a single modules only, which is very bad. Solution: create mod_busylock and add it to experimental. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
*) get backend response as soon as possible even it's very big. mod_accel uses temporary file for buffering backend response if reponse can not fill in mod_accel configurable buffer. This kind of thing is fixed in v2.0 in mod_cache. It is too big an architecture change for the v1.3 proxy. Haven't thought this through, but there is at least one complicated case to consider and handle correctly. If the backend is chunking a response back to the proxy and that response exceeds the size the proxy is allowed to cache, then the proxy would need to abort the caching, send the partial cached file, cleanup that file, then continue reading from the backend. And would we want to make this behaviour configurable? Are there practicle (non-contrived) cases where it is unacceptable to defer sending bytes to the client? Bill
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Fri, 1 Mar 2002, Graham Leggett wrote: Igor Sysoev wrote: mod_proxy can not do many things that mod_accel can Some of them can be easy implemented, some not Keep in mind that mod_proxy is exactly that - a proxy It does not try to duplicate functionality that is performed by other parts of Apache (This is the main reason mod_proxy and mod_cache were separated from each other in v20) mod_accel is not proxy It's accelarator It can not work as usual proxy I did not even try to implement it - Apache 13 is poor proxy Squid or Oops are much better mod_accel can: *) ignore headers like 'Pragma: no-cache' and 'Authorization' This is the job of mod_headers, not mod_proxy However: ignoring headers violates the HTTP protocol and is not something that should be included in a product that claims to be as HTTP compliant as possible If you want to cache heavy data sources, use the Cache-Control header correctly, or correct the design of the application so as to be less inefficient mod_accel can ignore client's 'Pragma: no-cache' and 'Cache-Control: no-cache' These headers are sent if you press Reload button in Netscape or Mozilla By default if mod_accel gets these headers then it does not look cache but send request to backend Webmaster can set 'AccelIgnoreNoCache on' if he sure that backend did not give fresh data and such requests only overload backend As to 'Authorization' mod_accel by default sends this header to backend and never caches such answers Webmaster can set 'AccelIgnoreAuth on' if backend never ask authorization but client anyway send 'Authorization' - so in this case 'Authorization' is simply very powerfull 'no-cache' header I know at least one download utility, FlashGet, that sends in 'Authorization' header name and password for anonymous FTP access It's probably bug in FlashGet but this bug effectively trashes cache and backend Yes, of course all these directives work per Location and Files level *) log its results In theory mod_proxy (and mod_cache) should allow results to be logged via the normal logging modules If this is not yet possible, it should be fixed In theory but not in practice *) pass cookies to backend even response can be cached Again RFC2616 dictates how this should be done - proxy should support the specification As I said mod_accel is not proxy By default mod_accel did not send cookies to backend if reponse can be cached But webmaster can set 'AccelPassCookie on' and all cookies goes to backend Backend is responsible to control which answers should be cached and which are not Anyway 'Set-Cookie' headers never goes to cache This directive works per Location and Files level *) taking cookies into account while caching responses *) mod_accel has AccelNoPass directive What does this do? If it allows certain parts of a proxied URL space to be not-proxied, then the following will achieve this effect: ProxyPass /blah http://somewhere/blah ProxyPass /blah/somewhere/else ! Everything under /blah is proxied, except for everything under /blah/somewhere/else Yes But '!' is already implemented ? I use another syntax: AccelPass / http://backend/ AccelNoPass /images /download ~*\jpg$ *) proxy mass name-based virtual hosts with one directive on frontend: AccelPass / http://19216811/[PH] [PH] means preserve hostname, ie request to backend would go with original 'Host' header mod_accel does this in one directive, mod_proxy does it in two - but the effect is the same Should we consider adding a combined directive to mod_proxy the same way mod_accel works? What are two mod_proxy's directives ? As far as I know mod_proxy always change 'Host' header *) resolve backend on startup This is a good idea mod_accel does it by default You can disable it with [NR] flag in AccelPass directive *) make simple fault-tolerance with dns-balanced backends mod_proxy does this already No mod_proxy tries it but code is broken If connection failed it try to connect with the same socket It should make new socket Anyway mod_accel tries another backend if connection failed, backend has not sent header, and backend has send 5xx response *) use timeout when it connects to backend mod_proxy should do this - if it doesn't, it is a bug mod_proxy does not *) use temporary file for buffering client request body (there is patch for mod_proxy) What advantage does this give? Suppose slow client (3K/s) that POST 10K form Backend is busy for 3 seconds Suppose client uploads 100K file *) get backend response as soon as possible even it's very big mod_accel uses temporary file for buffering backend response if reponse can not fill in mod_accel configurable buffer This kind of thing is fixed in v20 in mod_cache It is too big an architecture change for the v13 proxy mod_accel can send part of answer to client even backend has not sent whole answer But even in this
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Wed, 27 Feb 2002, Joseph Wayne Norton wrote: For dynamic content that has been cached or can be cached, the Distributor component would simply send the response back to the client (as mod_proxy does now after talking with the backend). For dynamic content that cannot be cached or doesn't need to be cached, the Distributor would implement a form of TCP handoff that would allow the backend to serve the response directly to the client. This later step probably cannot be done without some additional kernel-level module. I do not understand why do you want that the backend will serve response directly to the client ? If ithe client is slow then it will keep busy the backend. Is it possible to integrate apache 2.0's mod_cache with mod_accel and/or add mod_accel's features to mod_proxy? Mod_proxy is no longer ancient nor hard to maintain, and as far as I am aware the new mod_proxy does almost everything mod_accel does - if it doesn't, tell me what's broken and I'll try to fix it. I haven't spent any time examining the source (or trying to extend) of mod_proxy or mod_accel so I am not able to judge either module. The 2 main points that I picked up from Igor's mail that I'm not sure if mod_proxy supports or not: a. It frees backend as soon as possible. mod_proxy can keep busy backend with slow client, i.e, using mod_proxy to accelerate backend is not worked with slow clients . The last patch allows to specify mod_proxy the big buffer to get backend reponse. But if repsonse would be bigger then this buffer then slow client can still stall backend. b. It can use busy locks and limit number of connection to backend. Yes, mod_proxy can not it. One additional feature that I would like to have with mod_proxy is to have a way to install error_handler documents for all or individual backends. This would allow apache to return a customized error page for individual backends for cases when the backend is not reachable, etc. mod_accel allows it. It seems that mod_proxy in 1.3.23 allows it too but I'm not sure. Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Wed, 20 Feb 2002, Graham Leggett wrote: Igor Sysoev wrote: 1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend. But ap_proxy_send_fb() flushes output to client so it can hang for a long time. I have come up with a patch to solve this problem - in theory anyway. Can you test it and get back to me with whether it makes a difference or not...? The patch is being posted separately. +/* allocate a buffer to store the bytes in */ +/* make sure it is at least IOBUFSIZE, as recv_buffer_size may be zero for system default */ +buf_size = MAX(recv_buffer_size, IOBUFSIZE); +buf = ap_palloc(r-pool, buf_size); There is one drawback in this code. ap_palloc() is not good for big allocations (I think 16K) because it stores data and meta-data together. I had found this when try to allocate memory from pool for zlib in mod_deflate. zlib needs about 390K - 2*128K + 2*64K + 6K. After this change Apache had grown up about 2M after about hour with 50 requests/s. I'm not sure that this growing could continue but I did not want additional 2M on each Apache. I use malloc for big allocations, store addresses in array allocated from pool and set cleanup for this array. In cleanup I free addresses if they is not free already. Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Thu, 21 Feb 2002, Joseph Wayne Norton wrote: After I read your posting, I downloaded but haven't tried to install the mod_accel. From you description, it looks like a very, powerful module with pretty much the features that I have been looking for. Can mod_accel work with the mod_rewrite module (in a fashion similar? mod_accel can work with mod_rewrite as mod_proxy does ([P] flag) but mod_proxy would loose this functionality if mod_accel installed. In all other cases mod_proxy can work with mod_accel in one Apache. In conjunction with mod_rewrite as url filter, I would like to be able to use mod_accel as a proxy for only the http request portion of a client request and allow for the http response portion to be served directly from the backend to the client. This would be useful in situations where the response does not (or should not) have to be cached by the mod_accel cache. However, I think this type of tcp-handoff cannot be performed soley by an application process such as apache. Have you a similiar requirement or experience? No. But mod_accel can simply proxies request without caching. You can set 'AccelNoCache on' on per-server, per-Location and per-Files basis. You can send 'X-Accel-Expires: 0' header from backend. You can use usual 'Cache-Control: no-cache or Expires headers. With mod_accel your mod_rewite using can be eliminated with AccelNoPass directive: AccelPass /http://backend/ AccelNoPass/images /download ~*\.jpg$ Is it possible to integrate apache 2.0's mod_cache with mod_accel and/or add mod_accel's features to mod_proxy? I have plans to make mod_accel Apache 2.0 compatible but not right now. I wait Apache 2.0 stabilzation. As to mod_proxy, I've wrote replacement for mod_proxy because it's to difficult to hack it. It was much simpler to write module from scratch. Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Thu, 21 Feb 2002, Igor Sysoev wrote: On Thu, 21 Feb 2002, Joseph Wayne Norton wrote: After I read your posting, I downloaded but haven't tried to install the mod_accel. From you description, it looks like a very, powerful module with pretty much the features that I have been looking for. Can mod_accel work with the mod_rewrite module (in a fashion similar? mod_accel can work with mod_rewrite as mod_proxy does ([P] flag) but mod_proxy would loose this functionality if mod_accel installed. In all other cases mod_proxy can work with mod_accel in one Apache. In conjunction with mod_rewrite as url filter, I would like to be able to use mod_accel as a proxy for only the http request portion of a client request and allow for the http response portion to be served directly from the backend to the client. This would be useful in situations where the response does not (or should not) have to be cached by the mod_accel cache. However, I think this type of tcp-handoff cannot be performed soley by an application process such as apache. Have you a similiar requirement or experience? No. But mod_accel can simply proxies request without caching. You can set 'AccelNoCache on' on per-server, per-Location and per-Files basis. You can send 'X-Accel-Expires: 0' header from backend. You can use usual 'Cache-Control: no-cache or Expires headers. Even more. mod_accel by default did not cache response if it has not positive Expires or Cache-Control headers. But you can cache these responses using AccelDefaultExpires or AccelLastModifiedFactor directives. Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: 1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend. But ap_proxy_send_fb() flushes output to client so it can hang for a long time. I have come up with a patch to solve this problem - in theory anyway. Can you test it and get back to me with whether it makes a difference or not...? The patch is being posted separately. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Tue, 19 Feb 2002, Fowler, Brian wrote: Due to a requirement on a project we are currently working on involving using Apache as a caching reverse proxy server to WebLogic. We are considering implementing the Cache-Control: no-cache=directive for the Apache 1.3 mod_proxy module so allow us to prevent the caching of certain headers served by WebLogic. (In particular the session cookie.) I developed mod_accel module. ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_accel-1.0.13.tar.gz Documentation in Russain only but English translation was started: http://dapi.chaz.ru:8100/articles/mod_accel.xml Features: It allows reverse-proxing only. It frees backend as soon as possible. mod_proxy can keep busy backend with slow client, i.e, using mod_proxy to accelerate backend is not worked with slow clients . It can use busy locks and limit number of connection to backend. It implements primitive fault-tolerance via DNS-balanced backends. It can to cache content with some cookie and ignore another. It can ignore Pragma: no-cache and Authorization. You can specify variuos buffer sizes. It buffers POST body. It logs its state. Drawbacks: I think it can not work in Win32. Probably under Cygwin only. Has/is anyone working in this area? Is there any specific reason why this has deliberately not been implemented already? (E.g. performance hit?) Any views on this directive? mod_proxy is very ancient module and it's hard to maintain it. Igor Ssyeov
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: mod_proxy is very ancient module and it's hard to maintain it. Er, mod_proxy _was_ a very ancient module, but has been largely overhauled in v1.3 and completely rewritten in v2.0 in both cases having full support of HTTP/1.1. Once mod_cache is finished in v2.0, (in theory) the capability will be there to disengage expensive backends and slow frontends from each other - so all your problems will be solved. :) Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Tue, 19 Feb 2002, Graham Leggett wrote: Igor Sysoev wrote: mod_proxy is very ancient module and it's hard to maintain it. Er, mod_proxy _was_ a very ancient module, but has been largely overhauled in v1.3 and completely rewritten in v2.0 in both cases having full support of HTTP/1.1. The main problem with mod_proxy is that it reads backend response to 8K buffer and than sends it to client. When it have sent it to client it reads again from backend. After it have sent whole content to client it flushes buffer and only after this it closes backend socket. Even backend send all to its kernel buffer and response is recevied in frontend kernel buffer nevertheless backend need to wait frontend in lingering_close. So we lose at least 2 seconds with small client and big response. Once mod_cache is finished in v2.0, (in theory) the capability will be there to disengage expensive backends and slow frontends from each other - so all your problems will be solved. :) Will see 2.0 but I suppose that multi-threaded mod_perl backend with 10 threads will occupy almost the same memory as 10 mod_perl single thread processes. Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: The main problem with mod_proxy is that it reads backend response to 8K buffer and than sends it to client. When it have sent it to client it reads again from backend. After it have sent whole content to client it flushes buffer and only after this it closes backend socket. Even backend send all to its kernel buffer and response is recevied in frontend kernel buffer nevertheless backend need to wait frontend in lingering_close. So we lose at least 2 seconds with small client and big response. Will making the 8k buffer bigger solve this problem? I will check that once the end of a request has been detected from the backend, this backend connection is closed before attempting to send the last chunk to the frontend. This should have the effect that with a large enough buffer, the backend will not have to wait around while a slow frontend munches the bytes. Once mod_cache is finished in v2.0, (in theory) the capability will be there to disengage expensive backends and slow frontends from each other - so all your problems will be solved. :) Will see 2.0 but I suppose that multi-threaded mod_perl backend with 10 threads will occupy almost the same memory as 10 mod_perl single thread processes. But a single thread of a mod_perl backend will use less resources if it need only stick around for 100ms, than it will if it has to stick around for a minute. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
On Tue, 19 Feb 2002, Graham Leggett wrote: Igor Sysoev wrote: The main problem with mod_proxy is that it reads backend response to 8K buffer and than sends it to client. When it have sent it to client it reads again from backend. After it have sent whole content to client it flushes buffer and only after this it closes backend socket. Even backend send all to its kernel buffer and response is recevied in frontend kernel buffer nevertheless backend need to wait frontend in lingering_close. So we lose at least 2 seconds with small client and big response. Will making the 8k buffer bigger solve this problem? No. It does not resolve 2-second lingering close on backend. I will check that once the end of a request has been detected from the backend, this backend connection is closed before attempting to send the last chunk to the frontend. This should have the effect that with a large enough buffer, the backend will not have to wait around while a slow frontend munches the bytes. 1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend. But ap_proxy_send_fb() flushes output to client so it can hang for a long time. Once mod_cache is finished in v2.0, (in theory) the capability will be there to disengage expensive backends and slow frontends from each other - so all your problems will be solved. :) Will see 2.0 but I suppose that multi-threaded mod_perl backend with 10 threads will occupy almost the same memory as 10 mod_perl single thread processes. But a single thread of a mod_perl backend will use less resources if it need only stick around for 100ms, than it will if it has to stick around for a minute. Why it will stick for 100ms only with slow client ? Will Apache 2.0 use separate threads for lingering_close ? Igor Sysoev
Re: mod_proxy Cache-Control: no-cache=directive support Apache1.3
Igor Sysoev wrote: 1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend. But ap_proxy_send_fb() flushes output to client so it can hang for a long time. Then this needs to be fixed. I have 24 hours sitting on a plane starting tomorrow night, so I'll probably have time then :) Why it will stick for 100ms only with slow client ? Will Apache 2.0 use separate threads for lingering_close ? The idea was that instead of passing buckets from the backend to the frontend one-at-a-time, the backend would feed buckets into the memory cache, and independently the frontend would read buckets out of the cache. So: When the backend was finished sending buckets, it went away completely having finished populating the cache. The frontend would then read from the cache taking as long as it liked. There have been a lot of changes to mod_cache though, not sure if this is still in the design. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... smime.p7s Description: S/MIME Cryptographic Signature
