yeah I'm still scratching my head around this simple problem, maybe I should just stick with leiningen for now, only use pure clojurescript in my project with no scss is an option for now

gotta have a solution for a week or so, since I'm gonna need to develop the whole application with yada, datomic and hot-reload and I don't know if figwheel can be hosted by my server instead a ring one

Just wanted to say thanks for Yada. I had a moment where I wanted to change the URL for a route and I changed the route table and all my code referencing the route updated because I was using Yada/Bidi. Worth the price of admission for that alone!

@sickill yada depends quite a lot on aleph, due to the async features particularly I believe. I don't think that officially it will work without aleph. You may have some success for non async though, but I'm uncertain. The plan has always been to accept ports to other backend if someone writes the code to make async work with them. Aleph (netty) is very good though. No reason to not use it.

@dominicm how does aleph handle synchronous code? let's say I write my handlers like before, making sync calls to db etc. will it perform worse than jetty in this case, or equally good, but could perform better than jetty if I put the db calls in future/used let-flow etc?

@sickill as far as I know, equally good or better. Netty is very quick, I think it's used by Twitter.

I see. Last time I checked jetty used auto-increasing thread pool (up to 200 threads) for req processing, and I think aleph uses only a handful (2 * cpu cores?)

@sickill https://clojurians.slack.com/archives/yada/p1483699840000450

and put it onto a specific executor if you don't want to use the standard manifold executor

or when you don't want to do this for every blocking call, specify a custom executor in the options of aleph's start-server

@sickill http://netty.io/testimonials it can apparently handle 10k concurrent requests.

The optimal setting for number of threads is something like 2*cpu+1, see http://martinsprogrammingblog.blogspot.co.uk/2011/12/asynchronous-workflows-in-clojure.html for why this is

I like the diagrams in this blog - the point is the most efficient scheme is where you spend more time working and less time scheduling - having all CPUs working on the workload all the time is very efficient

Netty can scale well beyond 10K connections if you tune the OS - it's used at Apple, Facebook, Twitter, Yahoo, Google etc. for their 'most demanding workloads': https://www.infoq.com/presentations/apple-netty

This sounds great, and I know the benefits of netty. Of course if I write my code explicitly to use the full benefits of netty (via manifold etc), it will utilize the cpu greatly and scale well. My question was: if I don't pro-actively write code this way (initially), having blocking db calls like I have in a regular jetty setup, will this still compare with jetty's auto-growing thread pool, or will it lose with jetty (because I only have 2*cpu+1 threads and all are blocked all the time)

I know yada itself is utilizing aleph's async greatly, asynchronously handling cases where my response fn is not used

but I assume 90% of the requests are hitting my response fns anyway

Pretty sure you'd lose to Jetty if you had more concurrent connections than 2*cpu+1, as those threads won't be released for other work to be done until your blocking call completes

yeah, this is what I think too

with small workload both jetty and netty would work equally fine, but with higher no. of concurrent reqs jetty would be winning, but then making your code really async on netty would give you perf unachievable on jetty (you can't just be adding hundreds more of worker threads on jetty ad inifinitum)

in my use case I don't expect massive load, so I'll just not worry about all this and use netty, making more use of aleph's/yada's async support down the road when it makes sense

custom executor suggested by @stijn sounds like a low hanging fruit

Part of the requirements also include streaming responses, which an executor doesn't solve.

hmm, aleph's default executor grows its pool based on utilization up to 512 threads

and judging by this https://github.com/juxt/yada/blob/8181df043c86c5cfe6503102732ab3444094b013/ext/aleph/src/yada/aleph.clj yada uses this default one (unless you explicitly override one via :executor in options passed to (listener))