ring-swagger

ring-swagger & compojure-api
borkdude 2019-03-30T07:23:13.015800Z

@metametadata was it faster than transit? It’s not what I saw in my benchmark but maybe I should try again

borkdude 2019-03-30T07:34:48.016900Z

Maybe it depends on the size of the file. I only tested with a 2mb file

metametadata 2019-03-30T12:51:05.023100Z

Unfortunately, I don't remember all the details, but yeah, the files were bigger: ~10-100 mb. Maybe I was bitten by the issue you found yesterday (https://github.com/cognitect/transit-clj/issues/43)?.. I should also try again I guess and would be happy to be wrong in the end.

ikitommi 2019-03-30T14:59:00.026300Z

Did some quick tests: • for in-process/memory encode+decode, jsonista is 10x faster on small messages. still over 2x faster with 10k payloads. transit requires to read & write streams. Jsonista allows data -> byte[] -> data • for NIO messaging, over the wire, both are fast, with reitit+immutant(my perf fork):

ikitommi 2019-03-30T14:59:32.026800Z

➜  reitit git:(master) ✗ curl <http://127.0.0.1:8080/json>
{"message":"Hello, World!"}%                                                                                                             

➜  reitit git:(master) ✗ curl <http://127.0.0.1:8080/transit>
["^ ","~:message","Hello, World!"]%                                                                                                     

➜  reitit git:(master) ✗ wrk -t20 -c100 -d2s <http://127.0.0.1:8080/json>
Running 2s test @ <http://127.0.0.1:8080/json>
  20 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     0.89ms   94.36us   5.28ms   95.11%
    Req/Sec     5.61k   187.34     5.98k    83.81%
  234540 requests in 2.10s, 34.22MB read
Requests/sec: 111683.59
Transfer/sec:     16.30MB

➜  reitit git:(master) ✗ wrk -t20 -c100 -d2s <http://127.0.0.1:8080/transit>
Running 2s test @ <http://127.0.0.1:8080/transit>
  20 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.04ms  694.28us  12.24ms   97.22%
    Req/Sec     5.13k   590.77     8.91k    93.96%
  211384 requests in 2.10s, 32.25MB read
Requests/sec: 100614.73
Transfer/sec:     15.35MB

ikitommi 2019-03-30T15:00:00.027100Z

didn’t test the latter with larger messages.

metametadata 2019-03-30T15:05:03.028100Z

awesome, thanks. I was just about to publish the similar benchmarks using jsonista.json-perf-test 🙂

1👌
borkdude 2019-03-30T17:04:58.028700Z

@ikitommi @metametadata thanks! I’ll surely try it out now!

1🙏
borkdude 2019-03-30T17:06:11.029400Z

I’m not sure what I’m looking at with this test. I need to serialize to disk, but I think that’s an orthogonal concern right? if it’s faster in memory, it should also be faster to disk

borkdude 2019-03-30T17:06:50.030Z

I hope I can get jsonista to compile with graalvm. I was happy that transit worked, but it’s good to have another candidate

ikitommi 2019-03-30T18:20:36.033300Z

@borkdude haven't tested file perf, but with jsonista, calls are passed directly to Jackson, which supports all kind of file writing & reading oob. Overhead should be zero'ish on clj-side. Some samples on files: https://github.com/metosin/jsonista/blob/master/test/jsonista/core_test.clj#L215-L238

ikitommi 2019-03-30T18:22:06.034600Z

that said, if that is internal format, nippy is also a good option: https://github.com/ptaoussanis/nippy

borkdude 2019-03-30T18:27:35.035400Z

I tried nippy, but that didn’t work with Graal. I could get fressian to work with some tweaks though, but performance was in the same ballpark as transit.

borkdude 2019-03-30T18:27:41.035700Z

for that 2MB file, I didn’t try smaller ones

borkdude 2019-03-30T18:28:51.036500Z

The thing with JSON is, I can’t really save symbols, so it would be better to switch the program model to nested maps that use string keys maybe, if I would switch from transit to json(ista)

borkdude 2019-03-30T19:13:26.037600Z

but that may be worth it altogether because (symbol (str string-or-symbol) (str string-or-symbol)) is driving my crazy already 😉