Log in

No account? Create an account
Yay I have code in varnish :)… - Artur Bergman [entries|archive|friends|userinfo]
Artur Bergman

[ website | O'Reilly Radar ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Jun. 23rd, 2008|12:35 am]
Artur Bergman


I have code in varnish :)


[User Picture]From: burr86
2008-06-23 08:07 am (UTC)
Nice! :D
(Reply) (Thread)
[User Picture]From: netik
2008-06-23 08:36 am (UTC)
Cool. I've been using varnish on quite a few sites that I work on since you showed it to me.

I guess I'll see you at Velocity tomorrow. ;)

(Reply) (Thread)
From: (Anonymous)
2008-06-26 01:08 pm (UTC)

some reverse-proxy notes

Hey hey!

1. Great conference, and great keynote, you're spreading some good gospel out there.
2. Saw the squid/varnish talk, and yep, we still use squid at Flickr, mostly because performance doesn't suck for our use case (disk-intensive, constantly full/evicting cache) and reliability.

Some thoughts:

- Median service times reported for any of the metrics in squid, hits/misses/nearhits/etc *include* the time it took for the client to pull down the last bit of the response, not *just* how long it took for squid to find the object and start serving it. So that means that those service timings are skewed, depending on how many "far" (i.e. across an ocean, on slow links) clients you have. Whereas, IIRC, stats from varnish actually measure how long varnish had the request. So it's not 100% apples-apples, to compare graphs.

As you might guess, this is because squid still enjoys a massive following of users using it as a forward-proxy, and those times are important to them, but not for us accelerator users. There is a patch to make those timings in squid more relevant, I've got some more description here:


- The performance data you had in your slides for varnish and squid: were they done with full/churning caches, and using disk? Or serving a working set of objects just out of RAM?

(Reply) (Thread)
[User Picture]From: crucially
2008-06-26 05:42 pm (UTC)

Re: some reverse-proxy notes

The absolute numbers where just serving one object out of memory, with the times reported by the clients.

I suspect we have much smaller objects with much shorter ttl than you guys. :)

The squid numbers are actually from the second layer squids. We use a first layer squid that does CARP and a second layer of squids. So the graphs in the presentation are all from the internal squids. We parse the access-log and make those graphs out of that. Most of our squid traffic is served from RAM, the disk churn is fairly small.

More performance on Varnish once it starts getting more reliable :) (I think Varnish can give you the stats both on starting to send and how long time it took to send, but not sure about that)

Thanks for coming to the conference, I had a blast.

(Reply) (Parent) (Thread)
From: (Anonymous)
2008-07-10 12:14 am (UTC)

Re: some reverse-proxy notes

Will you post your slides for the varnish talk? They don't seem to be on the Velocity site and I'd like to go over them in detail, it was an interesting talk.
(Reply) (Parent) (Thread)