VARNISH 3.0 Milan Release Party

Yesterday I was at the Milan VARNISH 3.0 Release Party hosted by ZephirWorks to make a “lightning talk” version of my “Varnish e caching di applicazioni Rails” talk I gave at the last RubyDay.

It was very interesting follow the lightning talks because they gave me new ideas on how to integrate Varnish in the application architecture not only to be the “http accelerator” but to be an active architecture component to separate concerns and responsibilities and have much simpler piece of software.

I had the opportunity to have a deeper understanding on what to watch if varnish is in a good shape or not, good stuffs.

I was impressed by so many people were there for a niche’s software, in italy at least. I think it a good starting point to create a devops community… as discussed yesterday we should start organize some sort of local user-group to start sharing experiences and trying ideas.

I hope to find their slides somewhere to review them 🙂

Well done!


Varnish won’t start

This morning I’ve updated our amazon 32bit image with varnish.
After I applied the current configuration used on our 64bit image (on which it works flawlessly) varnish was able to start only the admin interface.

Logging in in the admin interface and asking for the status I was receiving:

200 22      
Child in state stopped

And trying to start it:

child (30152) Started
Pushing vcls failed: CLI communication error (hdr)
Stopping Child
200 0       

Child (30152) died signal=11
Child (-1) said 
Child (-1) said Child starts
Child cleanup complete

the options I was originally using were:

DAEMON_OPTS="-a :80 \
-T \
-smalloc,1GB \
-f /etc/varnish/default.vcl \
-u ubuntu \
-g ubuntu \
-p sess_workspace=262144 \
-p listen_depth=2048 \
-p overflow_max=2000 \
-p ping_interval=2 \
-p log_hashstring=off \
-h classic,5000009 \
-p lru_interval=60 \
-p esi_syntax=0x00000003 \
-p thread_pool_add_delay=2 \
	-p thread_pools=2 \
	-p thread_pool_min=100 \
	-p thread_pool_max=4000 \
-p shm_workspace=32768 \
-p default_grace=3600 \
-p sess_timeout=10 \
-p pipe_timeout=10 \
-p send_timeout=10"

Using the “-d” option I was able to test all the options and at the end the problem was with:

-p sess_workspace=262144

It was too large for a 32bit system as stated on the varnish documentation:

Be aware that on 32 bit systems, certain default values, such as
sess_workspace (=16k) and thread_pool_stack (=64k) are reduced 
relative to the values listed here, in order to conserve VM space.