Mailing List Archive

This mail has stayed unanswered on varnish-dist, but I think someone on
varnish-misc may be able to answer.

Ingvar


Steve Scally <steve at kcilink.com> said on varnish-dist at projects.linpro.no
> Hello,
>
> I have just started to use varnish and was looking into the default
> cache time of an object / item, etc. I know the default_ttl is 120
> seconds and I was looking to change that to 3600 seconds. From the
> documentation and previous mail archives I have found three ways to
> set this. Two ways are through the rc.d and rc.conf files and the
> last is through the vcl.
>
> A. /usr/local/etc/rc.d/varnishd file
>
> Create a variable called varnishd_ttl and set it to 3600.
> : ${varnishd_ttl="3600"}
>
> Edit varnishd_flags and add my new variable
> : ${varnishd_flags="-P ${pidfile} -a ${varnishd_listen} -f $
> {varnishd_config} -T ${varnishd_telnet} -s ${varnishd_storage} -t $
> {varnishd_ttl}"}
>
> B. /etc/rc.conf
>
> Create a variable called varnishd_ttl and set it to 3600.
> : ${varnishd_ttl="3600"}
>
> Edit varnishd_flags and add my new variable
>
> varnishd_enable="YES"
> varnishd_listen="mb-prv.kcilink.com:80"
> varnishd_storage="file,/var/tmp,512M"
> varnishd_config="/usr/local/etc/varnish/morebiz.vcl"
> varnishd_ttl="3600"
> varnishd_flags="-P ${pidfile} -a ${varnishd_listen} -f $
> {varnishd_config} -T ${varnishd_telnet} -s ${varnishd_storage} -t $
> {varnishd_ttl}"
>
> c. /usr/local/etc/varnish/default.vcl
>
> *if (obj.ttl < 3600s) {
> set obj.ttl = 3600s;
> }
>
> *not exact just scratch code.
>
> Now my question, is there a more direct way to change the default_ttl
> either through configuration files or .vcl file? If these are pretty
> much the only three ways that is fine, I just wanted to make sure I
> wasn't skipping over any options. Thank you in advance for your help.
>
> Steve

Ingvar Hagelund <ingvar at linpro.no> writes:
> Steve Scally <steve at kcilink.com> writes:
> > Now my question, is there a more direct way to change the default_ttl
> > either through configuration files or .vcl file? If these are pretty
> > much the only three ways that is fine, I just wanted to make sure I
> > wasn't skipping over any options. Thank you in advance for your help.
> This mail has stayed unanswered on varnish-dist, but I think someone on
> varnish-misc may be able to answer.

The default TTL can be configured on the command line with -t ttl or
(as any other run-time parameter) with -p default_ttl=ttl. The
FreeBSD rc script does not currently have a variable for setting the
default TTL directly, nor a mechanism for setting run-time parameters
in general. I could either add code to the rc script to read in a
list of run-time parameters and pass them on the command line, or we
could add code to varnishd to read initial values from a file. I
prefer the former, but we need to add similar code to the Debian and
RedHat init scripts as well.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

* Steve Scally
>>> Now my question, is there a more direct way to change the default_ttl
>>> either through configuration files or .vcl file? If these are pretty
>>> much the only three ways that is fine, I just wanted to make sure I
>>> wasn't skipping over any options. Thank you in advance for your help.
>>>
* Dag-Erling Sm?rgrav
> The default TTL can be configured on the command line with -t ttl or
> (as any other run-time parameter) with -p default_ttl=ttl. The
> FreeBSD rc script does not currently have a variable for setting the
> default TTL directly, nor a mechanism for setting run-time parameters
> in general. I could either add code to the rc script to read in a
> list of run-time parameters and pass them on the command line, or we
> could add code to varnishd to read initial values from a file. I
> prefer the former, but we need to add similar code to the Debian and
> RedHat init scripts as well.
>
The RedHat and Debian init scripts reads default values from their
respective defaults file, that is, for RedHat, /etc/sysconfig/varnish,
and for Debian, /etc/defaults/varnish. In that file, you can add any
command line parameter to varnishd, not only those that are commented in
the file. Do we need any other mechanism for adding runtime parameters?
A full-fledged configuration file parser in varnishd?

Ingvar


redhat$ tail -4 /etc/sysconfig/varnish

## Alternative 4, Do It Yourself. See varnishd(1) for more information.
#
# DAEMON_OPTS=""

Ingvar Hagelund <ingvar.hagelund at linpro.no> writes:
> The RedHat and Debian init scripts reads default values from their
> respective defaults file, that is, for RedHat, /etc/sysconfig/varnish,
> and for Debian, /etc/defaults/varnish. In that file, you can add any
> command line parameter to varnishd, not only those that are commented in
> the file. Do we need any other mechanism for adding runtime parameters?
> A full-fledged configuration file parser in varnishd?
>
> Ingvar
>
>
> redhat$ tail -4 /etc/sysconfig/varnish
>
> ## Alternative 4, Do It Yourself. See varnishd(1) for more information.
> #
> # DAEMON_OPTS=""

The problem is that if you define DAEMON_OPTS, none of the other knobs
work, right? FreeBSD at least has that issue:

: ${varnishd_enable="NO"}
: ${varnishd_listen=":6081"}
: ${varnishd_config="%%PREFIX%%/etc/varnish/default.vcl"}
: ${varnishd_telnet="localhost:6082"}
: ${varnishd_storage="file,/tmp,50%"}
: ${varnishd_flags="-P ${pidfile} -a ${varnishd_listen} -f ${varnishd_config} -T ${varnishd_telnet} -s ${varnishd_storage}"}

if you define varnishd_flags, you have to specify everything manually,
since the other knobs only serve to populate the default value for
varnishd_flags.

Of course, we could introduce a varnishd_extra_flags knob that just
gets appended to varnishd_flags... not very elegant, though.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

I take this off varnish-misc as it is quite distro specific.

* Ingvar Hagelund
>> The RedHat and Debian init scripts reads default values from their
>> respective defaults file, that is, for RedHat, /etc/sysconfig/varnish,
>> and for Debian, /etc/defaults/varnish.

* Dag-Erling Sm?rgrav
> The problem is that if you define DAEMON_OPTS, none of the other knobs
> work, right? FreeBSD at least has that issue:
>
> if you define varnishd_flags, you have to specify everything manually,
> since the other knobs only serve to populate the default value for
> varnishd_flags.

At least for RedHat, there are no other knobs. All the startup
configuration is in the file. There are no hard coded values in the init
script. The init script won't start varnishd if DAEMON_OPTS is empty, or
the config file does not exist.

if [ "$DAEMON_OPTS" = "" ]; then
echo "\$DAEMON_OPTS empty."
echo -n "Please put configuration options in
/etc/sysconfig/varnish"
echo_failure

The configuration file is fairly documented with the most used options,
and points to the manpage for more advanced users.

I would not know if this is suitable for FreeBSD ports, but I think it's
quite a clean method to ensure that the user knows what she wants to
change before changing it. As for myself, I dislike magic "invisible"
default values.

Ingvar

--
Buddha wears an iPod

Ingvar,

Sorry, I did not include my OS information, as the location of the
files I was referencing pointed to FreeBSD or a BSD like system. In
the future I will clarify.

Dag-Erling,

"I could either add code to the rc script to read in a list of run-
time parameters and pass them on the command line."

This would work great something like this: varnishd_ttl or
varnishd_default_ttl etc,

/usr/local/etc/rc.d/varnishd

: ${varnishd_enable="NO"}
: ${varnishd_listen=":6081"}
: ${varnishd_config="%%PREFIX%%/etc/varnish/default.vcl"}
: ${varnishd_telnet="localhost:6082"}
: ${varnishd_storage="file,/tmp,50%"}
:${varnishd_ttl="3600"}
: ${varnishd_flags="-P ${pidfile} -a ${varnishd_listen} -f $
{varnishd_config} -T ${varnishd_telnet} -s ${varnishd_storage} -t $
{varnish_ttl}"}

This will then allow me to add something like this to my /etc/rc.conf
file:

varnishd_enable="YES"
varnishd_listen=":80"
varnishd_storage="file,/var/tmp,512M"
varnishd_config="/usr/local/etc/varnish/default.vcl"
varnishd_ttl="3600"

To better understand my setup, all our machines have their /etc/
configs auto generated using protofs. This way each systems
configurations do not have be kept in subversion only the template.
Then by using the template all the configs can be regenerated. So by
enabling this new variable I simply add varnishd_ttl and the value I
would like and then regenerate the configs and it produces the
rc.conf above.

services :
varnishd :
apache22 :
varnishlog :
extraconfig:
varnishd_listen : :80
varnishd_config : /usr/local/etc/varnish/default.vcl
varnishd_storage : file,/var/tmp,512M
varnishlog_file : /var/log/varnish/varnish-cache.log
varnishd_ttl : 3600


Regards,

Steve


On Oct 24, 2007, at 4:33 AM, Ingvar Hagelund wrote:

> I take this off varnish-misc as it is quite distro specific.
>
> * Ingvar Hagelund
>>> The RedHat and Debian init scripts reads default values from their
>>> respective defaults file, that is, for RedHat, /etc/sysconfig/
>>> varnish,
>>> and for Debian, /etc/defaults/varnish.
>
> * Dag-Erling Sm?rgrav
>> The problem is that if you define DAEMON_OPTS, none of the other
>> knobs
>> work, right? FreeBSD at least has that issue:
>>
>> if you define varnishd_flags, you have to specify everything
>> manually,
>> since the other knobs only serve to populate the default value for
>> varnishd_flags.
>
> At least for RedHat, there are no other knobs. All the startup
> configuration is in the file. There are no hard coded values in the
> init
> script. The init script won't start varnishd if DAEMON_OPTS is
> empty, or
> the config file does not exist.
>
> if [ "$DAEMON_OPTS" = "" ]; then
> echo "\$DAEMON_OPTS empty."
> echo -n "Please put configuration options in
> /etc/sysconfig/varnish"
> echo_failure
>
> The configuration file is fairly documented with the most used
> options,
> and points to the manpage for more advanced users.
>
> I would not know if this is suitable for FreeBSD ports, but I think
> it's
> quite a clean method to ensure that the user knows what she wants to
> change before changing it. As for myself, I dislike magic "invisible"
> default values.
>
> Ingvar
>
> --
> Buddha wears an iPod
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.linpro.no/pipermail/varnish-dist/attachments/20071024/767976cc/attachment.htm

Steve Scally <steve at kcilink.com> writes:
> "I could either add code to the rc script to read in a list of run-
> time parameters and pass them on the command line."
>
> This would work great something like this: varnishd_ttl or
> varnishd_default_ttl etc,

default_ttl is only one of about two dozen run-time parameters, I
don't want to have to add a separate rc variable for each of them.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

> Steve Scally <steve at kcilink.com> writes:
>> "I could either add code to the rc script to read in a list of run-
>> time parameters and pass them on the command line."
>>
>> This would work great something like this: varnishd_ttl or
>> varnishd_default_ttl etc,
>
> default_ttl is only one of about two dozen run-time parameters, I
> don't want to have to add a separate rc variable for each of them.
>
> DES
> --
> Dag-Erling Sm?rgrav
> Senior Software Developer
> Linpro AS - www.linpro.no

Yes, after thinking about it adding a value for every option would be
cumbersome, especially every time a new parameter option was added.
The reason this question even came about was during my load testing
when I needed to change the default cache time to see performance
increases / decreases and in my previous post it also helps with
generating config files. In this view however, I was only concerned
with the default_ttl and did not stop to think about the other
configuration options. As it stands the parameter is configurable 3
ways and the default works fine for me as is. Although my priority
is not high for this ,it would be a nice configuration option to
have. How do you handle future feature requests? Should I create a
ticket requesting this feature?

Steve