3 ms·

Strange, there is a great web server woo [1] and great parallel futures library for async lparalel [2] that we use with great results. [1] https://github.com/f

Strange, there is a great web server woo [1] and great parallel futures library for async lparalel [2] that we use with great results. [1] https://github.com/fukamachi/woo https://github.com/fukamachi/woo (4x faster than nodejs) [2] https://lparallel.org/ https://lparallel.org/

orthecreedence 5y ago
As far as I know, Woo has no async foundation, meaning it can serve static content very quickly, but cannot really make use of other async libs without farming out to another event loop/thread pool. In other words, its main asset, speed, is bottlenecked as soon as you need to do things. Wookie, the original server for Turtl, was built on top of cl-async which gave it access to all the other async libs built for CL. Woo wouldn't have been particularly useful for us.
- gibsonf1 5y ago
  That would be a misunderstanding of Woo. You can have as many workers running as you like with woo, but for async activities processing requests, the issue isn't woo, that is the server doing things with the request once received, and for that you run lparallel with great results. You can simply send every request off in a future, and it will go off and do it on another thread.
  - orthecreedence 5y ago
    So you're not running anything truly async, you're just using threading at a lower level? I don't get what Woo really provides to the async ecosystem in CL.
    - gibsonf1 5y ago
      Woo is a superfast web server. It handles receiving 4x the number of requests that node js can. Once the server gets the request, you can control how the response works with futures etc. Our front end webapp is using Vue cli, which clearly is javascript. I assumed the discussion here was about the server, not the front end webapp on the browser.
      - orthecreedence 5y ago
        The discussion was about an app server written in CL (Wookie) that supports a backend app written in CL, all in async (via cl-async). It seems to me you're using Woo as an Nginx replacement, not as a CL app server, which makes total sense to me after you described the model you're using.
      - wyager 5y ago
        I wouldn’t describe 4x nodejs as “super fast”. Nodejs is one of the slowest popular backends, or at least it was when I did a comparison a few years ago.
        gibsonf1 5y ago
        In the last benchmarks, woo beat all including the Go webserver: Scroll down just a bit to see the comparisons here: https://github.com/fukamachi/woo https://github.com/fukamachi/woo
        wyager 5y ago
        Nice. Node has gotten a lot faster than when I last looked apparently. In fact, I’m a bit suspicious of the benchmark they’re using.
    - Jtsummers 5y ago
      What is your distinction between "async" and "using threading at a lower level"?
      - orthecreedence 5y ago
        In this case, an async (via cl-async) application served by an async app server (http://wookie.lyonbros.com/ http://wookie.lyonbros.com/), so async all the way down using evented I/O vs an async server (Woo) that farms out all requests to a synchronous thread pool. I've been asked multiple times why I "didn't just use Woo" by people who don't understand that Turtl's server was async and Woo doesn't support async.
        gibsonf1 5y ago
        I guess the question is what does that have to do with it? Why not just work asynchronusly with requests that hit the server with a library like lparallel with their futures? Isn't it about the response to the request?
        orthecreedence 5y ago
        > Isn't it about the response to the request? High level, yes. Mid/low-level, it really depends on what you're doing. If you're serving static files, sure, use Nginx/Woo. If you're running an evented CL application that deals mostly with network i/o, threading is going to be a tank when you need a hummingbird. I built cl-async/wookie as parallels for nodejs/express in common lisp.
        math-dev 5y ago
        Oh, are you the developer mentioned in the main post? If so, I agree a lot with what you said!
        orthecreedence 5y ago
        I am! Turtl is my baby.

orthecreedence 5y ago

As far as I know, Woo has no async foundation, meaning it can serve static content very quickly, but cannot really make use of other async libs without farming out to another event loop/thread pool. In other words, its main asset, speed, is bottlenecked as soon as you need to do things. Wookie, the original server for Turtl, was built on top of cl-async which gave it access to all the other async libs built for CL. Woo wouldn't have been particularly useful for us.

gibsonf1 5y ago
That would be a misunderstanding of Woo. You can have as many workers running as you like with woo, but for async activities processing requests, the issue isn't woo, that is the server doing things with the request once received, and for that you run lparallel with great results. You can simply send every request off in a future, and it will go off and do it on another thread.
- orthecreedence 5y ago
  So you're not running anything truly async, you're just using threading at a lower level? I don't get what Woo really provides to the async ecosystem in CL.
  - gibsonf1 5y ago
    Woo is a superfast web server. It handles receiving 4x the number of requests that node js can. Once the server gets the request, you can control how the response works with futures etc. Our front end webapp is using Vue cli, which clearly is javascript. I assumed the discussion here was about the server, not the front end webapp on the browser.
    - orthecreedence 5y ago
      The discussion was about an app server written in CL (Wookie) that supports a backend app written in CL, all in async (via cl-async). It seems to me you're using Woo as an Nginx replacement, not as a CL app server, which makes total sense to me after you described the model you're using.
    - wyager 5y ago
      I wouldn’t describe 4x nodejs as “super fast”. Nodejs is one of the slowest popular backends, or at least it was when I did a comparison a few years ago.
      - gibsonf1 5y ago
        In the last benchmarks, woo beat all including the Go webserver: Scroll down just a bit to see the comparisons here: https://github.com/fukamachi/woo https://github.com/fukamachi/woo
        wyager 5y ago
        Nice. Node has gotten a lot faster than when I last looked apparently. In fact, I’m a bit suspicious of the benchmark they’re using.
  - Jtsummers 5y ago
    What is your distinction between "async" and "using threading at a lower level"?
    - orthecreedence 5y ago
      In this case, an async (via cl-async) application served by an async app server (http://wookie.lyonbros.com/ http://wookie.lyonbros.com/), so async all the way down using evented I/O vs an async server (Woo) that farms out all requests to a synchronous thread pool. I've been asked multiple times why I "didn't just use Woo" by people who don't understand that Turtl's server was async and Woo doesn't support async.
      - gibsonf1 5y ago
        I guess the question is what does that have to do with it? Why not just work asynchronusly with requests that hit the server with a library like lparallel with their futures? Isn't it about the response to the request?
        orthecreedence 5y ago
        > Isn't it about the response to the request? High level, yes. Mid/low-level, it really depends on what you're doing. If you're serving static files, sure, use Nginx/Woo. If you're running an evented CL application that deals mostly with network i/o, threading is going to be a tank when you need a hummingbird. I built cl-async/wookie as parallels for nodejs/express in common lisp.
        math-dev 5y ago
        Oh, are you the developer mentioned in the main post? If so, I agree a lot with what you said!
        orthecreedence 5y ago
        I am! Turtl is my baby.