• Description
• Features
• What's new?
• Usage
• Output and it's interpretation

Squeezer is a tool for gathering different statistical information from Squid web cache server to tune it fine. The tool is destined basically for web cache operators, but can be obtained and used for any other purpose. The software has been written in PERL and as Squid itself and PERL - it's free. But You use it at your own risk! Check out this page for any information about it's development and features.
You can download:

• stable version 0.3

Features

• uses squid access.log in native log format as input,
• gives several profiles of information about the traffic characteristics from the point of view of web cache clients (uses the time ellapsed during the client's connection),
• gives the output as HTML/CGI.

Whats' new?
0.3

• added refresh pattern statistics
• changed output look for much more nice and clear :)

• further optimizations making it run faster
• added command line options (squeezer.pl -h for help)

• added simple web interface to choose which archived log to analyze,
• done many optimizations improving performance a lot!
• added CPU usage statistics.

• fixed time accounting ($last_time is now always greater than $first_time, so the time accounted is now always positive)

• from command line with options:

-a directory - process all logfiles from directory
-c config_file - squid config file (default /usr/local/squid/etc/squid.conf)
-h - help - prints out helpful information
-l logfile - process logfile
produces HTML report on standard output
• as CGI script - can be run interactively from web page

The output contains several profiles of information with several different positions (categories) in each. Each category is characterized with several values which are described below:

• No of req - the number of service requests classified into category
• Req % - share of current category's requests in total number of requests
• Xfer - the amount of traffic classified into category (in kilobytes)
• Xfer % - the share of current category's traffic in total traffic from this web cache
• Xfer speed - the speed of transfer in current category (in kilobytes)
• Times to direct - simple comparison of transfer speed in current category to direct fetches speed; this value is important - it tells you whether the category speed up your service or not!

Start date: Wed Jun 16 00:02:26 1999
End date : Wed Jun 16 11:57:26 1999 

Total time: 42900 s 

HTTP requests per hour : 860

Transfer per hour : 5572 KB

• Start date is a time of the first analyzed service request
• End date is the time of the last analyzed service request

• Total time is the dlength of analyzed period
• HTTP requests per hour is the average number of service request per hour of analyzed period
• Transfer per hour is the average amount of data (in kilobytes) transferred per hour of analyzed period

• Total traffic is the characteristics of all the traffic coming through this web cache server - no matter who satisfied the request; the value of Times to direct in this category (colored red) shows how much all the traffic is on an average faster compared to potentially all-direct traffic; good for reporting and cache advertising purposes ;)
• Direct fetches is the characteristics for direct fetches from the origin servers
• This server is the characteristics for fetches from local web cache server; it shows you the general information about the efficiency of the local server - how much traffic goes locally instead of from outside and how faster is that compared to the direct fetches
• Other servers is an aggregate category for the fetches from the cooperating web cache servers - it gives you the overview of cooperation between you and your siblings/parents
• Cache hierarchy shows you the characteristics of the This server and Other servers taken together

Sibling efficiency:

Server	Current relation and options	HTTP	ICP	Xfer (KB)	Xfer %	No of req	Xfer speed (KB/s)	Times to direct
w3cache.man.lodz.pl	parent no-digest	8080	3130	2379	3	888	3.17	5.34
sunsite.icm.edu.pl	parent no-digest	8081	3131	2469	3	570	2.02	3.39
w3cache.pk.edu.pl	sibling no-query	8080	0	103	0	81	0.33	0.55
w3cache.man.szczecin.pl	sibling no-digest	8080	3130	0	0	4	0.00	0.00

This table shows you the characteristics of the fetches from individual cooperating web cache servers. This one will help you to set up properly sibling relationships. The servers are sorted by the amount of transfer - the effective siblings/parents are higher in the table. Remember about some rules

• the slowest sibling will go probably down the table - it answers slowly for ICP queries and the chance of SIBLING HIT for him is reduced; it does mean that faster siblings should have bigger Xfer % - if it is not true something goes wrong - e.g. you probably try to access large (and having good ICP hit ratio), but slow (heavily loaded) server - this will slow you down! If it is parent, you can use weight options to balance it; if it is sibling you'll probably need to copy it's data to your cache (do not use proxy only option!) or even turn it off.
• the fastest siblings can use the proxy only option to avoid the replication of the data which is available fast e.g. from the same fast network (LAN or MAN) by the some backup/additional/private link; doing that you save your disk space and database entries for something, which could be fetched at any time with small cost

This table shows you detailed statistics about efficiency of fetching objects of different types. It is useful for making different refresh_patterns in your squid.conf. This does make a sense while refreshing different types of objects - rather large like pictures and movies and changed rarely - and smaller and changed often - like HTML documents. As you can imagine relaxing the refreshing rules for the first ones will raise your byte hit ratio and speed of service without large risk of staleness, while the second ones still need the tight refreshing rules. From that table you could see the impact of the different object types for your web cache server and it's efficiency. This is going to be replaced by the table of refresh patterns hit characteristics in future.

By cache result codes:

This table shows the characteristics for different cache result codes. The only useful information I have found is the difference between TCP_MEM_HIT (which are objects fetched from squid's RAM buffer) against TCP_HIT (which are fetched from disk buffer). Low value for TCP_HIT displays the need for dedicate more RAM for Squid and/or rearranging the cache_dir layout - spreading several cache directories over several disk/controllers or any further disk performance improvement.

By peer status:

The basic stuff showing you advantages/disadvantages of using parent and sibling relationship. Ue with caution! Remember that your parents and siblings could be available via lines of different speed and quality. Using those aggregates for analysis may cause false conclusions.
The strong point of this stuff is opportunity to compare cache digests versus ICP, if there are siblings communicating both ways in similar environment.
No idea how to use that more:( Any suggestions?

Feedback

If you have any questions, comments, flames, seen any bugs, send it to maciej_kozinski@yahoo.com.

---

Back to my personal page

---