DEV Community: Frank@theOpenSourceU.org

Revisited Concept: High Performance web server w/ Promises

Frank@theOpenSourceU.org — Wed, 14 Mar 2018 13:53:00 +0000

This is a follow up to my earlier article: Concept: High Performance web server w/ Promises.

I decided to follow this up for two main reasons. First and foremost, there was an error in the original code I posted and I couldn't remember if that error existed in the code I actually tested with or if it was introduced during my writing of the article. Second, I didn't have any of my detailed data to share and I feel that is relevant to this type of article.

The Concept

The TL;DR of the concept is: Can we get higher HTTP server throughput (higher RPS) by using a promise even when not needed. That is, no async operation exists.

Please see the first article for more details.

Methodology

I recreated my project but this time I saved it as open source. It's a basic WebStorm express template with handlebars as the view manager. I've modified it to introduce my concept and that looks like:

const myData = { title: 'Promise Express' };

/* GET /promise/ */
router.get('/', function(req, res) {
    new Promise(function(resolve, reject) {
        resolve(myData); //setup data
    }).then(function(d) {
        res.render('index', d); //render the view in the 'then'
    });
});

I used Artillery for the load testing aspect. Artillery was run from my desktop computer (not on the server running the express project). Using Artillery, we create the following scenarios:

10 users each making 20 GET requests
50 users each making 30 GET requests
100 users each making 30 GET requests
500 users each making 100 GET requests

The exact server details are: Ubuntu 16.04 LTS DigitalOcean Droplets, Flexible Droplets - 2 GB 2x vCPUs ($15 a month).

Note: I also did one run on a 1 GB 1x vCPU droplet as well which is documented at the very bottom.

Summary of Differences

There are a few technical differences from my initial article and this version aside from the depth of content. ( Format : first article vs this article)

Promise library: Pinkie vs Bluebird)
The server: 1x CPU, 1 GB VPS vs 2x CPU, 2 GiB VPS
- I did check the prev. config though without getting errors.
Handlebars: No view template engine vs Handlebars

Results

The results are different than my first article. Basically, it doesn't help but it doesn't hurt...

No scenario threw any errors (which was different from my first run as I recall.) I've made the assumption that this has to do with my promise library of choice; bluebird is known and written to be very fast.

Raw Results

Following are the "cut and paste" raw results from Artillery for detailed reference and review. Also, in case I mistyped something into a chart or table.

2x vCPU, 2 GiB RAM

Basic - 10 "Virtual Users", 20 GETs

λ artillery quick --count 10 -n 20 http://159.65.99.177:3000/basic
Started phase 0, duration: 1s @ 15:00:41(-0600) 2018-03-06
Report @ 15:00:44(-0600) 2018-03-06
  Scenarios launched: 10
  Scenarios completed: 10
  Requests completed: 200
  RPS sent: 68.49
  Request latency:
    min: 64.3
    max: 139.3
    median: 71.8
    p95: 119.8
    p99: 137.9
  Codes:
    200: 200

All virtual users finished
Summary report @ 15:00:44(-0600) 2018-03-06
  Scenarios launched: 10
  Scenarios completed: 10
  Requests completed: 200
  RPS sent: 68.03
  Request latency:
    min: 64.3
    max: 139.3
    median: 71.8
    p95: 119.8
    p99: 137.9
  Scenario counts:
    0: 10 (100%)
  Codes:
    200: 200

Promise - 10 "Virtual Users", 20 GETs

λ artillery quick --count 10 -n 20 http://159.65.99.177:3000/promise
Started phase 0, duration: 1s @ 15:01:44(-0600) 2018-03-06
Report @ 15:01:47(-0600) 2018-03-06
  Scenarios launched: 10
  Scenarios completed: 10
  Requests completed: 200
  RPS sent: 82.64
  Request latency:
    min: 62.3
    max: 144.8
    median: 71.1
    p95: 116.5
    p99: 140.7
  Codes:
    200: 200

All virtual users finished
Summary report @ 15:01:47(-0600) 2018-03-06
  Scenarios launched: 10
  Scenarios completed: 10
  Requests completed: 200
  RPS sent: 82.3
  Request latency:
    min: 62.3
    max: 144.8
    median: 71.1
    p95: 116.5
    p99: 140.7
  Scenario counts:
    0: 10 (100%)
  Codes:
    200: 200

Basic - 50 "Virtual Users", 30 GETs

λ artillery quick --count 50 -n 30 http://159.65.99.177:3000/basic
Started phase 0, duration: 1s @ 15:06:18(-0600) 2018-03-06
Report @ 15:06:22(-0600) 2018-03-06
  Scenarios launched: 50
  Scenarios completed: 50
  Requests completed: 1500
  RPS sent: 373.13
  Request latency:
    min: 63
    max: 376.4
    median: 84.5
    p95: 130.4
    p99: 149.2
  Codes:
    200: 1500

All virtual users finished
Summary report @ 15:06:22(-0600) 2018-03-06
  Scenarios launched: 50
  Scenarios completed: 50
  Requests completed: 1500
  RPS sent: 372.21
  Request latency:
    min: 63
    max: 376.4
    median: 84.5
    p95: 130.4
    p99: 149.2
  Scenario counts:
    0: 50 (100%)
  Codes:
    200: 1500

Promise - 50 "Virtual Users", 30 GETs

λ artillery quick --count 50 -n 30 http://159.65.99.177:3000/promise
Started phase 0, duration: 1s @ 15:06:57(-0600) 2018-03-06
Report @ 15:07:01(-0600) 2018-03-06
  Scenarios launched: 50
  Scenarios completed: 50
  Requests completed: 1500
  RPS sent: 374.06
  Request latency:
    min: 63.2
    max: 360.3
    median: 82.6
    p95: 132.8
    p99: 166
  Codes:
    200: 1500

All virtual users finished
Summary report @ 15:07:01(-0600) 2018-03-06
  Scenarios launched: 50
  Scenarios completed: 50
  Requests completed: 1500
  RPS sent: 372.21
  Request latency:
    min: 63.2
    max: 360.3
    median: 82.6
    p95: 132.8
    p99: 166
  Scenario counts:
    0: 50 (100%)
  Codes:
    200: 1500

Basic - 100 "Virtual Users", 30 GETs

λ artillery quick --count 100 -n 30 http://159.65.99.177:3000/basic
Started phase 0, duration: 2s @ 15:11:15(-0600) 2018-03-06
Report @ 15:11:21(-0600) 2018-03-06
  Scenarios launched: 100
  Scenarios completed: 100
  Requests completed: 3000
  RPS sent: 543.48
  Request latency:
    min: 62.3
    max: 220.3
    median: 114
    p95: 155.4
    p99: 174.5
  Codes:
    200: 3000

All virtual users finished
Summary report @ 15:11:21(-0600) 2018-03-06
  Scenarios launched: 100
  Scenarios completed: 100
  Requests completed: 3000
  RPS sent: 541.52
  Request latency:
    min: 62.3
    max: 220.3
    median: 114
    p95: 155.4
    p99: 174.5
  Scenario counts:
    0: 100 (100%)
  Codes:
    200: 3000

Promise - 100 "Virtual Users", 30 GETs

λ artillery quick --count 100 -n 30 http://159.65.99.177:3000/promise
Started phase 0, duration: 2s @ 15:12:23(-0600) 2018-03-06
Report @ 15:12:28(-0600) 2018-03-06
  Scenarios launched: 100
  Scenarios completed: 100
  Requests completed: 3000
  RPS sent: 542.5
  Request latency:
    min: 63.6
    max: 240.4
    median: 117.1
    p95: 196.8
    p99: 209.9
  Codes:
    200: 3000

All virtual users finished
Summary report @ 15:12:28(-0600) 2018-03-06
  Scenarios launched: 100
  Scenarios completed: 100
  Requests completed: 3000
  RPS sent: 540.54
  Request latency:
    min: 63.6
    max: 240.4
    median: 117.1
    p95: 196.8
    p99: 209.9
  Scenario counts:
    0: 100 (100%)
  Codes:
    200: 3000

Basic - 200 "Virtual Users", 50 GETs

λ artillery quick --count 200 -n 50 http://159.65.99.177:3000/basic
Started phase 0, duration: 4s @ 15:21:01(-0600) 2018-03-06
Report @ 15:21:11(-0600) 2018-03-06
  Scenarios launched: 200
  Scenarios completed: 0
  Requests completed: 5737
  RPS sent: 592.91
  Request latency:
    min: 62.1
    max: 528.2
    median: 272
    p95: 403.4
    p99: 431.9
  Codes:
    200: 5737

Report @ 15:21:17(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 200
  Requests completed: 4263
  RPS sent: 735.08
  Request latency:
    min: 66.1
    max: 552.1
    median: 214.4
    p95: 272.9
    p99: 289.2
  Codes:
    200: 4263

All virtual users finished
Summary report @ 15:21:17(-0600) 2018-03-06
  Scenarios launched: 200
  Scenarios completed: 200
  Requests completed: 10000
  RPS sent: 641.03
  Request latency:
    min: 62.1
    max: 552.1
    median: 245.8
    p95: 382.5
    p99: 424.9
  Scenario counts:
    0: 200 (100%)
  Codes:
    200: 10000

Promise - 200 "Virtual Users", 50 GETs

λ artillery quick --count 200 -n 50 http://159.65.99.177:3000/promise
Started phase 0, duration: 4s @ 15:22:10(-0600) 2018-03-06
Report @ 15:22:20(-0600) 2018-03-06
  Scenarios launched: 200
  Scenarios completed: 0
  Requests completed: 5664
  RPS sent: 585.81
  Request latency:
    min: 65.7
    max: 468.6
    median: 290.4
    p95: 384.7
    p99: 414.3
  Codes:
    200: 5664

Report @ 15:22:27(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 200
  Requests completed: 4336
  RPS sent: 589.17
  Request latency:
    min: 62.7
    max: 433.5
    median: 249.1
    p95: 375.4
    p99: 408.7
  Codes:
    200: 4336

All virtual users finished
Summary report @ 15:22:27(-0600) 2018-03-06
  Scenarios launched: 200
  Scenarios completed: 200
  Requests completed: 10000
  RPS sent: 585.14
  Request latency:
    min: 62.7
    max: 468.6
    median: 270.6
    p95: 381.6
    p99: 410
  Scenario counts:
    0: 200 (100%)
  Codes:
    200: 10000

Basic - 500 "Virtual Users", 100 GETs

λ artillery quick --count 500 -n 100 http://159.65.99.177:3000/basic
Started phase 0, duration: 10s @ 15:27:51(-0600) 2018-03-06
Report @ 15:28:01(-0600) 2018-03-06
  Scenarios launched: 499
  Scenarios completed: 0
  Requests completed: 2969
  RPS sent: 347.05
  Request latency:
    min: 68.3
    max: 1459.7
    median: 657.3
    p95: 1170.9
    p99: 1273.4
  Codes:
    200: 2969

Report @ 15:28:11(-0600) 2018-03-06
  Scenarios launched: 1
  Scenarios completed: 0
  Requests completed: 3221
  RPS sent: 322.3
  Request latency:
    min: 1228.9
    max: 2406.5
    median: 1474.4
    p95: 2157.3
    p99: 2234.8
  Codes:
    200: 3221

Report @ 15:28:21(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3465
  RPS sent: 347.19
  Request latency:
    min: 1170.7
    max: 1972.4
    median: 1472.9
    p95: 1591.9
    p99: 1623.6
  Codes:
    200: 3465

Report @ 15:28:31(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 2944
  RPS sent: 295.29
  Request latency:
    min: 1336.3
    max: 2194.1
    median: 1659.1
    p95: 1851.4
    p99: 1917.3
  Codes:
    200: 2944

Report @ 15:28:41(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 2695
  RPS sent: 269.5
  Request latency:
    min: 1511
    max: 2925.6
    median: 1708.7
    p95: 2599.9
    p99: 2763
  Codes:
    200: 2695

Report @ 15:28:51(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3173
  RPS sent: 317.3
  Request latency:
    min: 1215.4
    max: 2177.5
    median: 1605.9
    p95: 1855.3
    p99: 1914.4
  Codes:
    200: 3173

Report @ 15:29:01(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3103
  RPS sent: 311.55
  Request latency:
    min: 1365.4
    max: 2064.8
    median: 1575.2
    p95: 1790.9
    p99: 1839.5
  Codes:
    200: 3103

Report @ 15:29:11(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3926
  RPS sent: 392.21
  Request latency:
    min: 1007.3
    max: 1879
    median: 1298.1
    p95: 1652.6
    p99: 1695.8
  Codes:
    200: 3926

Report @ 15:29:21(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3500
  RPS sent: 351.05
  Request latency:
    min: 1035.3
    max: 2560.6
    median: 1223.3
    p95: 2261.8
    p99: 2317.5
  Codes:
    200: 3500

Report @ 15:29:31(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3762
  RPS sent: 375.82
  Request latency:
    min: 892
    max: 2616
    median: 1372.8
    p95: 1992.1
    p99: 2263.5
  Codes:
    200: 3762

Report @ 15:29:41(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 4787
  RPS sent: 478.22
  Request latency:
    min: 872.3
    max: 1304.4
    median: 1029.1
    p95: 1211.3
    p99: 1256.7
  Codes:
    200: 4787

Report @ 15:29:51(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 2
  Requests completed: 4288
  RPS sent: 429.89
  Request latency:
    min: 955.4
    max: 1546.2
    median: 1154.3
    p95: 1316
    p99: 1342.4
  Codes:
    200: 4288

Report @ 15:30:01(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 43
  Requests completed: 3345
  RPS sent: 330.86
  Request latency:
    min: 1169.9
    max: 2025.5
    median: 1439.5
    p95: 1695.3
    p99: 1735.2
  Codes:
    200: 3345

Report @ 15:30:11(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 128
  Requests completed: 3091
  RPS sent: 297.19
  Request latency:
    min: 1062.3
    max: 2158.7
    median: 1313.9
    p95: 1688.9
    p99: 1725.6
  Codes:
    200: 3091

Report @ 15:30:17(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 327
  Requests completed: 1731
  RPS sent: 256.67
  Request latency:
    min: 67.3
    max: 1544.1
    median: 812.7
    p95: 1134.7
    p99: 1194.8
  Codes:
    200: 1731

All virtual users finished
Summary report @ 15:30:17(-0600) 2018-03-06
  Scenarios launched: 500
  Scenarios completed: 500
  Requests completed: 50000
  RPS sent: 342.4
  Request latency:
    min: 67.3
    max: 2925.6
    median: 1343.2
    p95: 1868.3
    p99: 2289
  Scenario counts:
    0: 500 (100%)
  Codes:
    200: 50000

Promise - 500 "Virtual Users", 100 GETs

λ artillery quick --count 500 -n 100 http://159.65.99.177:3000/promise
Started phase 0, duration: 10s @ 15:23:49(-0600) 2018-03-06
Report @ 15:23:59(-0600) 2018-03-06
  Scenarios launched: 499
  Scenarios completed: 0
  Requests completed: 2840
  RPS sent: 334.13
  Request latency:
    min: 73.3
    max: 1409
    median: 838
    p95: 1189.6
    p99: 1291.6
  Codes:
    200: 2840

Report @ 15:24:09(-0600) 2018-03-06
  Scenarios launched: 1
  Scenarios completed: 0
  Requests completed: 3281
  RPS sent: 328.3
  Request latency:
    min: 1109.5
    max: 2140.4
    median: 1508.1
    p95: 1780.6
    p99: 1811.6
  Codes:
    200: 3281

Report @ 15:24:19(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3164
  RPS sent: 316.4
  Request latency:
    min: 1341.6
    max: 2064.7
    median: 1568.2
    p95: 1747.3
    p99: 1788.5
  Codes:
    200: 3164

Report @ 15:24:29(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3389
  RPS sent: 338.9
  Request latency:
    min: 1130.1
    max: 2303.4
    median: 1441.1
    p95: 1931.9
    p99: 2009.6
  Codes:
    200: 3389

Report @ 15:24:39(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3653
  RPS sent: 365.3
  Request latency:
    min: 1129.9
    max: 1912.8
    median: 1344
    p95: 1672
    p99: 1750.4
  Codes:
    200: 3653

Report @ 15:24:49(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3239
  RPS sent: 323.8
  Request latency:
    min: 1177.4
    max: 2181.4
    median: 1541.4
    p95: 1996.8
    p99: 2080.1
  Codes:
    200: 3239

Report @ 15:24:59(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3167
  RPS sent: 316.7
  Request latency:
    min: 1211.1
    max: 2267.6
    median: 1557
    p95: 1819.5
    p99: 1874.5
  Codes:
    200: 3167

Report @ 15:25:09(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3285
  RPS sent: 328.6
  Request latency:
    min: 1291.1
    max: 2083.3
    median: 1534.9
    p95: 1748.2
    p99: 1818.5
  Codes:
    200: 3285

Report @ 15:25:20(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3217
  RPS sent: 322.02
  Request latency:
    min: 1195
    max: 2412.1
    median: 1554.5
    p95: 1967.8
    p99: 2017.9
  Codes:
    200: 3217

Report @ 15:25:30(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3744
  RPS sent: 375.53
  Request latency:
    min: 1024.8
    max: 1831.5
    median: 1325
    p95: 1604.3
    p99: 1667.5
  Codes:
    200: 3744

Report @ 15:25:40(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3376
  RPS sent: 337.6
  Request latency:
    min: 1266.4
    max: 1897.7
    median: 1509.7
    p95: 1641.8
    p99: 1688.3
  Codes:
    200: 3376

Report @ 15:25:50(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 3311
  RPS sent: 331.1
  Request latency:
    min: 1124.3
    max: 2060.3
    median: 1534.3
    p95: 1781.6
    p99: 1822.9
  Codes:
    200: 3311

Report @ 15:26:00(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 10
  Requests completed: 3122
  RPS sent: 312.45
  Request latency:
    min: 1254.5
    max: 2007.5
    median: 1627.3
    p95: 1750.8
    p99: 1789.1
  Codes:
    200: 3122

Report @ 15:26:10(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 50
  Requests completed: 3369
  RPS sent: 332.23
  Request latency:
    min: 1104.9
    max: 1970.4
    median: 1416.5
    p95: 1659.1
    p99: 1730.9
  Codes:
    200: 3369

Report @ 15:26:20(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 209
  Requests completed: 3203
  RPS sent: 299.4
  Request latency:
    min: 827.1
    max: 1679.7
    median: 1181.5
    p95: 1464.4
    p99: 1502.7
  Codes:
    200: 3203

Report @ 15:26:22(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 231
  Requests completed: 640
  RPS sent: 162.95
  Request latency:
    min: 118.2
    max: 944.7
    median: 790.7
    p95: 894
    p99: 928.5
  Codes:
    200: 640

All virtual users finished
Summary report @ 15:26:22(-0600) 2018-03-06
  Scenarios launched: 500
  Scenarios completed: 500
  Requests completed: 50000
  RPS sent: 326.71
  Request latency:
    min: 73.3
    max: 2412.1
    median: 1460.3
    p95: 1776.8
    p99: 1962.2
  Scenario counts:
    0: 500 (100%)
  Codes:
    200: 50000

1x CPU, 1 GiB Ram

Basic - 500 "Virtual Users", 100 GETs

λ artillery quick --count 500 -n 100 http://159.65.98.204:3000/basic
Started phase 0, duration: 10s @ 16:06:07(-0600) 2018-03-06
Report @ 16:06:17(-0600) 2018-03-06
  Scenarios launched: 499
  Scenarios completed: 0
  Requests completed: 6656
  RPS sent: 714.79
  Request latency:
    min: 64.3
    max: 734.5
    median: 357.6
    p95: 558.2
    p99: 615.7
  Codes:
    200: 6656

Report @ 16:06:27(-0600) 2018-03-06
  Scenarios launched: 1
  Scenarios completed: 0
  Requests completed: 8778
  RPS sent: 876.05
  Request latency:
    min: 499.7
    max: 868.6
    median: 575.8
    p95: 605.5
    p99: 626.5
  Codes:
    200: 8778

Report @ 16:06:37(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 8864
  RPS sent: 884.73
  Request latency:
    min: 476.5
    max: 873.3
    median: 568.8
    p95: 603.4
    p99: 615.9
  Codes:
    200: 8864

Report @ 16:06:47(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 8760
  RPS sent: 874.25
  Request latency:
    min: 473.4
    max: 849.6
    median: 569.5
    p95: 614.6
    p99: 633.4
  Codes:
    200: 8760

Report @ 16:06:57(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 65
  Requests completed: 8857
  RPS sent: 877.45
  Request latency:
    min: 467.9
    max: 856.4
    median: 542.4
    p95: 590
    p99: 613.9
  Codes:
    200: 8857

Report @ 16:07:07(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 435
  Requests completed: 8085
  RPS sent: 802.73
  Request latency:
    min: 63
    max: 554.6
    median: 415.7
    p95: 503
    p99: 517.4
  Codes:
    200: 8085

All virtual users finished
Summary report @ 16:07:07(-0600) 2018-03-06
  Scenarios launched: 500
  Scenarios completed: 500
  Requests completed: 50000
  RPS sent: 834.72
  Request latency:
    min: 63
    max: 873.3
    median: 552.7
    p95: 600.5
    p99: 622.7
  Scenario counts:
    0: 500 (100%)
  Codes:
    200: 50000

Promise - 500 "Virtual Users", 100 GETs

λ artillery quick --count 500 -n 100 http://159.65.98.204:3000/promise
Started phase 0, duration: 10s @ 16:08:07(-0600) 2018-03-06
Report @ 16:08:17(-0600) 2018-03-06
  Scenarios launched: 499
  Scenarios completed: 0
  Requests completed: 7403
  RPS sent: 788.61
  Request latency:
    min: 63.5
    max: 700
    median: 306.2
    p95: 516.4
    p99: 564.6
  Codes:
    200: 7403

Report @ 16:08:28(-0600) 2018-03-06
  Scenarios launched: 1
  Scenarios completed: 0
  Requests completed: 9068
  RPS sent: 904.99
  Request latency:
    min: 470.2
    max: 822.4
    median: 555.3
    p95: 593.2
    p99: 613.7
  Codes:
    200: 9068

Report @ 16:08:38(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 0
  Requests completed: 8916
  RPS sent: 893.39
  Request latency:
    min: 473.4
    max: 872.2
    median: 561.1
    p95: 603.4
    p99: 629.3
  Codes:
    200: 8916

Report @ 16:08:48(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 9
  Requests completed: 8784
  RPS sent: 875.75
  Request latency:
    min: 503.8
    max: 694.4
    median: 565.7
    p95: 645.4
    p99: 677.2
  Codes:
    200: 8784

Report @ 16:08:58(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 90
  Requests completed: 8995
  RPS sent: 888.62
  Request latency:
    min: 406.5
    max: 804.5
    median: 516.3
    p95: 569
    p99: 588.2
  Codes:
    200: 8995

Report @ 16:09:06(-0600) 2018-03-06
  Scenarios launched: 0
  Scenarios completed: 401
  Requests completed: 6834
  RPS sent: 799.25
  Request latency:
    min: 62.2
    max: 533.6
    median: 375.8
    p95: 449.2
    p99: 506.3
  Codes:
    200: 6834

All virtual users finished
Summary report @ 16:09:06(-0600) 2018-03-06
  Scenarios launched: 500
  Scenarios completed: 500
  Requests completed: 50000
  RPS sent: 855.72
  Request latency:
    min: 62.2
    max: 872.2
    median: 536.9
    p95: 598.4
    p99: 645.7
  Scenario counts:
    0: 500 (100%)
  Codes:
    200: 50000

TED Talk: Teach girls bravery, not perfection (Reshma Saujani)

Frank@theOpenSourceU.org — Thu, 08 Mar 2018 16:08:25 +0000

I have a daughter (as well as a beautiful wife) and this topic is of great relevance to me. Not just at home but work, tech - just life. Sometimes, when executing an idea or project (school or work), we must open ourselves up to criticism and that can be scary.

Let's teach girls to be brave in the face of criticism and resistance. Our girls and women have great ideas and contributions to make and they should be willing and free to do and share them.

Happy International Women's day 2018

Video belongs here: https://theopensourceu.org/ted-talk-teach-girls-bravery-not-perfection-reshma-saujani/

Concept: High Performance web server w/ Promises

Frank@theOpenSourceU.org — Mon, 05 Feb 2018 21:12:25 +0000

Purpose

My intended purpose is to provide a higher level of throughput -- service more requests per second through an async API. It is expected that the time to service each request would increase but that is fine if we handle more requests per second. Or if nothing else, at least handle more requests before issues start to occur.

Concept Overview - How?

The high-level idea is for an http server running on Express + Node. From there, any incoming request is wrapped in a promise and the promise resolves to respond to the request. Of course, if throughout processing the request, other async processing is needed, other then-ables can be used.

For example, this:

/* GET home page. */
router.get('/', function(req, res, next) {
    debug("GET /");
    res.render('site/index', { title: 'The Open Source U' });
});

Becomes:

/* GET home page. */
router.get('/', function(req, res, next) {
  new Promise(function() {
    debug("GET /");
    return { title: 'The Open Source U' }; //calculation or object
  })
  .then(function(payload) {
    res.render('site/index', payload)
  });
});

This is regardless of need. So, I intentionally have no async operation but still use a promise; this accurately represents my idea.

Result: Ineffective

I quickly did a proof of concept... which showed that this doesn't help. In fact, it made performance worse. In considering why, I suspect the cost to service the promise (memory and processing) is more costly than simply responding to the http request.

This is not to say a promise should be avoided in the http request/response cycle but it should, instead, be used at async appropriate times. Regardless, we've learned something here and I thought it was worth sharing.

Success is not final, failure is not fatal: it is the courage to continue that counts. Winston Churchill

I am disappointed this didn't have even a neutral effect on performance, let alone a negative one but it is what it is.

Update (new article coming)

Because of a comment on Dev.to (here), I've revisited this. The commenter pointed out a mistake I made in the code I posted. That code was an example and not 1:1 from the original test code (which I ran from a Linode server).

I've posted my test code here: https://github.com/TheOpenSourceU/tOSU-PromiseWebServer-Experiment

I should have done this in the first place.

Programmer vs Software Engineer

Frank@theOpenSourceU.org — Mon, 13 Nov 2017 19:12:30 +0000

I came across this thread via the CodeProject Daily News. The original forum post reads:

I continually have to check the details of syntax and stuff when programming. Things like print format specifiers, the syntax of things I haven't used for a year or so, and use a calculator to work out bit masks and check my bitwise logic. I can never get it right in my head.

I don't remember details. I don't pride myself on that. I spend my time and energy on the big picture. Designing and understanding complex mechanisms. The architecture. The guts of the machine.

So I think of myself as a software engineer, not a programmer.

How about you lot?

-- Munchies_Matt

This is a topic I see pop up once in a while... In some instances, even going as far as saying "software engineering isn't real engineering". (Though this isn't a case of that.)

Anyway, for posterity, I'd like to put forth my definition.

A software engineer is an individual that carefully considers and crafts the composition of the software... perhaps even the whole system, whereas a programmer, by contrast, is focused on individual feature(s), routines, functions or classes.

In my observation of real-world scenarios, (various commercial and open source projects) a programmer (by my definition) will achieve a given goal efficiently (both time and lines of code) but without regard to component composition or the relationship of the components among the whole system.

Concepts to Implementations: Promise

Frank@theOpenSourceU.org — Thu, 06 Jul 2017 19:23:28 +0000

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

-MDN

Put simply^[1], it is a means to reorganize asynchronous (concurrently executing) code to reduce nesting among other reasons.

Over the next couple of posts, I'm going to give a brief primer on what a promise is and how to use it but the main purpose of this article is to understand how a Promise library is implemented. I was poking through the source code of Pinkie not too long ago and it seemed like a great article candidate.

Why use one?

Without going into too much detail, they are used to avoid "Callback Hell" as well as create a more familiar code-flow (the try/catch). pattern. Here's a contrived but pseudo real-world example:

// require statements omitted for readability and brevity.
function processData( startingData, cbResult ) {
  //
  // Do something with startingData and ultimatly set result to finalizedResult.
  // ...
  var finalizedResult = startingData;
  cbResult(finalizedResult);
} 

function parentMethod() {
  fs.readFile('/my/made/up/file.txt', function callback1(err, data) {
    if(err) throw err;
    processData( data, function callback2(results) {
      sendResultToServer(result, function callback3(response) {
        executionOrderGetsConfusing(response);
      });
    });
  });
}

A promise allows us to restructure the code as such as this:

//
// require statements omitted for readability and brevity.
var readFile = Promise.promisify(require("fs").readFile); //See http://bluebirdjs.com/docs/api/promise.promisify.html

function processData( startData ) {
  //Return a promise which impl will use "then" to implement what was "cbResult"
  return new Promise( function(resolve) {
    //
    // Do something with startingData and ultimatly set result to finalizedResult.
    // ...
    var finalizedResult = startingData;
    return finalizedResult; //Returning something makes it available in chained 'then' statements.
  } );
}

function parentMethod() {
  readFile('/my/made/up/file.txt')
    .then(function callback1(data) {    //Note that (data) => {} is a newer way of defining a function in JS. 
      return processData( data );       //Not available everywhere yet though. Equiv. to function(data) {}
    })
    .then(function callback2(results) {
      return sendResultsToServer(result);
    })
    .then(function callback3(response) {
      executionOrderIsClearer(); //as well as where each method starts and ends.
    })
    .catch(function(err) {
      // Handle errors from the readFile to callback3. 
      // Like wraping the above in a try/catch
    });
}

There appears to be more code in the later version because, I suppose, there is. The use of a promise doesn't reduce code. It makes the flow more obvious. And I do believe that is achieved here. You now see the order of execution more clearly. Each then statement must be completed before the previous then statement and should an error occur, the catch(function(er){}) will intercede to allow you to handle the error gracefully.

More examples

Promises in JavaScript has become quite ubiquitous. Should you want to see more examples or practical uses of Promises, the pg-promise library has excellent up-to-date examples that are both clear and real-world. The library itself is a PostgreSQL interface for Node.

In the next post, we'll look at how promise libraries are implemented by dissecting the implementation by Floatdrop called Pinkie. A small ES2015 Promise implementation.

An Oversimplification but suitable for our purposes. ↩︎

Bit Masks

Frank@theOpenSourceU.org — Sun, 26 Mar 2017 19:44:19 +0000

Bit masks are a computer science concept; in a nutshell, they represent options which can be combined in a variety of ways.

A very basic example colors. Blue and Green combined create yellow. This can be represented in bit masks.

The following example is sourced from the Bit field article on Wikipedia; it illustrates the concept well for those new to it.

Consider the following^[1] and take note of the binary version which is in the comment.

// primary colors
#define BLUE 4 /* 100 */
#define GREEN 2 /* 010 */
#define RED 1 /* 001 */

This creates the base options. The next example uses the above to further define more colors without assigning them specific numbers, although they would output as numbers.

// mixed colors
#define BLACK 0 /* 000 */
#define YELLOW (RED | GREEN) /* 011 */
#define MAGENTA (RED | BLUE) /* 101 */
#define CYAN (GREEN | BLUE) /* 110 */
#define WHITE (RED | GREEN | BLUE) /* 111 */

Notice that WHITE is all the colors -- all the bits are "on" and black is no color -- all the bits are off.

I've seen this used quite a bit although, I must admit, I don't come across it quite as often as I used to. Rest assured, it is still in use and is quite useful.

The code presented is Pseudocode. It is not intended to be complete. ↩︎

Bouncy - Open Source Code Exploration

Frank@theOpenSourceU.org — Sat, 18 Mar 2017 18:09:01 +0000

Bouncy is a tool to "pipe raw http traffic from [an] incoming http request to a another remote end point."

It's an interesting tool and, for me, a useful find. Not to reveal too much but this site is running on Node among other technologies.

I think this tool has a lot of possible applications^[1] but for me, it acts as a virtual host router. I don't want to go into too much detail here (you can see here for more info) but in my scenario, I wanted to setup my server so that I could host another site on the same server if needed or desired.

Bouncy allows me to do that; using bouncy I created a small custom program that listens on port 80 (the website port). When it accepts an incoming request it routes it to the correct site which is running on another port (on the same server) -- say 8000 for discussion.

It determines the site via the request host headers (req.headers.host).

Summary of example configuration:

Bouncy = Port 80
The Open Source U = Port 8000
Possible future sites = Port 8001, 8002, etc

It's a small library (it's available as a CLI tool as well) and I think it's an excellent candidate for a first article. I'm, frankly, curious how it works and it's small enough to sort out the structure of these posts.

For the purpose of this article, I've forked the git repository to https://github.com/TheOpenSourceU/bouncy

I'll use and reference this version in this article. Because the parent/source project could continue to be developed, I've created a branch called tOSU/explore. This will remain consistent with this article whereas master can deviate. I want to keep master consistent with the sources' master.

Technology Prerequisites

I'll do my best to link or explain related technologies and concepts. A principle goal of this site is to engage folks with a diverse backgrounds and experience levels.

That said, I do make some assumptions about a basic familiarity with some technology. At this time, I don't have public comments on this site but should you need to provide critical (respectful) feedback or ask questions, please feel use the GitHub issues located here.

Index of Dependencies

Knowing and understanding the high-level purpose of a package/programs dependencies is helpful in understanding the parent application.

Bouncy has two main dependencies (for those unfamiliar, this is in the package.json file.

// ...
"dependencies" : {
 "through": "~2.3.4",
 "optimist": "~0.3.5"
},
// ...

through: Creates a stream that is readable and writable.
optimist: (deprecated) is a command line option parser written by the same author as Bouncy.

index.js

The entry point and frankly the main implementation. Bouncy is built on top of the bog standard NodeJS http/https library and in a way, simply wraps it. Given it's relationship to http/https, Bouncy is event driven.

The correct server type is created (secure or not); then three events are assigned handlers. The first is the connection or secureConnection event which is handled by an anonymous function which we'll call the "connection event handler". The other two events are upgrade and request which are both assigned onrequest.

Connection Event Handler

This accepts the parameter stream. This represents the network stream of data coming in for the request. The handler adds a property called _bouncyStream which is the results of stealthBuffer().

The next snippet is the nuts and bolts of the handler.

var src = stream._bouncyStream = stealthBuffer();
// ... old version work around ...
else stream.pipe(src);

At this point, stream is an instance of Socket and src is an instance of Stream. (Notice that despite the name, stream is not Stream -- that capital "S" is important.)

The src (Stream) is piped (sent) to the Socket. This completes the set up of the connection. Now, bouncy will wait for incoming requests and through onrequest, route them.

`onrequest`

This is the main purpose of Bouncy. This ultimately bounces the request to another port via the cb parameter as this is the user implemented code provided as a callback.

Here's the example given on the GitHub page.

var bouncy = require('bouncy');

var server = bouncy(function (req, res, bounce) {
    if (req.headers.host === 'beep.example.com') {
        bounce(8001);
    }
    else if (req.headers.host === 'boop.example.com') {
        bounce(8002);
    }
    else {
        res.statusCode = 404;
        res.end('no such host');
    }
});
server.listen(8000);

The anonymous function passed into the bouncy and is called after some setup which is mainly creating the bounce method. The end user then calls bounce with the appropriate port and said method pipes the connection to the new path.

This "bounces" the request to the new port.

`stealthBuffer()`

stealthBuffer() returns an instance of the dependency through; recall this provides the means to make a stream readable and writable.

This is ultimately used in the connection event handler. The bottom line is it augments the request for passing it through to the bounce method in the onrequest handler.

I'm wondering if Bouncy can be used to load balance the same site on two different instances of NodeJS. I strongly suspect it could and hope to test that soon... ↩︎

DEV Community: Frank@theOpenSourceU.org

Revisited Concept: High Performance web server w/ Promises

The Concept

Methodology

Summary of Differences

Results

Raw Results

2x vCPU, 2 GiB RAM

Basic - 10 "Virtual Users", 20 GETs

Promise - 10 "Virtual Users", 20 GETs

Basic - 50 "Virtual Users", 30 GETs

Promise - 50 "Virtual Users", 30 GETs

Basic - 100 "Virtual Users", 30 GETs

Promise - 100 "Virtual Users", 30 GETs

Basic - 200 "Virtual Users", 50 GETs

Promise - 200 "Virtual Users", 50 GETs

Basic - 500 "Virtual Users", 100 GETs

Promise - 500 "Virtual Users", 100 GETs

1x CPU, 1 GiB Ram

Basic - 500 "Virtual Users", 100 GETs

Promise - 500 "Virtual Users", 100 GETs

TED Talk: Teach girls bravery, not perfection (Reshma Saujani)

Concept: High Performance web server w/ Promises

Purpose

Concept Overview - How?

Result: Ineffective

Update (new article coming)

Programmer vs Software Engineer

Concepts to Implementations: Promise

Why use one?

More examples

Next

Bit Masks

Bouncy - Open Source Code Exploration

Technology Prerequisites

Index of Dependencies

index.js

Connection Event Handler

onrequest

stealthBuffer()

`onrequest`

`stealthBuffer()`