Documentation overhaul

parent 3370a4c4
......@@ -33,7 +33,8 @@
......@@ -9,10 +9,6 @@ EXTRA_DIST = README.rst LICENSE CONTRIBUTING.rst INSTALL.rst
README.rst: src/vdp_pesi.vcc
cp src/ README.rst
$(MAKE) $(AM_MAKEFLAGS) -C src coverage
This diff is collapsed.
......@@ -62,47 +62,6 @@ SYNOPSIS
.. _varnishstat(1):
This documentation is detailed on purpose. It aims to explain well
how this VMOD works and how optimizations can be tuned.
We welcome all users to read the documentation, but many users will
neither want to nor need to understand the details. Thus, here is what
you *really* need to know:
* See `INSTALL.rst <INSTALL.rst>`_ in the source repository for
installation instructions.
* To use pESI, add to the top of your VCL::
import pesi;
and to your ``sub vcl_deliver {}``, add::
This should be added *after* any modification of ``resp.do_esi``,
``req.http.Accept-Encoding``, ``req.http.Range`` or
``resp.filters``, if these exist.
To be safe, ``pesi.activate()`` can be called before any
``return(deliver)`` in ``sub vcl_deliver {}``.
* If you call ``pesi.activate()``, call it unconditionally and on all
ESI levels. Read this documentation for details.
It is possible that your current configuration of system resources,
such as thread pools, workspaces, memory allocation and so forth, will
suffice after this simple change, and will need no further
But that is by no means ensured, since pESI uses system resources
differently from standard ESI. Understanding these difference, and how
to monitor and manage resource usage affected by pESI, is a main focus
of the detailed discussion that follows.
......@@ -132,11 +91,11 @@ Parallel ESI processing is enabled by invoking |pesi.activate()|_ in
``vcl_deliver {}``::
import pesi;
sub vcl_backend_response {
set beresp.do_esi = true;
sub vcl_deliver {
......@@ -809,42 +768,6 @@ at different times, depending on the order of events, and on whether
or not we use (partial) sequential delivery (for example, when no
threads are available).
All versions of the VDP require strict ABI compatibility with Varnish,
meaning that it must run against the same build version of Varnish as
the version against which the VDP was built. This means that the
"commit id" portion of the Varnish version string (the SHA1 hash) must
be the same at runtime as at build time.
See `INSTALL.rst <INSTALL.rst>`_ in the source repository.
.. _Otto GmbH & Co KG:
Most of the development work of this vmod in 2019 and 2020 has been
sponsored by `Otto GmbH & Co KG`_.
.. _BoardGameGeek:
The initial release to the public in 2021 has been supported by
For community support, please use `Gitlab Issues`_.
For commercial support, please contact
.. _Gitlab Issues:
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment