This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-02-27
Channels
- # announcements (47)
- # babashka (36)
- # beginners (7)
- # biff (34)
- # calva (9)
- # cider (5)
- # clj-http (13)
- # clj-kondo (24)
- # cljs-dev (9)
- # clojure (146)
- # clojure-austin (1)
- # clojure-europe (16)
- # clojure-nl (1)
- # clojure-norway (8)
- # clojure-uk (2)
- # clojurescript (4)
- # clr (1)
- # core-async (9)
- # cursive (11)
- # datomic (6)
- # emacs (17)
- # events (3)
- # fulcro (45)
- # graphql (7)
- # helix (1)
- # hyperfiddle (28)
- # java (1)
- # london-clojurians (1)
- # lsp (75)
- # malli (1)
- # membrane (35)
- # reitit (6)
- # releases (1)
- # shadow-cljs (48)
- # tools-build (5)
- # tools-deps (27)
Finally got around to publish https://github.com/ferdinand-beyer/refx to Clojars: v0.0.49 is available now!
refx
is a port of re-frame without Reagent, bringing re-frame’s elegance to next-generation React wrappers such as Helix or UIx. Thanks to @rome-user
(GitHub handle, not sure if they’re in Slack) for fixing a bug in reg-sub
!
Nice work. Great to have the https://github.com/ferdinand-beyer/refx/tree/main/examples too.
Thanks for your work Ferdinand. I've ported some reitit/re-frame examples to refx as well, if anyone is interested in more samples. The port was 1:1 when looking at re-frame vs refx code: https://github.com/rafaeldelboni/helix-refx-reitit-example
Released https://clojure-lsp.io/ https://github.com/clojure-lsp/clojure-lsp/releases/tag/2023.02.27-13.12.12 with fixes, performance and behavior improvements 🎉
There are improvements in hover being able to follow :arglists
for documentation, support for cljs docs search on clojuredocs, big performance improvement in completion and more improvements!
More details in #CPABC1H61
Thank you for all sponsors and ClojuristsTogether 💙
https://github.com/mpenet/mina 0.1.13 is updated with the latest Nima release (requires java19+Loom preview)
I understand Nima is still relatively new & alpha. But still, I was curious to try apache benchmark against it (or mina). And I was surprised that no matter what value I used for "concurrency" (`-c` ), the benchmark resulted in identical results (total time, requests per second,..)
Also the request per second number wasn't too great: ~ 25k req/s on relatively beefy laptop. I've seen better results on "regular old servers" such as httpkit etc.
Does benchmarking using ab
makes even sense against Nima/Mina? Is is some specific configuration needed in order to get better results?
I recall one benchmark showing 800k req/s on an early nima release, matching the netty impl. of helidon. So I suppose that's likely a config issue and maybe some system level tweaks needed to get there. I haven't run any benchmarks yet myself, but I try to make the code not be wasteful (there are more low hanging fruits, but I don't want to focus on that right now, while in alpha).
if you look at the code involved for reading a req and writing a response it's very thin, I doubt mina is very far from Nima. One thing I will introduce at some point is some "lazy" maps a bit like in aleph to cut down this further, field access would just defer to the underlying method calls and potentially cache values upon access. But not right now.
it's definitely a problem in mina, I got same results with some nima example project (maven + java)
same results
1. https://github.com/tomas-langer/helidon-nima-example (need one more dependency to be added to pom.xml to work)
2. example hello world server using mina
both gave me ~25k req/s using ab
, at both cases it made no difference when I increased concurrency level
right. well, that could be caused by many things, some config tweaks needed in mina/nima itself or OS level (ulimit & co)
I tried checking ulimits and stuff as well, but nothing fishy there. I'll check that TexhEmpower link you mentioned above. Thanks.
I could try to ask the authors to give me some hints on how they achieved 800k for their presentation, they are quite responsive/helpful
I'll also try using different tools than ab
- or at least check if my distro has the up-to-date version
well ab should be able to go further than 20k r/s, I strongly suspect it's not the issue 🙂
it's strange, here's a quick "repro"
(ns httpkitserver.httpkitserver
(:require [org.httpkit.server :as http]
[s-exp.mina :as mina]))
(defn app [_req]
{:status 200
:headers {"Content-Type" "text/html"}
:body "hello HTTP!"})
(comment
;; httpkit start/stop
(def server
(http/run-server app {:port 8080}))
(server)
;; ab -c 8 -k -n 100000
;;Requests per second: 230394.04 [#/sec] (mean)
;; mina start/stop
(def server-mina
(mina/start! app {:port 8080}))
(mina/stop! server-mina)
;; ab -c 8 -k -n 100000
;; Requests per second: 20098.54 [#/sec] (mean)
)
just using wrk instead of ab I get 72k r/s, but maybe that would also bump the numbers of httpkit
➜ ~ # httpkit
➜ ~ wrk -c 30 -t 10
Running 10s test @
10 threads and 30 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 73.09us 62.46us 4.10ms 95.73%
Req/Sec 43.06k 5.28k 57.13k 65.15%
4326476 requests in 10.10s, 536.39MB read
Requests/sec: 428387.33
Transfer/sec: 53.11MB
➜ ~ # mina
➜ ~ wrk -c 30 -t 10
Running 10s test @
10 threads and 30 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 99.78us 116.17us 8.24ms 96.01%
Req/Sec 32.07k 1.03k 34.64k 74.36%
3223260 requests in 10.10s, 421.13MB read
Requests/sec: 319140.63
Transfer/sec: 41.70MB
like I said yesterday, there are still some low hanging fruits for perfs, and I suppose with some tweaks of the server options that would also push it a bit further
Both numbers are quite high, but again, suprisingly, mina/nima is not winning at this game. There might be some important setting somewhere in the options that will change this situation. Or perhaps the virtual threads approach way doesn't necessarily bring better raw performance, but scales to high number of concurrent users in more friendly way (?)
wow 🙂
I might check some nima docs or slack later. Perhaps they'll mention what settings need to be used / configured.
I don't think it's surprising, I am actually quite pleased we're not so far off httpkit, given how early it is and with the default options
wget -nc
wrk -d 15 -c 512 -t 8 --latency \
-H 'Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7' \
-H 'Connection: keep-alive' \
\
-s pipeline.lua
-- 16
the full output was:
File 'pipeline.lua' already there; not retrieving.
Running 15s test @
8 threads and 512 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 438.78us 663.85us 31.01ms 98.82%
Req/Sec 128.64k 13.27k 197.85k 66.89%
Latency Distribution
50% 377.00us
75% 476.00us
90% 541.00us
99% 1.25ms
15381870 requests in 15.10s, 2.35GB read
Requests/sec: 1018686.05
Transfer/sec: 159.33MB
I just landed a tiny optimisation for request map creation/access that should work towards closing the gap with httpkit, more of the same can be done on other things (like request headers access)
Nice speed bump 👍
wrk -c 30 -t 10
previous run with mina 0.1.13
3223260 requests in 10.10s, 421.13MB read
Requests/sec: 319140.63
Transfer/sec: 41.70MB
mina 0.1.14
3777539 requests in 10.10s, 493.55MB read
Requests/sec: 374019.28
Transfer/sec: 48.87MB
btw using that pipeline.lua
bench script you sent, mina is already winning 🙂
(the response is always a simple static hello world response)
httpkit : Requests/sec: 482222.91
mina: Requests/sec: 564992.41
Clojure CLI https://clojure.org/releases/tools#v1.11.1.1237 is now available • Added env var that can be set to temporarily allow support for http repos: CLOJURE_CLI_ALLOW_HTTP_REPO • Remove deprecated support for -R and -C • Clean up help text around repl supporting init-opts
hi @U064X3EF3 thanks for the new release. could you direct me to where i can find more information on CLOJURE_CLI_ALLOW_HTTP_REPO
? can't find it in either cli or tools repos, nor on the TDEPS jira. wondering what it is? thanks
I haven’t doc’ed it yet, but it’s exactly what it says above - an env var that can be set to allow use of Maven repos with http urls (which are disallowed otherwise)