[deleted]
WebSockets with Varnish and Nginx
11–20 of 20 posts
Re: WebSockets with Varnish and Nginx
#12Varnish allocates one thread per connection. Even if it supports websockets, it's not going to scale well across tens of thousands of simultaneous persistent connections. The context switch and memory overhead will be considerable. For now, Java-based servers (using netty) and node.js may be a better idea.
Not only that, but letting all traffic through Varnish is not a good utilization of its resources at all.
The question is, how could I set up multiple servers on the same port? Or what else do I need to put in front of Varnish to route WebSocket connections elsewhere?
I'm starting to think this use case is not easy to solve under one IP address.
Re: WebSockets with Varnish and Nginx
#13Varnish allocates one thread per connection. Even if it supports websockets, it's not going to scale well across tens of thousands of simultaneous persistent connections. The context switch and memory overhead will be considerable. For now, Java-based servers (using netty) and node.js may be a better idea.
I don't see why Varnish would create one thread per allocation. They are using epoll/kqueue on an accept thread to handle new incoming requests. The requests themselves are handled by worker thread pool.
Re: WebSockets with Varnish and Nginx
#14Varnish allocates one thread per connection. Even if it supports websockets, it's not going to scale well across tens of thousands of simultaneous persistent connections. The context switch and memory overhead will be considerable. For now, Java-based servers (using netty) and node.js may be a better idea.
To clarify (and answer @sureshv), Varnish allocates one worker-thread per session (active connection), but those threads are pooled by the managed thread pool @sureshv referred to. It's recommended to leave the thread_pool value at 2 and scale the thread_pool_min and _max values to suit your traffic.
As for the handling of the websockets, setting the pipe_timeout variable in the vcl file would release any persistent, yet silent, connections.
Re: WebSockets with Varnish and Nginx
#15Varnish allocates one thread per connection. Even if it supports websockets, it's not going to scale well across tens of thousands of simultaneous persistent connections. The context switch and memory overhead will be considerable. For now, Java-based servers (using netty) and node.js may be a better idea.
Not only that, but letting all traffic through Varnish is not a good utilization of its resources at all. The question is, how could I set up multiple servers on the same port? Or what else do I need to put in front of Varnish to route WebSocket connections elsewhere? I'm starting to think this use case is not easy to solve under one IP address.
Node Http Proxy: https://github.com/nodejitsu/node-http-proxy
No need for Varnish for proxying your websockets.
Re: WebSockets with Varnish and Nginx
#16Varnish allocates one thread per connection. Even if it supports websockets, it's not going to scale well across tens of thousands of simultaneous persistent connections. The context switch and memory overhead will be considerable. For now, Java-based servers (using netty) and node.js may be a better idea.
Not only that, but letting all traffic through Varnish is not a good utilization of its resources at all. The question is, how could I set up multiple servers on the same port? Or what else do I need to put in front of Varnish to route WebSocket connections elsewhere? I'm starting to think this use case is not easy to solve under one IP address.
Varnish sits in front on port 80 then proxies based on the VCL configuration, you can parse the HTTP headers/path to pass through appropriately.
https://www.varnish-cache.org/docs/trunk/tutorial/websockets...
Re: WebSockets with Varnish and Nginx
#17Varnish allocates one thread per connection. Even if it supports websockets, it's not going to scale well across tens of thousands of simultaneous persistent connections. The context switch and memory overhead will be considerable. For now, Java-based servers (using netty) and node.js may be a better idea.
Not only that, but letting all traffic through Varnish is not a good utilization of its resources at all. The question is, how could I set up multiple servers on the same port? Or what else do I need to put in front of Varnish to route WebSocket connections elsewhere? I'm starting to think this use case is not easy to solve under one IP address.
One of the things I've debated back and forth personally is if it's better to put nginx in front of varnish or vice versa.
There are reasons to do either but I've not come up with a definitive reason to go one way or another.
Re: WebSockets with Varnish and Nginx
#18Earlier quoted context omitted.
Not only that, but letting all traffic through Varnish is not a good utilization of its resources at all. The question is, how could I set up multiple servers on the same port? Or what else do I need to put in front of Varnish to route WebSocket connections elsewhere? I'm starting to think this use case is not easy to solve under one IP address.
Node Http Proxy: https://github.com/nodejitsu/node-http-proxy No need for Varnish for proxying your websockets.
Thanks for the link. This looks like an ideal tool to fulfil the same role as Varnish (in the stack I'd outlined) without losing SSL support or allocating one thread per active connection.
Re: WebSockets with Varnish and Nginx
#19this does not address the problem with ssl-traffic. varnish will delegate it to a reverse proxy _in front_ of itself. i usually deploy nginx. looks like a catch-22 for websockets ;).
So how do you handle the case of SSL in front of web traffic and web socket traffic? I need to handle both SSL and non-SSL. Right now I just use another port, but my users behind a firewall can't access the websocket.
usually a different websocket port. not what you wanted to hear i guess :|.
Re: WebSockets with Varnish and Nginx
#20Earlier quoted context omitted.
So how do you handle the case of SSL in front of web traffic and web socket traffic? I need to handle both SSL and non-SSL. Right now I just use another port, but my users behind a firewall can't access the websocket.
usually a different websocket port. not what you wanted to hear i guess :|.
node-http-proxy is one option, but I'm just going to wait for nginx's native support.