Varnish 3 and statistics

simply for reference here, from http://drupal.org/node/1179964#comment-4634044

-----------------------------
#19
Posted by cedarm on June 21, 2011 at 12:10pm

IMHO trying to preserve the stats page is probably not worth the effort*. Don't forget that varnish is often on a different machine, so you can't just run varnishstat from a web server. (*we run a dedicated varnish box)
-----------------------------
#20
Posted by x746554 on June 21, 2011 at 12:24pm

i'll disagree.

to the extent possible, providing the tools within Drupal & its modules to monitor what's going on in/with Drupal is a good idea. not all Drupal 'mgrs' will be given shell access @ the server ...
'stats' was a valued part of this module for v6 -- why would it be LESS so for D7?

as for bits-n-pieces running on other boxes -- that's true of, and possible for, just about everything. THAT config is in the vast minority, and IMHO, hardly a guideline for deciding mainstream applicability/value (inasmuch anyone using Varnish is in the mainstream in the 1st place ...)
-----------------------------

@ my ./admin/config/development/varnish

I've set

  Varnish Control Terminal
   127.0.0.1:6080

I've been working 'elsewhere', not on Varnish for a bit, but noticed today two additional messages at the bottom of the page, in addition to the usual "Server OK"

Status

    Server OK: 127.0.0.1:6080 Varnish running. Observe more detailed statistics here.
    Server down: {$server}:{$port} The Varnish control terminal is not responding at attributes_array on port .
    Server down: {$server}:{$port} The Varnish control terminal is not responding at theme_hook_suggestions on port .

A bit confused as to what these messages are telling me -- the control terminal itself IS running -- and/or why they've shown up.

Is this likely indiciative of a problem? Or just part of the not-yet-fully-ported-to-D7 state of the module, and perhaps the deprecated 'stats' cmd?

simple enough to find the source, if not the cause, of the issue. checking,

 grep -rlni theme_hook_suggestions `grep -rlni attributes_array .`
  ./all/modules/entity/entity.module
  ./all/modules/devel_themer/devel_themer.module

then,

 drush pm-disable devel_themer

@ my ./admin/config/development/varnish, back to just:

Status

    Server OK: 127.0.0.1:6080 Varnish running. Observe more detailed statistics here.

as before.

Another option could be to use the Varnish PECL Extension:

• http://pecl.php.net/package/varnish
• http://www.php.net/manual/en/book.varnish.php

This provides a lot more than just stats, but that could be a good place to start.

Requirements for the Varnish PECL extension:

Varnish 3

e.g. CentOS/Red Hat

rpm --nosignature -i http://repo.varnish-cache.org/redhat/varnish-3.0/el6/noarch/varnish-release/varnish-release-3.0-1.el6.noarch.rpm
yum install varnish

Varnish Libs

e.g.

yum install varnish-libs-devel

Varnish PECL

e.g.

pecl install varnish

As usual, install any dependencies as required.

Here's a start. This adds support for varnish stats using the Varnish PECL extension.

It could probably fail more gracefully if version 2 is selected in the admin screen when running version 3. Although this could actually be done within _varnish_terminal_run().

Seems like the PECL extension could be used for everything else this module does. Perhaps it would be a good idea to create a new branch of this module that uses PECL instead of control terminal. I'm not sure what the advantages/disadvantages are though, I guess PECL extension is an additional requirement. Advantage is probably easier to maintain, no need for low level code like _varnish_read_socket().

I brought this up in another issue and I tend to agree: #2235433: Make module compatible with Varnish Cache 4.0.x

The complexity of the code required to maintain 2 separate methods was given as a reason not to go down this path.

2 options I can think of:

1. Structure the main module so it can hand off Varnish commands to the appropriate plugin (terminal or PECL) with either a separate PECL module or include file
2. Write a completely independent module (varnish_pecl?)

Option 2 would duplicate a lot of work but would be the cleanest. It would also be a chance to refactor a lot of the code. Perhaps this could be done for a Drupal 8 version.

The main problem with option 2 would be the existence of 2 separate Varnish modules, with the associated lack of focus and duplicated effort.