Is it not possible to cache the https due the encryption?
2015-09-18 9:44 GMT-03:00 Antony Stone <Antony.Stone@xxxxxxxxxxxxxxxxxxxx>:
On Friday 18 September 2015 at 14:27:42, Jorgeley Junior wrote:
> there is a way to improve it?
Improve what? The percentage of your traffic which is cached, or the accuracy
of the information reported by your monitoring system?
If you want to cache more content:
1. Make sure the sites being visited have available content (note that 12.6%
of your requests resulted in the remote server saying some variation on
"nothing available").
2. Ignore things which are meaningless - such as the 27% of your requests
which resulted in 407 Authentication Required - that tells you nothing about
whether the user then successfully authenticated and got what they wanted, or
didn't, but either way it's a standard response from the server which tells
you nothing about the effectiveness of your cache.
3. Make sure your traffic is HTTP instead of HTTPS.
4. Make sure your users are visiting the same sites repeatedly so that content
which gets cached gets re-used.
5. Make sure the sites they're visiting are not setting "don't cache" or
"already expired" headers (such as is common for news sites, for example) so
that the content is cacheable.
6. Run your cache for long enough that it's likely to have a representative
proportion of what the users are asking for when you start measuring its
effectiveness - if you start from an empty cache and pass requests through it,
it's going to take some time for the content to build up so that you see some
hits.
If you want to improve the information you're getting from the monitoring
system, make sure it's telling you how much was cached as a proportion of
requests which could have been cached - in other words, leave out HTTPS (36%)
and 407 Auth Required (27%), plus anything where the remote server had nothing
to provide (13%), and requests where the user's browser already had a cached
copy and didn't to request an update (4%).
That throws out 80% of your current statistics, so you concentrate on the data
about connections Squid *could* have helped with.
"The problem with television is that the people must sit and keep their eyes
> 2015-09-18 8:25 GMT-03:00 Antony Stone:
> > On Friday 18 September 2015 at 13:13:27, Jorgeley Junior wrote:
> > > hey guys, forgot-me? :(
> >
> > Surely you can see for yourself how many connections you've had of
> > different types? Here are the most common (all those over 100 instances)
> > from your list of 5240 results
> >
> > > > 290 TAG_NONE/503
> > > > 368 TCP_DENIED/403
> > > > 1421 TCP_DENIED/407
> > > > 680 TCP_MISS/200
> > > > 192 TCP_REFRESH_UNMODIFIED/304
> > > > 1896 TCP_TUNNEL/200
> >
> > So:
> >
> > 290 (5.5%) got a 503 result (service unavailable)
> > 368 (7%) were denied by the remote server with code 403 (forbidden)
> > 1421 (27%) were deined by the remote server with code 407 (auth required)
> > 680 (13%) were successfully retreived from the remote servers but were
> > not previously in your cache
> > 192 (3.6%) were already cached by your browser and didn't need to be
> > retreived
> > 1896 (36%) were successful HTTPS tunneled connections, simply being
> > forwarded
> > by the proxy
> >
> > This accounts for 4847 (92.5%) of your 5240 results.
> >
> > As you can see, just measuring HIT and MISS is not the whole picture.
> >
> >
> > Hope that helps,
> >
> >
> > Antony.
--
glued on a screen; the average American family hasn't time for it."
- New York Times, following a demonstration at the 1939 World's Fair.
Please reply to the list;
please *don't* CC me.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
--
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
