Hacker News Reader

Comment by StavrosK | Hacker News Reader

Varnish is arguably more performant than varnish. I've had amazing success with both, and I don't think both are necessary together, but they're both screaming fast. I noticed one day that varnish had served 100,000 visitors per day from the cache due to a Google mistake only because I saw it in my analytics. The server load was at 0.05 all day.

I love varnish. Hard.

View on HN

Er, would you mind correcting your post to indicate which one is more performant?

Thanks.

What do you mean? I say they're both very, very fast, but I think Varnish might be a bit faster (or better written). In any case, it's a really close call, and you should use the right tool for the job, as they aren't both written for the same job.

I think he means that you should read the first sentence of your original post again.

Ah, I meant "than nginx". The weird thing is that I read it again after the comment. I can't edit it now, unfortunately...

It's clear from his post that he found varnish to be faster.

Unless you subscribe to the concept of case sensitivity, that is.

Varnish is ridiculously amazing. I use it directly in front of unicorn to host some ruby apps. The performance is just amazing compared to the load avg. No need for a 'proper' web server.

Thank God you came. I was thinking of doing this exact thing with a passthrough directive for socket.io. What's your experience with it? Any caveats? Do you serve static media in any special way? I usually just have Varnish cache them forever.

Any help would be great, thank you!

Varnish would need to support HTTP 1.1 proxying (specifically the "Upgrade" header) in order to run socket.io WebSockets. haproxy might be more what you're looking for in regards to reverse proxies.

Doesn't it work if you just pass that url through?

I don't exactly deal with any high amount of visitors (current record being like 300 hits per month).

But for using it directly with a application server I just use it as a backend and handle Cache-Control headers directly in the app. As for static files I haven't really handled them but caching them forever seems like a good enough option. It seems to work great and I haven't discovered any problems yet and with grace-time in varnish you could even survive a backend dying if it's serving out fairly static content.

Actually the reason I'm not caching more is due to a bug in Rack. https://github.com/rack/rack/pull/157 Rack seems to not handle session cookies correctly, they are always there even when there is no session set. Varnish does not cache things that sets cookies. (e.g pages where you are logged in, like a admin panel).

This makes things served through my sinatra application/unicorn have session cookies, even if it's something like a css file. I'm specifically stripping them out at this point but it shouldn't be needed. I don't know enough about Rack yet to fix the bug myself and way too busy with exams anyway.

I see, thanks. Since nginx would proxy gunicorn anyway, I don't think it would be any different, though, would it... It sounds like a good solution, I'll go with that, thanks.

I don't know how websockets works with varnish though, but you could run varnish on port 80, nginx on 81 and have the websockets hit :81 to get proxied through nginx I guess, you would still get good caching of normal content through varnish! :)

That's a good idea, but if you can run WebSockets on a different port you can just have it go straight through :p

For some reason I can't respond to your other post, but yeah that makes sense too. Let me know what you end up doing, would be nice to discuss it more :-) I'm on irc a few places (freenode and efnet mostly) if you want.

If you can't respond to a post, just click "link" and it'll let you. As for the final setup, it I'll definitely write it up and post it here :)

Reply on news.ycombinator.com