Ic, <span class="Apple-style-span" style="border-collapse: collapse; white-space: pre-wrap; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; ">Poul-Henning</span> thank you!<div><br></div><div>
Hey guys,<br><div><br></div><div>Im still trying to get a handle how to debug these vcl rules best here..</div><div><br></div><div><a href="https://gist.github.com/ca5ef043fdfb89a5b143">https://gist.github.com/ca5ef043fdfb89a5b143</a></div>
<div><br></div><div>Ive got some simple tests set up, mainly based on <a href="http://overstimulate.com/articles/varnish-getting-started">http://overstimulate.com/articles/varnish-getting-started</a></div><div><br></div><div>
With app #1 caching happens fine, but with app #2 with the same very general vcl rules, I cant seem to get caching to work :(.</div><div><br></div><div>There's a few questions at the end of the gist:</div><div><div>1. Why isnt app #2 picking up the cache?  I think maybe the rails app returns a slighly </div>
<div>different header that could be causing a problem but I dont see anything different in the </div><div>varnishlog output :(.</div><div>2. Is there a way to check what is in the cache from the "telnet localhost 6082" or anything </div>
<div>else, if I have the key, "/articles;feed?tag_id=16" in this case.  Maybe thats whats going on, </div><div>the data isnt being written into the cache...</div><div>3. I also tried adding some C code (commented out) to maybe puts some output out or writing to </div>
<div>a file (maybe through a system call could work too) to see which part of the vcl chain Im </div><div>hitting.  Whats a good way of doing that?  This would be great to know how to do so I can </div><div>check the vcl rules. </div>
<div> </div><div><br></div><div>Thanks again and any responses are appreciated.</div><div>Tung</div></div><div><br><div><br><div class="gmail_quote">On Sun, Mar 22, 2009 at 2:08 AM, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk">phk@phk.freebsd.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">In message <<a href="mailto:ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com">ca6364050903220201t1f50f65btd5b4904f5703f735@mail.gmail.com</a>>, Tung<br>

<div class="im">Nguyen writes:<br>
>Hey guys,<br>
><br>
>In the the varnishlog output<br>
><br>
><a href="https://gist.github.com/8b163cc29fbd5e3141f6" target="_blank">https://gist.github.com/8b163cc29fbd5e3141f6</a><br>
><br>
>Where can I find out more info on what the columns mean,<br>
>So what does the 7 vs 10 mean in the first column?<br>
>What does the b vs c mean in the second column?<br>
<br>
</div>The first column is a magic number for each transaction.<br>
<br>
This is what allows you collect all the messages that<br>
belong to the same transaction.<br>
<br>
For the time being, it is also the file descriptor number<br>
of the socket, but this is not guaranteed to always be the<br>
case.<br>
<br>
The 'b' means "backend transaction, and 'c' client side<br>
transaction.<br>
<div><div></div><div class="h5"><br>
> 7 VCL_return   c pass<br>
>10 BackendOpen  b default 127.0.0.1 57141 0.0.0.0 3000<br>
> 7 Backend      c 10 default default<br>
>10 TxRequest    b HEAD<br>
<br>
</div></div><font color="#888888">--<br>
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG         | TCP/IP since RFC 956<br>
FreeBSD committer       | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Tung Nguyen, Lead Developer<br>Bleacher Report, The Open Source Sports Network <br>(510) 928-0475<br>
</div></div></div>