Re: A talk on Lua: Our experience with LuaJIT in mid-load web-projects (in Russian)

[Tim Mensch <tim-lua-l@...>]

Thanks for the links.

I saw luvit before, but I am hoping to go with something a bit more battle-tested. They describe the project as "still under heavy development, but it's showing promise." This is really cool work, and it sounds awesome, but I don't have the resources to take a chance on it right now.

LuaNode (and the related Socket.IO project) is new to me, but again, it doesn't look like it's as mature as OpenResty/Nginx, which is my current go-to for serving Lua-driven pages. I really need, as much as possible, for the server part of the equation to be fire-and-forget, until it's time to think about scaling. Even on the readme for LuaNode-Socket.IO, it says "it is not ready for prime-time yet." If I had a full-time server developer, I might take a chance, but I have two clients AND a server architecture to put together.

I have to say that Zed Shaw did an awesome job on Mongrel2 and Tir, and it's tempting to go in that direction, but I'm also seeing benchmarks that show Mongrel2 falling down with 5000+ concurrent connections because it uses poll instead of epoll, and I'm hoping to have 30000+ concurrent connections per server (each connection may only get a message every 10-45 seconds, so this is well in line with the benchmarks I've done of Nginx+Lua). Running 8 or more instances of Mongrel2 behind haproxy (or Nginx) might be an option, though.

Thanks again, though.

Tim

On 5/26/2013 10:05 AM, Ignacio Burgueño wrote:

I would add 2.5 to your list. Just before turning to Node.js you could take a look at LuaNode [1] and LuaNode-Socket-IO [2].

LnSocket-io implements an outdated version of socket.io (0.7 I guess) and it does not support websockets (current draft, that is).

You could also take a look at luvit [3].

[1] https://github.com/ignacio/LuaNode

[2] https://github.com/ignacio/LuaNode-Socket.IO

[3] http://luvit.io/

On Sat, May 25, 2013 at 11:43 PM, Tim Mensch <tim-lua-l@bitgems.com> wrote:

On 5/24/2013 9:23 AM, Daurnimator wrote:

How is long polling a problem?

I was under the impression they were using OpenResty, though apparently they weren't, and they listed long polling as a "problem" on the slides, so I was wondering if they'd since found a solution.

I guess the only problem I'm aware of is that there isn't a nice prepackaged library that handles long polling ("Comet" [1] -- something like socket.io [2]) reliably across browsers. Ideally there would be a WebSocket code path as well. A bit of Googling finds a module for Nginx that supports websockets [3], but with no OpenResty support available.

So it looks like my current solution would be one of :

1) Stick with simple long polling in OpenResty and implement the handling myself entirely in _javascript_. I'd rather not, since even though long polling isn't exactly rocket science, it strikes me as something prone to browser-specific issues. Additionally, I'm led to believe the server load is higher with long polling than with WebSockets, and I know the latency isn't as good if two messages arrive in quick succession.

2) Switch to Mongrel2/Tir from OpenResty, though it's not clear to me that Tir support for WebSockets is first class yet. Documentation is nonexistent, as far as I can tell, and support for existing _javascript_ libraries is an unknown.

3) Switch to Node.js so I can use socket.io without having to reinvent the server or client side of that equation.

#s 1 and 2 keep me with Lua, which is important to me, but if it turns out that #3 gives me significantly better scalability on a single server (through the use of WebSockets), then I'll swallow my dislike of JS and use it. #3 sounds like the "it just works" solution, which is very attractive.

Tim


[1] http://en.wikipedia.org/wiki/Comet_%28programming%29

[2] http://socket.io/

[3] https://github.com/wandenberg/nginx-push-stream-module