James Quacinella wrote:
> I use monit for monitoring programs. Here is a snippet I had used when
> monitoring a varnish install (too bad it never went into production;
> change values to you liking / environment):
>
A Billion thanks to you :)
I have been looking for a tool that could do this
Manuel Amador (Rudd-O) wrote:
> The optimum behaviour would be Varnish caching static files
> (img,css,jpg,png, based on response HTTP headers) and not caching
> dynamic ones. But as it currently stands, Varnish configuration
> language doesn't allow caching to be controlled based on the response
On Tuesday 03 July 2007 16:30, Dag-Erling Smørgrav wrote:
> varnishncsa shouldn't care, as it processes the log file linearly, but I
> generally prefer to rotate by size.
Hm.. ok. But that would have me running awstats at odd times..
Wil just have to try it out I guess
> Is this a 32-bit machine
Gaute Amundsen wrote:
> On Tuesday 03 July 2007 11:27, Dag-Erling Smørgrav wrote:
>
>>
>> I would recommend retrieving a page (or a set of pages). Simply
>> checking the pid won't help you if Varnish has gone off into la-la land,
>> or been SIGSTOPped or something.
>>
>> DES
>>
> Not what
Gaute Amundsen <[EMAIL PROTECTED]> writes:
> On Tuesday 03 July 2007 16:05, Dag-Erling Smørgrav wrote:
> > Gaute Amundsen <[EMAIL PROTECTED]> writes:
> > > Rotation is weekly, and the previous logs have sane dates.
> > Weekly rotation is probably far too seldom, Varnish can easily generate
> > seve
On Tuesday 03 July 2007 16:05, Dag-Erling Smørgrav wrote:
> Gaute Amundsen <[EMAIL PROTECTED]> writes:
> > Rotation is weekly, and the previous logs have sane dates.
>
> Weekly rotation is probably far too seldom, Varnish can easily generate
> several gigabytes of log data *per hour* under high loa
Gaute Amundsen <[EMAIL PROTECTED]> writes:
> I was finding quite a bit of "Pipe Shut" just running varnishlog -o.
> I's out of my buffer, so I cant paste it in right now, but could it
> bee that I was opening to many pipes?
"pipe shut" happens when either the backend or the client closes the
conne
Gaute Amundsen <[EMAIL PROTECTED]> writes:
> Rotation is weekly, and the previous logs have sane dates.
Weekly rotation is probably far too seldom, Varnish can easily generate
several gigabytes of log data *per hour* under high load.
Have you checked the file size limit (ulimit -f) that varnishlo
Hm..
I was finding quite a bit of "Pipe Shut" just running varnishlog -o.
I's out of my buffer, so I cant paste it in right now, but could it bee that I
was opening to many pipes?
I the default action in vcl_recv was pipe, and only a few hosts would get a
lookup... Trying with pass now, and it
On Tuesday 03 July 2007 15:18, Dag-Erling Smørgrav wrote:
> Gaute Amundsen <[EMAIL PROTECTED]> writes:
> > We have had logging running for about a week now with no apparent
> > problems, but yesterday I routed all our traffic into varnish, and now
> > bad things happen.
> >
> > /var/log/varnish/var
Gaute Amundsen <[EMAIL PROTECTED]> writes:
> We have had logging running for about a week now with no apparent
> problems, but yesterday I routed all our traffic into varnish, and now
> bad things happen.
>
> /var/log/varnish/varnish.log just stops growing after a while and a
> tail -n 1 gives me p
Hi again.
We have had logging running for about a week now with no apparent problems,
but yesterday I routed all our traffic into varnish, and now bad things
happen.
/var/log/varnish/varnish.log just stops growing after a while and a tail -n 1
gives me pages after pages of:
Pipe Shut write(r
TiAMO <[EMAIL PROTECTED]> writes:
> I need to add more backend servers and req.http.Host definitions quite
> often, is there a way to change the config without restarting varnish
> and loose the entire cache?
vcl.load newconf /my/new/config
vcl.use newconf
> also is it possible to make varnish li
In message <[EMAIL PROTECTED]>, TiAMO writes:
>I need to add more backend servers and req.http.Host definitions quite often,
>is there a way to change the config without restarting varnish and loose the
>entire cache?
Yes, you can load a new VCL code from the CLI interface with no disruption
to
I need to add more backend servers and req.http.Host definitions quite often,
is there a way to change the config without restarting varnish and loose the
entire cache?
Or is it just simpler to have a backend on loopback and write a separate app
to handle the backend distribution without having
jean-marc pouchoulon <[EMAIL PROTECTED]> writes:
> the problem is not related to varnish , disable compression and all is
> running.
Ah, it *is* related to Varnish: 1.0.4 doesn't support Vary: headers.
Compression works fine with trunk, and with the upcoming 1.1.
DES
--
Dag-Erling Smørgrav
Senio
Bonjour,
the problem is not related to varnish , disable compression and all is
running.
Thanks for your time and work et sorry for this false alarm
jean-marc.
Dag-Erling Smørgrav a écrit :
> jean-marc pouchoulon <[EMAIL PROTECTED]> writes:
>
>> Using varnish with this url:
>>
>> http://p
Poul-Henning Kamp wrote:
> The critical question is how we define "backend is down" and how
> fast and efficient we can detect it.
Right. I tend to like the Perlbal approach: Issue a http OPTIONS and
check if we get anything back from the backend. It is quite lightweight.
/Anton
__
On Tuesday 03 July 2007 11:27, Dag-Erling Smørgrav wrote:
> Gaute Amundsen <[EMAIL PROTECTED]> writes:
> > Now the question is, how do I best detect if varnsih should have a
> > problem? Would it be reasonably reliable to just chek if the pid from
> > /var/run/varnish.pid is running, do I need to
Hello all,
when working for speedera, we use to have the ability to define
two time-out timers in the config: timer1 and timer2
timer1 would define the time to receive the TCP ack of the http
request to the backend. (or something equivalent)
timer2 the time to receive the first chunk of http da
In message <[EMAIL PROTECTED]>, Christoph writes:
>i'd like to implement dirty-caching using varnish.
I'm busy twisting the variable visibility in VCL into proper shape
right now, and that will move us a bit closer to what your want
to do.
The critical question is how we define "backend is down"
- Anup Shukla <[EMAIL PROTECTED]> wrote:
> Manuel Amador (Rudd-O) wrote:
> > site is cached according to Varnish default policies. You have not
> > provided a single counterexample or a single snippet of VCL that
> > could solve the problems I have, or a single snippet of VCL that you guys
> >
- Dag-Erling Smørgrav <[EMAIL PROTECTED]> wrote:
> Christoph <[EMAIL PROTECTED]> writes:
> > So what is dirty caching and why use it? Think of a very unreliable
> > backend. If varnish can't reach it's backend, it will simply return
> > the last content it has (even if the content is stale). Th
Christoph <[EMAIL PROTECTED]> writes:
> So what is dirty caching and why use it? Think of a very unreliable
> backend. If varnish can't reach it's backend, it will simply return
> the last content it has (even if the content is stale). That way i can
> cover hickups.
It's on our list for 2.0, and
Gaute Amundsen <[EMAIL PROTECTED]> writes:
> Now the question is, how do I best detect if varnsih should have a
> problem? Would it be reasonably reliable to just chek if the pid from
> /var/run/varnish.pid is running, do I need to fetch a page, or is
> there some better way?
I would recommend re
- Gaute Amundsen <[EMAIL PROTECTED]> wrote:
> I have come to understand that in some builds under some conditions
> varnish
> may hang or a crash. (we run 1.0.4-3el4.i386.rpm)
Hi Gaute,
I'll just say that in my experience Varnish has proven itself to be extremely
stable. We actually run 1.0
26 matches
Mail list logo
