Since version 2.1
varnish support, at least partially, the ESI protocol. ESI is very useful to improve the cache hit ratio because it allow the splitting of uncachable dynamic pages into an ‘heavy’ static page and one or several ‘light’ dynamic page bloc.
Enable ESI support
For Varnish 2.x add into the vcl_recv:
For Varnish 3.x the syntax is:
set beresp.do_esi = true;
To test ESI support, you need to create two files. The first will be a simple HTML ‘template’ file. We will call it
<title>ESI Test Page</title>
Next we need a file to generate the ‘dynamic’ content. A very simple PHP script like this we be enough:
echo "ESI is correctly interpreted";
If ESI support is correctly enabled, calling the first page will result into calling the second file as well, displaying the proper “ESI is correctly interpreted” string.
TERM environment variable is used by your terminal emulator to indicate which type of control string it supports. For the most part you should not override this variable, but there is a narrow set of circumstances where the default value can be incorrect or at least not optimal.
For example in most distributions the default value for a console terminal is
linux and for a graphical terminal
xterm. That’s fine, but don’t allow you to enjoy
screen 256 color mode in graphical mode.
xterm only supports 16 colors and this value is specify into the
As you can image, changing the
xterm entry would have made users of the newer versions happy but also broken the configuration for others. Instead a new value
xterm-256color was declared. That may seems fine but when you log in remotely to machines with an older terminal database, the value isn’t recognized.
In this case the only viable solution left is to override the
TERM value in order to unset the 256 color mode. You can do it by adding something like that to the
.bash_profile on the remote machine:
if echo $TERM | grep -q -- '-256color'; then
export TERM=`echo -n $TERM | sed 's/-256color//'`
GoAccess is a real-time ncurse weblog analyzer and interactive viewer. Contrary to Awstats and other similar product, GoAccess doesn’t keep any “history”, but in exchange it’s way more faster. Having ‘on the fly’ HTTP statistics is extremely useful when load suddenly increase on a front webserver.
For analyzing a given log file use the
-f option, like this:
goaccess -f /var/log/apache/access.log
If you don’t use standard NCSA or common log format, you can specify the log format with
--log-format=. For a more permanent solution you can redefine the
log-format value inside the
/etc/goaccess.conf setting file.
You can also generate an html report like this:
goaccess -f /var/log/apache/access.log -a -o report.html