Arch Linux

MonkeyBoy

Member

Registered: 2017-11-26

Posts: 22

Squid access.log All miss - no hit (well, 0.05%, but still)

I have searched the forum and I have tried with the great google but to no avail. It might just be a non-problem and I might just made a fool of myself, but here we go.

I few days back I managed to get Squid up and running on my laptop, the /var/log/squid/access.log populated and all was well. Not many hits but that was expected - the hits would come over time.

Now, in the access.log there are:
A total of 1941 lines.
of which 1714 lines are marked MISS
hence there are 227 of other marking. Mostly REFRESH_MODIFIED or _UNMODIFIED
Then we come to the hitrate. Marked HIT - 10 lines

Roughly 0.05% HIT:s if I am not mistaken? I have a squid-cache of 19mb so there is something in there and hence it should be more HIT:s, no?

I read my newspapers (a lot), refreshed manually and automatic several times a day. I surf forums and sites to research for this or that and, yeah, that is about it. Am I doing something wrong here? Every webpage of a newspaper is approx 3-4meg, the pages have a lot of data in common, hence I should be able to see a substantial drop in data consumption over my 4G connections, right?

Hope for your input.

circleface

Member

Registered: 2012-05-26

Posts: 639

Re: Squid access.log All miss - no hit (well, 0.05%, but still)

Be aware that proxies like yours cannot cache https sites, only http.  So, for example, nothing on the archlinux.org domain will be cached by your proxy.  Unfortunately, there is no way around this since it is due to the nature of SSL.

MonkeyBoy

Member

Registered: 2017-11-26

Posts: 22

Re: Squid access.log All miss - no hit (well, 0.05%, but still)

@ First: thanks for taking your time again.

Below shows us two things: squid fetches virtually no archlinux pages and "https lines" are not fetched at all, so you are correct.

sudo less /var/log/squid/access.log | grep archlinux

1512291774.052    348 192.168.43.206 TCP_MISS/301 510 GET http://archlinux.cu.be/core/os/x86_64/core.db - ORIGINAL_DST/194.50.97.16 text/html
1512291775.570    130 192.168.43.206 TCP_MISS/301 512 GET http://archlinux.cu.be/extra/os/x86_64/extra.db - ORIGINAL_DST/194.50.97.16 text/html
1512291779.299    122 192.168.43.206 TCP_MISS/301 520 GET http://archlinux.cu.be/community/os/x86_64/community.db - ORIGINAL_DST/194.50.97.16 text/html
1512291795.231    123 192.168.43.206 TCP_MISS/301 518 GET http://archlinux.cu.be/multilib/os/x86_64/multilib.db - ORIGINAL_DST/194.50.97.16 text/html
1512291796.548    377 192.168.43.206 TCP_MISS/304 285 GET http://repo.archlinux.fr/x86_64/archlinuxfr.db - ORIGINAL_DST/5.39.83.67 -
1512597007.717    366 192.168.43.206 TCP_MISS/301 545 GET http://archlinux.cu.be/community/os/x86_64/vnstat-1.17-1-x86_64.pkg.tar.xz - ORIGINAL_DST/194.50.97.16 text/html

sudo less /var/log/squid/access.log | grep https | wc -l
0

But still we have 3079 "MISS lines" (just checked) and I think there should be a little more than 18 lines of HIT:s, (still 0,05%). Though, there are 3599 "http lines" fetched and 270 of these are "MODIFIED lines". So afaik 7,5% of fetched objects in the cache has been updated with a call to originator (eg newspaper)

So 1 - all in all I cannot really make sense out of this, and 2 - if it is not working that well with Squid and https sites, is there any other solution to effective cut bandwith? Sorry, it is OT but I hope it will slide.

Anyways, again thanks for your time.

Last edited by MonkeyBoy (2017-12-07 17:48:54)

circleface

Member

Registered: 2012-05-26

Posts: 639

Re: Squid access.log All miss - no hit (well, 0.05%, but still)

I'm not sure why you are getting that many misses, but I haven't used squid in over 10 years, so I'm not really sure what is going on.  With the "whole web" (from Let's Encrypt)  going to https however, it is becoming much harder to reduce your bandwidth usage.  Because of the nature of ssl sites, the proxy cannot decrypt the traffic and thus, cannot cache items that were sent over ssl.  One thing you might try is increasing the amount of cache in your browser.  That could potentially save you a bit of bandwidth, but probably not as much as you want.