Clojurians Log v2

@yogthos has joined the channel

@yogthos: welcome! simple_smile

hello simple_smile

can you post those traces for @tcrawley please?

sure thing

@tcrawley: he's using inc 714

@yogthos: you see no failed requests from the client, right? just these exceptions on the server?

the latter exception is ignorable I think. The former is a problem

the client seems fine in the browser at least

what does the code look like that triggers the first exception?

but when ab runs it might get some bad responses?

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

@yogthos: make sure you see the correct port in your log, please simple_smile

oh right simple_smile

this same code ran w/o error on 2.1.2?

let me flip the dependency back to make sure

I believe it only happens when run functions are chained

ok yeah I'm not seeing errors without the incremental build

do you see errors on every request to /json, or just some?

I must be doing something wrong. if I lein run the app, then git localhost:3000/json, I get a 404

@yogthos: ^

hitting / gives me "Hello, World!"

oh go to `/io/json

ah, thanks

cause that's served by the nested handler

and you don't see the error every request? only intermittently? only under load?

@tcrawley: pretty sure only load. he didn't see it in the browser

yeah it's definitely not for every request

I ran ab -c 10 -n 1000

and only saw a few exceptions

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

what OS/java version are you on?

I don't see errors on every run, and I'm on os x, jdk 8

hmm and now I'm not able to reproduce that either

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

it's troubling that it was there but isn't now, that is

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?

ah, pb. those 2.7k requests would all be errors

simple_smile

you don't see those on stdout?

oh, I do. I just didn't look at std out on the 2.1.2 run :)

haha

@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

with :dispatch? true, I see 12.8k req/seq vs. 13.2k on 714

with :dispatch? false on the latter

ab -c 100 -n 100000 http://127.0.0.1:3000/io/json

i'm running that

I'm -c 50

at some point, you'll see contention between ab and the jvm

so it sounds like I'll remove the middleware for the techempower benchmark, and we should see very nice performance simple_smile

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

yeah that sounds reasonable

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.

fantastic I'll definitely take you up on that simple_smile

@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 😞

no harm in going back!

13.5k r/s with 714/true/b9 which makes sense