This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-03
Channels
- # admin-announcements (2)
- # beginners (18)
- # boot (118)
- # cider (12)
- # cljs-dev (12)
- # cljsrn (24)
- # clojure (142)
- # clojure-art (4)
- # clojure-bangladesh (3)
- # clojure-ireland (1)
- # clojure-italy (7)
- # clojure-norway (4)
- # clojure-poland (207)
- # clojure-russia (101)
- # clojurescript (108)
- # clojurewerkz (2)
- # core-async (6)
- # css (8)
- # data-science (23)
- # datomic (31)
- # devcards (2)
- # emacs (8)
- # funcool (25)
- # hoplon (34)
- # immutant (78)
- # ldnclj (7)
- # lein-figwheel (4)
- # leiningen (6)
- # luminus (35)
- # off-topic (1)
- # om (119)
- # onyx (43)
- # parinfer (29)
- # proton (11)
- # re-frame (25)
- # remote-jobs (1)
- # slack-help (1)
- # spacemacs (3)
- # yada (10)
@yogthos: welcome!
can you post those traces for @tcrawley please?
@tcrawley: he's using inc 714
@yogthos: you see no failed requests from the client, right? just these exceptions on the server?
so the sample project is here https://github.com/yogthos/luminus-benchmark
I assume it would be around here https://github.com/yogthos/luminus-benchmark/blob/cc45d278159d34857a2d0a94c28671c90a407502/src/clj/hello/core.clj#L19
and that calls out to Immutant here https://github.com/luminus-framework/luminus-immutant/blob/master/src/luminus/http_server.clj
@yogthos: make sure you see the correct port in your log, please
I must be doing something wrong. if I lein run
the app, then git localhost:3000/json, I get a 404
@tcrawley: pretty sure only load. he didn't see it in the browser
ok, I'll try the same here and see if I can recreate, then maybe add some debug output to collect more data
@yogthos: do you see some errors every ab run? or only some? I've ran it several times, and tried bumping up -c and -n, with no errors
fwiw, i'm unable to replicate as well
that's troubling - the only way I can see for this to happen is if an exchange gets reused somehow, but I can't see what could cause that
i'm beginning to feel better about undertow not being the bottleneck, though.
the good news is, with ab -c 50 -n 100000
, I see 2.7k req/s with 2.1.2, and 13.2k req/s with 714
@yogthos: is there a simple way to only omit the formats middleware?
@tcrawley: is that an apples-to-apples test without being able to set :dispatch? false?
you don't see those on stdout?
@tcrawley: more troubling to me is that i actually see a little better perf from 2.1.2 with dispatch true
than i do with 714 and dispatch false
ab -c 100 -n 100000 http://127.0.0.1:3000/io/json
i'm running that
so it sounds like I'll remove the middleware for the techempower benchmark, and we should see very nice performance
sounds like this would be a reasonable default for luminus as well? :worker-threads 200 :io-threads (* 2 (.availableProcessors (Runtime/getRuntime))))
@yogthos: it really depends on your hardware
and your app
@yogthos: the immutant defaults are 1xProcessors for io and 8xIO for workers
you might breach someone's ulimit with 200 workers
and the immutant defaults are undertow's so i kinda yield to their expertise
regardless, as long as you make it clear in your template where to adjust them, i don't think it matters much what you default them to
@tcrawley: i see 12k r/s with 714/false and 15k r/s with 2.1.2/true
I think I'm going to add a "server tuning" section in the docs and discuss different strategies there
@yogthos: good idea. happy to review when you have something.
@tcrawley: i still see slightly better perf with 2.1.2/true at 30 clients
@tcrawley: it may be undertow, though. forcing 2.1.2 to use 1.3.18 slows down to 10k r/s
but that's still dispatching
let's try 714 with b9
yeah, that's 16k r/s with 714/false/b9
so undertow got slower
now i feel stupid for bumping wboss up off b9 😞
13.5k r/s with 714/true/b9 which makes sense