Re: [squid-users] Question for y'all?

From: Michial Thompson <michialt_at_gmail.com>
Date: Fri, 19 Nov 2010 12:29:40 -0600

Changing the application so that non static pages isn't able to happen
(long story). Most of the graphic files are going to be GIF/JPG/PNG
extensions and are not streamed, but the link inside the app would be
dynamically generated with the page.

I'll have to look at the server settings, I can change them some, so
they aren't telling the browsers not to cache. BUT the problem here
was that in a lot of cases I have had to set the browsers to reload
the page with every visit because caching at the browser side has been
problematic in the past too.

My thinking was that if I put a proxy server at the site and at least
cached all the image files I could at least increase some of the
performance, and cut out some of the traffice on the DSL. My
assumption was that if I could cut the traffic on the DSL I could gain
some performance for them.

---
On a side note, I had also considered puting NAS drives local w/ http
servers, then making copies of all the images to the NAS and changing
the programs to point to the NAS for images.  BUT that was going to be
substantial amounts of programming resources which I didn't want to
invest in.  I was thinking that it would cost about the same in
hardware to put proxies local, and save the cost of development.
On Fri, Nov 19, 2010 at 11:16 AM, Jakob Curdes <jc_at_info-systems.de> wrote:
> While I think Alex made a good point I will try to answer Michial's original
> question.
>
> Am 19.11.2010 16:00,  Michial Thompson wrote:
>>
>> How well does Squid do for caching images that are displayed on a
>> dynamically generated page?  How well does it handle caching from a
>> Windows Based Server?
>>
> You can configure what should be cached. Generally speaking, a GIF is a GIF.
> If it is recognizable as a gif picture (i.e. there is actually a link to a
> gif file somewhere in the HTML code), squid will cache this item (depending
> on the Cache-Control parameters sent by the HTTP server) without special
> configuration, regardless whether the HTML around it is generated
> dynamically or not.
> If the picture is some sort of a stream, or result of a query, you will need
> more work to cache this. The "Windows Server" does not enter into this
> picture, there are constructs very similar to ASP pages based on other
> operating systems too. The basic question is whether you are able to tell
> the proxy in some way which content is dynamic an which items are static.
> See below.
>>
>> Not sure if this is even possible, but how does it handle dynamically
>> generated pages that are really static in nature, just being generated
>> from ASP/ASPX type pages?
>
> You can configure squid to cache many sorts of http traffic, but probably
> what you really want is give the "static" items (i.e. where the content does
> not change every time) a file extension like "html" or "htm" and have squid
> cache these OOTB while your "really-dynamic" pages have an extension that is
> not cached ; otherwise you have no control over the content your users get
> any more. I am not sure how you can do this inside ASP; you could always
> place a reverse proxy (e.g. apache) in front of your origin server that does
> this rewriting. The same is valid for images etc; make them recognizable as
> static in some way and give this information to the HTTP proxy.
>
> Remember that a HTTP proxy like squid will not actually inspect the
> *content* of the HTTP traffic, so it cannot do something like "oh this byte
> stream looks like a gif header".
>
> Another point: before pushing proxy boxes to your customers, you probably
> want to make sure that you cannot achieve the same effect by correctly
> setting the cache-control of you webserver (which will be read by most
> browsers in a similar way that proxies do it). If you tell browsers and
> proxies to throw every item away and re-fetch it after viewing, adding a
> proxy would be pointless.
>
> Hope this helps,
> Jakob Curdes
>
>
>
Received on Fri Nov 19 2010 - 18:29:46 MST

This archive was generated by hypermail 2.2.0 : Sat Nov 20 2010 - 12:00:03 MST