r31 - trunk/varnish-doc/en/varnish-architecture

des at projects.linpro.no des at projects.linpro.no
Mon Feb 27 08:47:20 CET 2006


Author: des
Date: 2006-02-27 08:47:19 +0100 (Mon, 27 Feb 2006)
New Revision: 31

Modified:
   trunk/varnish-doc/en/varnish-architecture/article.xml
Log:
Paste large portion of phk's notes.

Modified: trunk/varnish-doc/en/varnish-architecture/article.xml
===================================================================
--- trunk/varnish-doc/en/varnish-architecture/article.xml	2006-02-27 07:28:50 UTC (rev 30)
+++ trunk/varnish-doc/en/varnish-architecture/article.xml	2006-02-27 07:47:19 UTC (rev 31)
@@ -89,9 +89,8 @@
 	<title>Logger</title>
 
 	<para>The Logger keeps logs of various types of events in
-	circular shared-memory buffers.  These buffers must be managed
-	using either POSIX shared memory primitives or file-backed
-	mmap(2).</para>
+	circular shared-memory buffers.  See <xref
+	linkend="sect.logging"/> for details.</para>
 
 	<para>It is the responsibility of each module to feed relevant
 	log data to the Logger.</para>
@@ -99,6 +98,144 @@
     </section>
   </section>
 
+  <section>
+    <title>Configuration</title>
+
+    <para>Policy is configured in a simple unidirectional (no loops,
+    no goto) programming language which is compiled into 'C' and from
+    there binary modules which are dlopen'ed by the main Varnish
+    process.</para>
+
+    <para>The dl object contains one exported symbol, a pointer to a
+    structure which contains a reference count, a number of function
+    pointers, a couple of string variables with identifying
+    information.</para>
+
+    <para>All access into the config is protected by the reference
+    counts.</para>
+
+    <para>Multiple policy configurations can be loaded at the same
+    time but only one is the "active configuration".  Loading,
+    switching and unloading of policy configurations happen via the
+    managment process.</para>
+
+    <para>A global config sequence number is incremented on each
+    switch and policy modified object attributes (ttl, cache/nocache)
+    are all qualified by the config-sequence under which they were
+    calculated and invalid if a different policy is now in
+    effect.</para>
+  </section>
+
+  <section id="sect.logging">
+    <title>Logging</title>
+
+    <para>
+    </para>
+  </section>
+
+  <section id="sect.invalidation">
+    <title>Invalidation</title>
+
+    <para>When a purge request comes in, the regexp is tagged with the
+    next generation number and added to the tail of the list of purge
+    regexps.</para>
+
+    <para>Before a sender transmits an object, it is checked against
+    any purge-regexps which have higher generation number than the
+    object and if it matches the request is sent to a fetcher and the
+    object purged.</para>
+
+    <para>If there were purge regexps with higher generation to match,
+    but they didn't match, the object is tagged with the current
+    generation number and moved to the tail of the list.</para>
+
+    <para>Otherwise, the object does not change generation number and
+    is not moved on the generation list.</para>
+
+    <para>New Objects are tagged with the current generation number
+    and put at the tail of the list.</para>
+
+    <para>Objects are removed from the generation list when
+    deleted.</para>
+
+    <para>When a purge object has a lower generation number than the
+    first object on the generation list, the purge object has been
+    completed and will be removed.  A log entry is written with number
+    of compares and number of hits.</para>
+  </section>
+
+  <section id="sect.management">
+    <title>Management</title>
+
+    <section>
+      <title>Management commands</title>
+
+      <itemizedlist>
+	<listitem>
+	  <para>object_query url -&gt; TTL, size, checksum</para>
+	</listitem>
+	<listitem>
+	  <para>{purge,invalidate} regexp</para>
+	</listitem>
+	<listitem>
+	  <para>object_status url -&gt; object metadata</para>
+	</listitem>
+	<listitem>
+	  <para>load_config filename</para>
+	</listitem>
+	<listitem>
+	  <para>switch_config configname</para>
+	</listitem>
+	<listitem>
+	  <para>list_configs</para>
+	</listitem>
+	<listitem>
+	  <para>unload_config</para>
+	</listitem>
+	<listitem>
+	  <para>freeze 	# stop the clock, freezes the object store</para>
+	</listitem>
+	<listitem>
+	  <para>thaw</para>
+	</listitem>
+	<listitem>
+	  <para>suspend	# stop acceptor accepting new requests</para>
+	</listitem>
+	<listitem>
+	  <para>resume</para>
+	</listitem>
+	<listitem>
+	  <para>stop	# forced stop (exits) varnish process</para>
+	</listitem>
+	<listitem>
+	  <para>start</para>
+	</listitem>
+	<listitem>
+	  <para>restart = "stop;start"</para>
+	</listitem>
+	<listitem>
+	  <para>ping $utc_time -&gt; pong $utc_time</para>
+	</listitem>
+	<listitem>
+	  <para>stats [-mr] -&gt; $data</para>
+	</listitem>
+	<listitem>
+	  <para>zero stats</para>
+	</listitem>
+	<listitem>
+	  <para>help</para>
+	</listitem>
+      </itemizedlist>
+
+      <para>Cluster only:</para>
+      <itemizedlist>
+	<listitem>
+	  <para>config_contents filename $inline -> compilation messages</para>
+	</listitem>
+      </itemizedlist>
+    </section>
+  </section>
+
   <bibliography>
     <title>References</title>
 




More information about the varnish-commit mailing list