search

uber-archive / multitransport-jsonrpc

JSON-RPC Client (Node.js & Browser) and Server (Node.js) aim at "natural looking" server and client code.
116 stars 22 forks source link

Tests to see how connection pooling affects performance. #7

Closed dfellis closed 11 years ago

dfellis commented 11 years ago

A quick addition to the tests to simulate connection pooling on the client side. The pooling efficiency is already saturated by 10 connections, and it looks like the source of the perf issue is mostly elsewhere.

I'm suspecting its the way the message is concatenated first and then a null character is searched for. This was done this way to make small messages high performance, but I think it's at the expense of the performance of large messages as it re-checks the same blocks of data over and over again for nulls that can't possibly exist (on the off chance that a single buffer had more than one null, as is possible with small messages). I'll think about a way to check for null characters without rechecking previous buffer pieces over and over again.

Anyways, here's the results of the connection pooling: a perf gain of about 33%

full-stack.js
✔ loopbackHttp
✔ failureTcp
TCP took 712ms, 14044.943820224718 reqs/sec
HTTP took 12979ms, 770.4753833115032 reqs/sec
✔ perf_simple
TCP took 679ms, 14727.540500736377 reqs/sec
HTTP took 12717ms, 786.3489816780688 reqs/sec
✔ perf_100
TCP took 948ms, 10548.523206751055 reqs/sec
HTTP took 12461ms, 802.5038118931064 reqs/sec
✔ perf_1000
TCP took 4573ms, 2186.7483052700636 reqs/sec
HTTP took 13059ms, 765.7554177195804 reqs/sec
✔ perf_10000
TCP took 60795ms, 164.48721111933548 reqs/sec
HTTP took 13080ms, 764.525993883792 reqs/sec
✔ perf_100000
TCP took 46789ms, 213.7254482891278 reqs/sec
HTTP took 13494ms, 741.0701052319549 reqs/sec
✔ perf_100000_10
TCP took 47301ms, 211.41202088750765 reqs/sec
HTTP took 12586ms, 794.5336087716511 reqs/sec
✔ perf_100000_100
dfellis commented 11 years ago

Interesting. The pooling does nothing for Linux.