Varnish HTTP Accelerator Integration - The Varnish control terminal is not responding

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
alexus's picture

I'm trying to use Varnish HTTP Accelerator Integration module ( http://drupal.org/project/varnish ) in our environment and I'm getting following error under "admin/settings/varnish"

Status: The Varnish control terminal is not responding at 172.16.0.110 on port 6082.

for troubleshooting purposes I did

telnet 172.16.0.110 6082

Trying 172.16.0.110...
Connected to 172.16.0.110.
Escape character is '^]'.

200 154

Varnish HTTP accelerator CLI.

Type 'help' for command list.
Type 'quit' to close CLI session.

quit
500 22
Closing CLI connection
Connection closed by foreign host.

so communication between them seems to be Ok

any ideas?

Comments

At the risk of asking a daft

alexharries's picture

At the risk of asking a daft question, have you tried (and is it possible for you to try) a different port to rule out some oddities in the handling of connections (firewalls, etc)?

I assume this isn't localhost is it? (If it were, you could try 127.0.0.1 as the IP address).

/Al

it's not a firewall issue,

alexus's picture

it's not a firewall issue, since i can telnet from that place to varnish's port
there is a communication between them, its just for one reason or another varnish's plugin doesn't sees it

Also, is the php sockets

Steven Merrill's picture

Also, is the php sockets extension enabled? I've had clients who had to recompile PHP in order to get this working.

do you know which extension

alexus's picture

do you know which extension is it exactly? I've looked and I only found this:

just looked at phpinfo(); and found this

sockets
Sockets Support enabled

so if you were referring to that, this is enabled

Two checks

fgm's picture

Two checks may be needed:

  • try increasing connection timeout well above its current value
  • try accessing the Varnish server on the "normal" IP, not the localhost one

do you know exactly which

alexus's picture

do you know exactly which timeout? page renders pretty quickly though, doesn't seems like it's timeout issue...
not using localhost so i'm already accessing it via "normal" ip

A little more info about our setup

repoman's picture

Varnish is running on a separate VM from our Pressflow VM. Like Alexus wrote we are able to connect on that port from the pressflow server to the Varnish proxy. However, I did open up UDP in addition to TCP on that port in hopes that was it. We use the PHP from RedHat so it's not compiled.

The reason we are trying to do this is that we have some Front-end folk that need to have the ability to Flush the cache via Drupal when they put up an urgent article/node, etc. Currently, Flushing all caches does not clear the Varnish cache and we were looking at this module as a method to do that. So if you know of another way that we can accomplish this same task we are all ears.

Thanks again!

Spotty reception

repoman's picture

Ok for some reason we see it is running and then it isn't. The status toggles back and forth between:

Status:
Varnish running. Observe more detailed statistics here.

Status:
The Varnish control terminal is not responding at xxx.xxx.0.110 on port 6082.

When I click on the statistics I do see information, so it is communicating sometimes but is there any way to see what might be causing the 'Spotty Reception'?

And this is what we see from the 'statistics' on our Staging pressflow VM

  384  Client connections accepted
    1526  Client requests received
     532  Cache hits
     785  Cache misses
     295  Backend conn. success
     626  Backend conn. reuses
     285  Backend conn. was closed
     911  Backend conn. recycles
     866  Fetch with Length
      27  Fetch chunked
      21  Fetch zero len
      19  N struct sess_mem
       1  N struct sess
     777  N struct object
     781  N struct objectcore
     470  N struct objecthead
    1555  N struct smf
       1  N large free smf
       1  N struct vbe_conn
      10  N worker threads
      10  N worker threads created
       3  N backends
       6  N expired objects
     529  N LRU moved objects
     850  Objects sent with write
     383  Total Sessions
    1526  Total Requests
       6  Total pipe
     129  Total pass
     914  Total fetch
  485895  Total header bytes
14135114  Total body bytes
     115  Session Closed
    1446  Session Linger
     607  Session herd
  106679  SHM records
   11092  SHM writes
       5  SHM MTX contention
    1676  allocator requests
    1554  outstanding allocations
16957440  bytes allocated

3643408384 bytes free
74 SMS allocator requests
9472 SMS bytes allocated
9472 SMS bytes freed
915 Backend requests made
1 N vcl total
1 N vcl available
30 N total active purges
30 N new purges added
317 N objects tested
634 N regexps tested against
28 N duplicate purges removed
1317 HCB Lookups without lock
468 HCB Lookups with lock
468 HCB Inserts
8859 Client uptime

Now using 1.0

repoman's picture

Earlier we were using the HEAD version and that seemed to give us inconsistent communication with Varnish. Now we downgraded that module to the 1.0 release and it appears to be communicating consistently. Fingers crossed that it does what we need. Thanks for you help.

Hi, Another way to do is to

vegardx's picture

Hi,

Another way to do is to call purge in the VCL. We have a setup where we just issue /purgeall to the top level domain, and it purges the cache with respect to cache headers, so that all new pages and updated pages will get updated.

https://www.varnish-cache.org/docs/trunk/tutorial/purging.html

Also, with Varnish 2.x you can have a challanging respons. If that is properly setup than the varnish module won't work. But that said, it's no issue to use varnish without a challanging response...

--
Vegard

Try using another port

gregbrown's picture

I had an issue with running Varnish on this port with a cents installation.. changing the port fixed it.... just a suggestion.

Switching ports didn't help

nicxvan's picture

Switching ports didn't help me.