Re: [squid-users] Unusual squid application

BARRY J BLUMENFELD wrote:

>Hello,
> We have a very unusual squid application. We want to use a squid as
>a distribution point of a few very large files (~300 MB) to hundreds of
>computers. If the first computer requests the file, and it isn't in the
>disk cache, a request will be made to the origin server. That's fine.
>What happens if a second computer requests the same file before the first
>download from the origin server is completely in the squid cache? Is
>squid smart enough to realize that the file has already been requested
>from the origin server and wait, or will the second request initiate a
>second download from the origin server?
>
>
>
From http://www.squid-cache.org/Doc/Prog-Guide/prog-guide-3.html#ss3.6...

* Client-side requests register themselves with a /StoreEntry/ to be
notified when new data arrives. Multiple clients may receive data via a
single /StoreEntry/.

What that says to me is that as long as the content is cacheable, and
explicitly the same (e.g. not the same content from different origin
servers) multiple clients will not cause multiple connections.

>For these huge files, does the squid wait until the whole file has arrived
>from the origin server before passing it on to the first client?
>
>
>
 From http://www.squid-cache.org/Doc/Prog-Guide/prog-guide-5.html...

* As the reply is initially received, the HTTP reply headers are parsed
and placed into a reply data structure. As reply data is read, it is
appended to the /StoreEntry/. Every time data is appended to the
/StoreEntry/, the client-side is notified of the new data via a callback
function. The rate at which reading occurs is regulated by the delay
pools routines, via the deferred read mechanism.

* As the client-side is notified of new data, it copies the data from
the StoreEntry and submits it for writing on the client socket.

Squid passes data along as it receives it. The read rate from origin
servers might be limited by delay pools, but the write rate to clients
is not.

>Thanks very much.
>
>
>

Hope that helps,
Chris
Received on Tue Mar 28 2006 - 12:11:51 MST