r4858 - in trunk/varnish-cache/doc/sphinx: installation tutorial

Wed May 26 10:21:58 CEST 2010

Author: perbu
Date: 2010-05-26 10:21:57 +0200 (Wed, 26 May 2010)
New Revision: 4858

Modified:
   trunk/varnish-cache/doc/sphinx/installation/install.rst
   trunk/varnish-cache/doc/sphinx/tutorial/increasing_your_hitrate.rst
   trunk/varnish-cache/doc/sphinx/tutorial/troubleshooting.rst
   trunk/varnish-cache/doc/sphinx/tutorial/vcl.rst
Log:
rewrote VCL + removed all warnings

Modified: trunk/varnish-cache/doc/sphinx/installation/install.rst
===================================================================

--- trunk/varnish-cache/doc/sphinx/installation/install.rst	2010-05-25 10:47:20 UTC (rev 4857)
+++ trunk/varnish-cache/doc/sphinx/installation/install.rst	2010-05-26 08:21:57 UTC (rev 4858)
@@ -43,7 +43,7 @@
 	You are probably best of compiling your own code. See `Compiling Varnish from source`_.
 
 If that worked for you, you can skip the rest of this document
-for now, and and start reading the much more interesting :ref:`Tutorial`
+for now, and and start reading the much more interesting :ref:`tutorial-index`
 instead.
 
 

Modified: trunk/varnish-cache/doc/sphinx/tutorial/increasing_your_hitrate.rst
===================================================================
--- trunk/varnish-cache/doc/sphinx/tutorial/increasing_your_hitrate.rst	2010-05-25 10:47:20 UTC (rev 4857)
+++ trunk/varnish-cache/doc/sphinx/tutorial/increasing_your_hitrate.rst	2010-05-26 08:21:57 UTC (rev 4858)
@@ -22,8 +22,8 @@
 give you the result. I use two programs, GET and HEAD.
 
 vg.no was the first site to use Varnish and the people running Varnish
-there are quite clueful. So its interesting to look at their HTTP
-Headers. Lets send a GET requst for their home page.::
+there are quite cluefull. So its interesting to look at their HTTP
+Headers. Lets send a GET request for their home page.::
 
   $ GET -H 'Host: www.vg.no' -Used http://vg.no/
   GET http://vg.no/
@@ -81,9 +81,8 @@
 cares about the *max-age* parameter and uses it to calculate the TTL
 for an object. 
 
-"Cache-Control: nocache" is ignored. See
-:ref:`tutorial-increasing_your_hitrate-pragma:` for an example on how
-to implement support.
+"Cache-Control: nocache" is ignored but if you need this you can
+easyli add support for it.
 
 So make sure use issue a Cache-Control header with a max-age
 header. You can have a look at what Varnish Softwares drupal server

Modified: trunk/varnish-cache/doc/sphinx/tutorial/troubleshooting.rst
===================================================================
--- trunk/varnish-cache/doc/sphinx/tutorial/troubleshooting.rst	2010-05-25 10:47:20 UTC (rev 4857)
+++ trunk/varnish-cache/doc/sphinx/tutorial/troubleshooting.rst	2010-05-26 08:21:57 UTC (rev 4858)
@@ -65,5 +65,5 @@
 Varnish doesn't cache
 ~~~~~~~~~~~~~~~~~~~~~
 
-See :ref:`_tutorial-increasing_your_hitrate:`.
+See :ref:`tutorial-increasing_your_hitrate`.
 

Modified: trunk/varnish-cache/doc/sphinx/tutorial/vcl.rst
===================================================================
--- trunk/varnish-cache/doc/sphinx/tutorial/vcl.rst	2010-05-25 10:47:20 UTC (rev 4857)
+++ trunk/varnish-cache/doc/sphinx/tutorial/vcl.rst	2010-05-26 08:21:57 UTC (rev 4858)
@@ -1,45 +1,28 @@
 Varnish Configuration Language - VCL
 -------------------------------------
 
-Varnish has a really neat configuration system. Most other systems use
-configuration directives, where you basically turn on and off a bunch
-of switches. 
+Varnish has a great configuration system. Most other systems use
+configuration directives, where you basically turn on and off lots of
+switches. Varnish uses a domain specific language called Varnish
+Configuration Language, or VCL for short. Varnish translates this
+configuration into binary code which is then executed when requests
+arrive.
 
-A very common thing to do in Varnish is to override the cache headers
-from our backend. Lets see how this looks in Squid, which has a
-standard configuration.::
+The VCL files are divided into subroutines. The different subroutines
+are executed at different times. One is executed when we get the
+request, another when files are fetched from the backend server.
 
-	 refresh_pattern ^http://images.   3600   20%     7200
-	 refresh_pattern -i (/cgi-bin/|\?)    0    0%        0
-	 refresh_pattern -i (/\.jpg)       1800   10%     3600 override-expire 
-	 refresh_pattern .                    0   20%     4320
-
-If you are familiar with squid that probably made sense to you. But
-lets point out a few weaknesses with this model.
-
-1) It's not intuitive. You can guess what the options mean, and you
-   can (and should) document it in your configuration file.
-
-2) Which rules have precedence? Does the last rule to match stick? Or
-   the first? Or does Squid try to combine all the matching rules. I
-   actually don't know. 
-
-Now enter Varnish. Varnish takes your configuration file and
-translates it to C code, then runs it through a compiler and loads
-it. When requests come along varnish just executes the relevant
-subroutines of the configuration at the relevant times.
-
 Varnish will execute these subroutines of code at different stages of
-its work. Since its code it's execute line by line and precedence
+its work. Because it is code it is execute line by line precedence
 isn't a problem. At some point you call an action in this subroutine
-and then the execution of the subroutine stops. 
+and then the execution of the subroutine stops.
 
 If you don't call an action in your subroutine and it reaches the end
-Varnish will execute some built in code as well. We discuss this in
-XXX: Appendix A - the builtin VCL.
+Varnish will execute some built in VCL code. You will see this VCL
+code commented out in default.vcl.
 
 99% of all the changes you'll need to do will be done in two of these
-subroutines.
+subroutines. vcl_recv and vcl_fetch.
 
 vcl_recv
 ~~~~~~~~


