I compiled a new RPM for the beta testers and or people who want to test newer code of ROCK and STOREID. So now the RPM build is explicitly not using "march=native" which should add couple more machines out-there that the RPM will work on... The RPM build is design for 64bit CPU but has a 32bit version. The tests that was done until now on the RPMs are: - Compilation using the generic squid options (minus\less)march=native of both 64 and 32 bit versions. - Startup and usage on ram and rock cahce_dir. - StoreID function works good.(appended small background on StoreID) - StoreID helper that uses a DB file for pattern works in a format of "regex - tab or more - response based on the request matches" examples in the patter DB which is provided in the wiki. - loading a page with more then 80 object which all took about 80 new connections. - stress testing the helper which doesn't have any ttl to cache the response compared to external_acl.(add acls that will lower the stress on the helper) - init.d script seems to work well for now but maybe needs a tweak. * yet to be tested using intercept\tproxy\accel. more info can be found at the wiki: http://wiki.squid-cache.org/KnowledgeBase/CentOS#Squid-3.4_-Beta The RPM can be downloaded from here: http://www1.ngtech.co.il/rpm/centos/6/x86_64/beta/ This is the second release of 3.4 branch. There are couple bug fixes and couple new features in it. There is, also the StoreID feature which has documentation at wiki: http://wiki.squid-cache.org/Features/StoreID A small introduction to StoreID. ================================ StoreID relays on the fact that a url identifies one content can also be identified by another url which has different domain different port different location and different headers. Since all the above are true then there is an option to assume that two urls can serve the same content using different properties of the HTTP request such as url. While all the above is true if I would for example ask a storage engine that stores files content hash *only* I would just ask for the let say md5 hash and it will retrieve the wanted content. Squid works the other way then plain HASH. Squid actually understands the request properties such as url headers and other properties of the requests and verifies if the currently stored *object* is the right one to return the client or in a case that a re-validation with the server is needed the re-validation is done to make sure the client is satisfied. After all the above a small example will be: http://www1.ngtech.co.il/rpm/centos/6/x86_64/beta/squid-3.4.0.2-1.el6.x86_64.rpm.asc Which is the digital signatures that squid rpm V 3.4.0.2 has. you can also get the same file at: http://repo.ngtech.co.il/rpm/centos/6/x86_64/beta/squid-3.4.0.2-1.el6.x86_64.rpm.asc The repo.ngtech.co.il is a nice resource and is a reliable one which will verify that the file comes from www1.ngtech.co.il. In a case an admin knows the above he can deduplicate any content under: http://repo.ngtech.co.il/rpm/ http://www1.ngtech.co.il/rpm/ to: http://repo.ngtech.co.il.squid.internal/rpm/ which the pattern will be identified by a line ^http:\/\/(www1|repo)\.ngtech\.co\.il\/rpm/(.*) http://repo.ngtech.co.il.squid.internal/rpm/$2 There is a small mirror pattern DB which I look forward to expand at: http://wiki.squid-cache.org/Features/StoreID/DB You can see that there are patterns of ubuntu mirrors in the list but There should be explicit rules to make sure that at least the repo DB will be downloaded from a 100% reliable server to verify that all the rpm files are not corrupted in any-way. New log features ================ In 3.4.0.2 we can see how logs looks and will understand them better and with example: #start 1381024746.672 2211 192.168.10.146 TCP_REFRESH_UNMODIFIED/304 396 GET http://repo.ngtech.co.il/rpm/centos/6/supported.txt - HIER_DIRECT/58.28.153.233 - 1381024764.417 20 192.168.10.146 TCP_REFRESH_FAIL_OLD/200 779 GET http://www1.ngtech.co.il/rpm/centos/6/supported.txt - HIER_DIRECT/84.95.212.160 text/plain #end The Above logs describe that the client requested a refresh for already cached object from the origin server and then requested the mirrored file while the origin server was not running. I shows how squid caches content in the extent of almost-offline situation. If you see some log entries that start with TCP_XYZ_XYZ don't panic since this is the way it should be. Release 2 of the RPM ==================== Since there were intensive testing going on in the background on this version there is a first release which works and there is a second release. Second release supports ROCK cache_dir. On the next beta 3.4.0.3 I will try to write more about ROCK cache_dir. Eliezer On 10/05/2013 09:25 AM, Amos Jeffries wrote: > The Squid HTTP Proxy team is very pleased to announce the > availability of the Squid-3.4.0.2 beta release! > > > The Squid-3.4 series is dedicated to Dmitry Kurochkin who died > in an accident on July 21, 2013. His work directly underpins several > of the major and popular performance and stability changes for > recent and upcoming Squid-3 series. > > > This new 3.4 series of Squid brings useful new features and changes > providing improved stability over earlier release series. > > More detailed descriptions of the major new features are available in > the release notes and wiki: > http://www.squid-cache.org/Versions/v3/3.4/RELEASENOTES.html > http://wiki.squid-cache.org/Squid-3.4 <SNIP> > > If you encounter any issues with this release please file a bug report. > http://bugs.squid-cache.org/ > > Amos Jeffries >
