The stats command has been removed from the varnish control terminal as of Varnish 3 beta 2. The recommended way of getting statistics from varnish is now to use the varnishstat command. Since the Varnish module has only dealt with the varnish control terminal previously, we need to discuss if, and if so, how we are going to work with getting varnish statistics in the future. Possible solutions are:
* Don't show statistics at all. After all, we can only get data from the current web node we are running our scripts on, provided that the web user has access to the command.
* Provide a way to enter the path to varnishstat. This will restore the functionality, at least for people who only have one varnish server.
Comment | File | Size | Author |
---|---|---|---|
#6 | varnish3_statistics-1195678-6.patch | 2.33 KB | imclean |
Comments
Comment #1
_-. CreditAttribution: _-. commentedsimply 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 ...)
-----------------------------
Comment #2
_-. CreditAttribution: _-. commented@ my ./admin/config/development/varnish
I've set
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"
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?
Comment #3
_-. CreditAttribution: _-. commentedsimple enough to find the source, if not the cause, of the issue. checking,
then,
@ my ./admin/config/development/varnish, back to just:
as before.
Comment #4
imclean CreditAttribution: imclean commentedAnother option could be to use the Varnish PECL Extension:
This provides a lot more than just stats, but that could be a good place to start.
Comment #5
imclean CreditAttribution: imclean commentedRequirements for the Varnish PECL extension:
Varnish 3
e.g. CentOS/Red Hat
Varnish Libs
e.g.
yum install varnish-libs-devel
Varnish PECL
e.g.
pecl install varnish
As usual, install any dependencies as required.
Comment #6
imclean CreditAttribution: imclean commentedHere'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().
Comment #7
mstrelan CreditAttribution: mstrelan commentedSeems 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().
Comment #8
imclean CreditAttribution: imclean commentedI 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:
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.