Re: Question about threads
Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... If I want to have Debian, is it AMD64 version that I should go for? (OT) / E Poul-Henning Kamp skrev: > In message <[EMAIL PROTECTED]>, Erik Torlen writes: > >> I still have the same problem :( >> The threads are created up to 238 where they are stopped, even if I set >> threads_max = 1000 and threads_pools = 2 (or 3). >> >> I also tested the tips and decreased the stack sixe to 512 and increased >> overflow_max to 1% . >> >> Any idea what could be wrong? >> > > Are you running on a 32bit or 64bit system ? > > On a 32bit system you may simply be running out of address-space... > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
I still have the same problem :( The threads are created up to 238 where they are stopped, even if I set threads_max = 1000 and threads_pools = 2 (or 3). I also tested the tips and decreased the stack sixe to 512 and increased overflow_max to 1% . Any idea what could be wrong? / E [EMAIL PROTECTED] skrev: > Thanks for the tips, I will test this and come back with the result. > > / E > > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
What I should mention is that the problem can be solved by another method.
If I remove the Cookie2 AND TE header it all works out fine:
remove req.http.Cookie2;
remove req.http.TE;
if(req.request != "GET" && req.request != "HEAD") {
set req.http.Connection = "close";
pass;
}
This works!
But I must remove BOTH Cookie2 and TE header, else it wont work.
/ Duja
Poul-Henning Kamp skrev:
> In message <[EMAIL PROTECTED]>, Erik Torlen writes:
>
>
>> My vcl has this code when POST are received:
>>
>>if(req.request != "GET" && req.request != "HEAD") {
>>set req.http.Connection = "close";
>>pass;
>>}
>>
>> This code usually works with FF and IE but NOT with Opera.
>>
>> If I remove "set req.http.Connection = "close";"
>>
>> the login process works with no problem.
>>
>> I have had problems with POSTs before, thats why I've been using
>> Connection = "close" on POSTs.
>>
>
> I'm not sure I can say much here...
>
> The "close" trick is mostly, if not only, relevant for "pipe" mode,
> where it prevents more than the first request from the client from
> being piped. It doesn't really do anything positive for "pass".
>
>
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
Yes, Im aware of that. But I did have some problem in an earlier version
of trunk (and especially 1.1.2), but with the latest it seems better.
I have seen alot of updates on trunk the latest days, what's the status
of it, is it stable for production use?
/ Duja
Poul-Henning Kamp skrev:
> In message <[EMAIL PROTECTED]>, Erik Torlen writes:
>
>
>> My vcl has this code when POST are received:
>>
>>if(req.request != "GET" && req.request != "HEAD") {
>>set req.http.Connection = "close";
>>pass;
>>}
>>
>> This code usually works with FF and IE but NOT with Opera.
>>
>> If I remove "set req.http.Connection = "close";"
>>
>> the login process works with no problem.
>>
>> I have had problems with POSTs before, thats why I've been using
>> Connection = "close" on POSTs.
>>
>
> I'm not sure I can say much here...
>
> The "close" trick is mostly, if not only, relevant for "pipe" mode,
> where it prevents more than the first request from the client from
> being piped. It doesn't really do anything positive for "pass".
>
>
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Strange Opera error in POST
Ok, I have gathered some more info about the problem.
What I have is a form login that has 3 input fields, username, password
and security code (from captcha).
When opera is making the POST it receives a 200 OK and NOT a 302 Moved
Temp. as expected.
This is the request that Opera is making:
13 RxRequestc POST
13 RxURLc /takelogin.php
13 RxProtocol c HTTP/1.1
13 RxHeader c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
13 RxHeader c Host: mydomain.com:8080
13 RxHeader c Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1
13 RxHeader c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
13 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
13 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
13 RxHeader c Referer: http://mydomain.com:8080/login.php
13 RxHeader c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
13 RxHeader c Cookie2: $Version=1
13 RxHeader c Connection: Keep-Alive, TE
13 RxHeader c TE: deflate, gzip, chunked, identity, trailers
13 RxHeader c Content-Length: 63
13 RxHeader c Content-Type: application/x-www-form-urlencoded
My vcl has this code when POST are received:
if(req.request != "GET" && req.request != "HEAD") {
set req.http.Connection = "close";
pass;
}
This code usually works with FF and IE but NOT with Opera.
If I remove "set req.http.Connection = "close";"
the login process works with no problem.
I have had problems with POSTs before, thats why I've been using
Connection = "close" on POSTs.
Here is the whole error log:
0 CLI - Rd ping
0 CLI - Wr 0 200 PONG 1213029670
13 SessionClose - timeout
13 StatSess - 82.182.xx.xx 1306 0 1 2 0 0 2 744 6750
0 CLI - Rd ping
0 CLI - Wr 0 200 PONG 1213029673
13 SessionOpen c 82.182.xx.xx 1307 0.0.0.0:8080
13 ReqStart c 82.182.xx.xx 1307 803913450
13 RxRequestc POST
13 RxURLc /takelogin.php
13 RxProtocol c HTTP/1.1
13 RxHeader c User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
13 RxHeader c Host: mydomain.com:8080
13 RxHeader c Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1
13 RxHeader c Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
13 RxHeader c Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
13 RxHeader c Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
13 RxHeader c Referer: http://mydomain.com:8080/login.php
13 RxHeader c Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
13 RxHeader c Cookie2: $Version=1
13 RxHeader c Connection: Keep-Alive, TE
13 RxHeader c TE: deflate, gzip, chunked, identity, trailers
13 RxHeader c Content-Length: 63
13 RxHeader c Content-Type: application/x-www-form-urlencoded
13 VCL_call c recv
13 VCL_return c pass
13 VCL_call c pass
13 VCL_return c pass
14 TxRequest- POST
14 TxURL- /takelogin.php
14 TxProtocol - HTTP/1.1
14 TxHeader - User-Agent: Opera/9.27 (Windows NT 5.1; U; sv)
14 TxHeader - Host: mydomain.com:8080
14 TxHeader - Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg, image/gif,
image/x-xbitmap, */*;q=0.1
14 TxHeader - Accept-Language: sv-SE,sv;q=0.9,en;q=0.8
14 TxHeader - Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
14 TxHeader - Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
14 TxHeader - Referer: http://mydomain.com:8080/login.php
14 TxHeader - Cookie: PHPSESSID=f3a60f178adede632c761dca745054cf
14 TxHeader - Cookie2: $Version=1
14 TxHeader - Content-Type: application/x-www-form-urlencoded
14 TxHeader - X-Varnish: 803913450
14 TxHeader - X-Forwarded-For: 82.182.xx.xx
14 RxProtocol - HTTP/1.1
14 RxStatus - 200
14 RxResponse - OK
14 RxHeader - Date: Mon, 09 Jun 2008 16:41:14 GMT
14 RxHeader - Server: Apache
14 RxHeader - X-Powered-By: PHP/5.2.0-8+etch10
14 RxHeader - Content-Length: 23
14 RxHeader - Content-Type: text/html; charset=UTF-8
13 ObjProtocol c HTTP/1.1
13 ObjStatusc 200
13 ObjResponse c OK
13 ObjHeaderc Date: Mon, 09 Jun 2008 16:41:14 GMT
13 ObjHeaderc Server: Apache
13 ObjHeaderc X-Powered-By: PHP/5.2.0-8+etch10
13 ObjHeaderc Content-Type: text/html; charset=UTF-8
14 BackendReuse - mydomain
13 TTL c 803913450 RFC 120 1213029674 1213029674 0 0 0
13 VCL_call c fetch
13 VCL_return c pass
13 Length c 23
13 VCL_call c deliver
13 VCL_return c deliver
13 TxProtocol c HTTP/1.1
13 TxStatus c 200
13 TxResponse c OK
13 TxHeader c Se
Re: Directors user sessions
But the loadbalancing is already implenteed. I dont see why it shouldn't be used as loadbalancer if the functionality exists? I don't want to use one place for all sessions, like a file share or something in that direction. Im thinking about creating a Header that is called X-Backend: (a|b|c|d). This could be used to check what backend the user should use. Its really not a nice way to do it but its a way of doing it. Is there any idea that I could create a ticket for a feature like this? / Erik Cherife Li skrev: > On 2008-3-28 19:05, [EMAIL PROTECTED] wrote: >> Hi, >> >> I got a question regarding the Directors in varnish vcl. If user A is >> logging in to http://mywebsite.com and the website is using varnish >> (with directors) in front of 4 backend servers. The 4 backend servers >> is identical. >> >> User A is logging in and hits server 1. He then goes to his profile >> and hits server 2. The server 2 doesn't know that user A is logged >> and redirect him to some "Not logged in"-page. >> >> Is there any way for varnish to lookup which server that user A >> should be directed to? Some kind of Sticky Session function? >> > IMHO, Varnish is for caching, rather than for redirecting. > Maybe you could consider HAProxy, or pound, or IPVS, or > similar implementation. > Besides, I know that sessions can be shared. > >> / Erik >> >> ___ >> varnish-misc mailing list >> varnish-misc@projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnishlogging
Well C then :P Dag-Erling Smørgrav skrev: > Erik <[EMAIL PROTECTED]> writes: > >> Ah ok, I see :( Unfortunately i'm not a c++ guru so I can just cross >> my fingers and hope that some handy guy writes a patch. >> > > Actually, there isn't a single line of C++ code in Varnish. You must > be thinking of Squid... > > DES > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Deliver ReqEnd in http header
But we could take those timestamps that we would be able to compose before the transmission of headers :) This would be cool to have. Is it alot of code to implent? Can I as a "almost-a-newbie" go into the code? :P / Erik Poul-Henning Kamp skrev: > In message <[EMAIL PROTECTED]>, Erik writes: > >> I suspect that this cant be done right now but Ill ask anyway. >> >> In varnishlog you have the reqend field with some interesting times. My >> question is if I could include these times in one or more http headerfields >> when varnish delivers the response (vcl_deliver). >> >> Varnishlog often gets very big and in my opinion it would be easier to use, >> for ex. LiveHttp Header in firefox or something similiar, to see the step >> that took time. >> >> ReqEnd Example: >> 2039158367 1158180241.00123 1158180241.54881 0.005646787 0.15924 >> 0.38834 >> XIDRequest timestampComplete timestamp Idle time proc.time >> xmit time >> > > Well, obviously you cannot have timestamps that are taken after we > compose the headers for transmission, but otherwise it wouldn't be > impossible. > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Using varnish
Do you just want to know a swedish newspaper that's using varnish? If so, Aftonbladet and SvD is both using varnish. / Erik Anders Vännman skrev: > Hi, > > We are in the process of evaluating Varnish as an alternative for Squid > for our sites. We have got an internal varnish up and running and it seems > just great. Of course I have many questions, is there anyone on a swedish > newspaper using varnish? > > // Anders Vännman > > > ___ > varnish-misc mailing list > varnish-misc@projects.linpro.no > http://projects.linpro.no/mailman/listinfo/varnish-misc > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: A few users see a blank page
Hi,
I have seen the same behaviour on my Apache2 server with php5 installed.
Many users got blank pages
when navigating around the website. I couldn't figure out what the
problem was so I simply removed varnish
and the problem disappeared.
Another problem I had was that php's X-FORWARDED-FOR was empty at random
times. I looked in the
apache2 log and saw some empty fields their too. Couldn't find a
solution for it :(
/ Erik
Marco Molinari skrev:
> I can now reproduce it and I found a lot of info.
>
> I wrote a simple script that keeps on reloading itself, adding some
> chars each time; I disabled compression both in Apache and in PHP and
> I connect my browser through a 2.6 Squid proxy; and now I can't see
> PHP pages larger than 8000 bytes. I also found an interesting
> connection with cookies.
>
> Here are the log lines for Varnish requesting two pages to Apache:
>
> Apache:
> 127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:26 +0100] "GET
> /test_varnish2.php?n=10&t=1202822659 HTTP/1.0" 200 8000 "-"
> "{MY-USER-AGENT}"
> 127.0.0.1, 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
> /test_varnish2.php?n=11&t=1202822659 HTTP/1.0" 200 8001 "-"
> "{MY-USER-AGENT}"
>
> Varnish:
> 10.0.2.2 - - [12/Feb/2008:14:24:26 +0100] "GET
> http://dev.{MY-SITE}:2280/test_varnish2.php?n=10&t=1202822659
> HTTP/1.0" 200 8000 "-" "{MY-USER-AGENT}"
> 10.0.2.2 - - [12/Feb/2008:14:24:29 +0100] "GET
> http://dev.{MY-SITE}:2280/test_varnish2.php?n=11&t=1202822659
> HTTP/1.0" 200 0 "-" "{MY-USER-AGENT}"
>
>
> As you can see Varnish logs a 0 size for the 8001 bytes request.
>
>
> Here is the extended log (as per varnishlog) for those requests (sorry
> for the length):
>
>15 ReqStart c 10.0.2.2 43859 67671826
>15 RxRequestc GET
>15 RxURLc /test_varnish2.php?n=10&t=1202822659
>15 RxProtocol c HTTP/1.0
>15 RxHeader c Host: dev.{MY-SITE}:2280
>15 RxHeader c User-Agent: {MY-USER-AGENT}
>15 RxHeader c Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>15 RxHeader c Accept-Language: en-us,en;q=0.5
>15 RxHeader c Accept-Encoding: gzip,deflate
>15 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>15 RxHeader c Cookie:
> __utma=.xx.xx.xx.xx.23;
> __utmz=.xx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
> __utmz=.xx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
>15 RxHeader c Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>15 RxHeader c X-Forwarded-For: 127.0.0.1
>15 RxHeader c Cache-Control: max-age=259200
>15 RxHeader c Connection: keep-alive
>15 VCL_call c recv
>15 VCL_return c pass
>15 VCL_call c pass
>15 VCL_return c pass
>18 BackendOpen b default 127.0.0.1 32988 127.0.0.1 8080
>18 BackendXID b 67671826
>15 Backend c 18 default
>18 TxRequestb GET
>18 TxURLb /test_varnish2.php?n=10&t=1202822659
>18 TxProtocol b HTTP/1.0
>18 TxHeader b Host: dev.{MY-SITE}:2280
>18 TxHeader b User-Agent: {MY-USER-AGENT}
>18 TxHeader b Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
>18 TxHeader b Accept-Language: en-us,en;q=0.5
>18 TxHeader b Accept-Encoding: gzip,deflate
>18 TxHeader b Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>18 TxHeader b Cookie:
> __utma=.xx.xx.xx.xx.23;
> __utmz=.xx.21.5.utmcsr=mail.google.com|utmccn=(referral)|utmcmd=referral|utmcct=%2Fmail%2F;
> __utmz=xx.xx.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(non
>18 TxHeader b Via: 1.1 virtual:3129 (squid/2.6.STABLE14)
>18 TxHeader b X-Forwarded-For: 127.0.0.1
>18 TxHeader b X-Varnish: 67671826
>18 TxHeader b X-Forwarded-for: 10.0.2.2
>18 RxProtocol b HTTP/1.1
>18 RxStatus b 200
>18 RxResponse b OK
>18 RxHeader b Date: Tue, 12 Feb 2008 13:24:26 GMT
>18 RxHeader b Server: Apache/2.0.52 (CentOS)
>18 RxHeader b X-Powered-By: PHP/4.3.9
>18 RxHeader b Content-Length: 8000
>18 RxHeader b Connection: close
>18 RxHeader b Content-Type: text/html; charset=UTF-8
>15 ObjProtocol c HTTP/1.1
>15 ObjStatusc 200
>15 ObjResponse c OK
>15 ObjHeaderc Date: Tue, 12 Feb 2008 13:24:26 GMT
>15 ObjHeaderc Server: Apache/2.0.52 (CentOS)
>15 ObjHeaderc X-Powered-By: PHP/4.3.9
>15 ObjHeaderc Content-Type: text/html; charset=UTF-8
>18 BackendClose b default
>15 TTL c 67671826 RFC 120 1202822666 1202822666 0 0 0
>15 VCL_call c fetch
>15 VCL_return c insert
>15 Length c 8000
>15 VCL_call c deliver
>15 VCL_return c deliver
>15 TxProtocol c HTTP/1.1
>15 Tx
IP & X-Forward-for
Hi, Im experiencing a strange problem when using varnish in front of apache2. I m running a php website where I log the client IP to the usertable in the database. I first check the Client IP to see if it is a valid IP, if not, I check the "x-forward-for" for a valid ip (I check for multiple IPs in x-forward-for). If neither client ip or x-forward-for contained a valid ip, it returns the client ip (in most cases 127.0.0.1). The strange thing is that I get alot of IPs that comes from 127.0.0.1 which means that x-forward-for is NOT set. This is the log from varnish: 81.224.31.xxx - - [31/Jan/2008:20:52:09 +0100] "GET 127.0.0.1 - - [31/Jan/2008:20:52:09 +0100] "(null) (null) (null)" (null) (null) "-" "-" backendserver - - [31/Jan/2008:19:52:09 +0100] "GET 81.227.81.xxx - - [31/Jan/2008:20:52:09 +0100] "GET 127.0.0.1 - - [31/Jan/2008:19:52:11 +0100] "GET 217.197.62.xxx - - [31/Jan/2008:20:52:11 +0100] "GET 127.0.0.1 - - [31/Jan/2008:19:52:11 +0100] "GET 85.229.6.xxx - - [31/Jan/2008:20:52:11 +0100] "GET 127.0.0.1 - - [31/Jan/2008:19:52:11 +0100] "GET 85.229.6.xxx - - [31/Jan/2008:20:52:11 +0100] "GET 127.0.0.1 - - [31/Jan/2008:19:52:12 +0100] "GET 83.233.193.xxx - - [31/Jan/2008:20:52:12 +0100] "GET Why does it have so many connections from 127.0.0.1 and why is the date an hour late? It also got a "connection" from "backendserver" which is the name of my backendserver in the vcl config. The logfile from apache2 shows me this whit the same connections: 81.224.31.xxx - - [31/Jan/2008:20:52:08 +0100] "GET 81.227.81.xxx - - [31/Jan/2008:20:52:09 +0100] "GET 217.197.62.xxx - - [31/Jan/2008:20:52:11 +0100] "GET 85.229.6.xxx - - [31/Jan/2008:20:52:11 +0100] "GET 85.229.6.xxx - - [31/Jan/2008:20:52:11 +0100] "GET 83.233.193.xxx - - [31/Jan/2008:20:52:12 +0100] "GET No 127.0.0.1 connections in this logfile. Is the 127.0.0.1 connections from apache2 when varnish fetches the object from back their? Im not sure if these logentries say enough about my problem. I will try to find some more entries that could show some more about the issue. I appreciate all help I can get on this one. / Erik ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnishtop hangs
Its not near an overload when it hangs. I do some requests against it and *poff*, varnishtop hangs and I can't even close it with ctrl+c. If you have any requests on some more info am more then glad to help. Cheers Erik Poul-Henning Kamp skrev: > In message <[EMAIL PROTECTED]>, Erik writes: > > >> I'm making alot of requests and the varnishtop shows the correct= >> stats but after a while with some certain tags (e.g TxURL) it= >> just hangs. I cannot make e Ctrl+C or anything, simply dead. >> > > Hmm, I wonder if your shmlog segment is overrun too fast. In that > case all the shmlog tailing programs can get confused. > > How much traffic does your server take ? > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnishstat vs. telnet stats
Ok. Thanks for all your help mate ;) Erik - Original Message - From: "Peter Oomen" <[EMAIL PROTECTED]> To: "Erik" <[EMAIL PROTECTED]> Sent: Thursday, September 20, 2007 4:34 PM Subject: Re: varnishstat vs. telnet stats > yes, cache hits mean hits from the cache.. > > > On 9/20/07, Erik <[EMAIL PROTECTED]> wrote: >> Thank you very much. It is up n running ;) >> >> A few question about the cache tho. >> >> The stats are saying that it has fetched like 40 items and have had about >> 650 cache hits. Is this enough to tell if the cache is running, I mean, >> "cache hits"? that must mean that its serving from the cache? >> >> // Erik >> >> ___ >> varnish-misc mailing list >> varnish-misc@projects.linpro.no >> http://projects.linpro.no/mailman/listinfo/varnish-misc >> > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.487 / Virus Database: 269.13.25/1018 - Release Date: > 2007-09-19 15:59 > > ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
varnishstat vs. telnet stats
Hi!
I still have problems with varnish and its cache. Its configured to
listen on port 80 which it does fine. My webserver is set to listen on
port 8080 and the backend on varnish is configured to:
backend default {
set backend.host = "127.0.0.1";
set backend.port = "8080";
}
Now if I make a request of a picture to port 80, I see in apache2 logs
that it passes the picture fine. But if I check varnishstat, its still
empty with zeros almost everywhere. The only values that are set is:
/1 N struct sess_mem
2 N struct smf
2 N large free smf
47 SHM records
47 SHM writes
1073741824 bytes free/
This is after a *single *request to a picture has been made.
If I then close down varnishstat and telnets in to port 6082 and type
/stats/ I get totally different data compared with varnishstat.
Here is exactly what it prints out in the telnet console (when using the
/stats/ command):
/ 1 Client connections accepted
1 Client requests received
0 Cache hits
0 Cache hits for pass
0 Cache misses
1 Backend connections success
0 Backend connections failures
0 Backend connections reuses
1 Backend connections recycles
0 Backend connections unused
1 N struct srcaddr
1 N active struct srcaddr
2 N struct sess_mem
2 N struct sess
0 N struct object
1 N struct objecthead
2 N struct smf
0 N small free smf
2 N large free smf
1 N struct vbe_conn
1 N worker threads
1 N worker threads created
0 N worker threads not created
0 N worker threads limited
0 N queued work requests
1 N overflowed work requests
0 N dropped work requests
0 N expired objects
0 N objects on deathrow
0 HTTP header overflows
0 Objects sent with sendfile
1 Objects sent with write
1 Total Sessions
1 Total Requests
0 Total pipe
0 Total pass
1 Total fetch
295 Total header bytes
90 Total body bytes
0 Session Closed
0 Session Pipeline
0 Session Read Ahead
1 Session herd
98 SHM records
27 SHM writes
0 SHM MTX contention
1 allocator requests
0 outstanding allocations
0 bytes allocated
1073741824 bytes free
1 Backend requests made
/Everything looking good to me!
But why doesn't varnishstat display the same data as telnet command
"stats" did?
Regards
Erik
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Problems with the cache
Im trying to get varnish running smoothly on my server with apache on it. Unforunately Im having some problems to get the caching thing working. I have set varnishd to use default.vcl on a Debian 4.0 etch OS. it starts up without any problem but doesn't cache anything. Also the varnishlog doesn't seem to log anything. I'm having it running as a daemon, it's writing the log to /var/log/varnish/varnish.log but that file is empty. Varnishstat doesn't update itself when using vcl, only when using "-b localhost:8080" as a parameter to varnishd. Im using all default config files, except that I have edited the backend in default.vcl and in /etc/default/varnish . However, if I use the "-b" parameter woith varnishd, I could get varnishd to work but nothing is cached. Alot of objects are fetched but nothing is parsed out to the client. It just fetches it from the backend server over and over again. As you see, i have alot of problems. It became a big mess after some tweaking and now am stuck with alooot of problems :( / Erik ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
