1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
# Stoppable
[](https://travis-ci.org/hunterloftis/stoppable)
> Node's `server.close()` the way you probably [expected it to work by default](https://github.com/nodejs/node/issues/2642).
## Summary
```js
const server = stoppable(http.createServer(handler))
server.stop()
```
Stoppable stops accepting new connections and closes existing, idle connections (including keep-alives)
without killing requests that are in-flight.
## Requirements
- Node.js v6+
Node.js v4.x is *unofficially* supported.
## Installation
```bash
yarn add stoppable
```
(or use npm)
## Usage
**constructor**
```js
stoppable(server, grace)
```
Decorates the server instance with a `stop` method.
Returns the server instance, so can be chained, or can be run as a standalone statement.
- server: Any HTTP or HTTPS Server instance
- grace: Milliseconds to wait before force-closing connections
`grace` defaults to Infinity (don't force-close).
If you want to immediately kill all sockets you can use a grace of 0.
**stop()**
```js
server.stop(callback)
```
Closes the server.
- callback: passed along to the existing `server.close` function to auto-register a 'close' event.
The first agrument is an error, and the second argument is a boolean that indicates whether it stopped gracefully.
## Design decisions
- Monkey patching generally sucks, but in this case it's the nicest API. Let's call it "decorating."
- `grace` could be specified on `stop`, but it's better to match the existing `server.close` API.
- Clients should be handled respectfully, so we aren't just destroying sockets, we're sending `FIN` packets first.
- Any solution to this problem requires bookkeeping on every connection and request/response.
We're doing a minimum of work on these "hot" code paths and delaying as much as possible to the actual `stop` method.
## Performance
There's no way to provide this functionality without bookkeeping on connection, disconnection, request, and response.
However, Stoppable strives to do minimal work in hot code paths and to use optimal data structures.
I'd be interested to see real-world performance benchmarks;
the simple loopback artillery benchmark included in the lib shows very little overhead from using a stoppable server:
### Without Stoppable
```plain
Scenarios launched: 10000
Scenarios completed: 10000
Requests completed: 10000
RPS sent: 939.85
Request latency:
min: 0.5
max: 51.3
median: 2.1
p95: 3.7
p99: 15.3
Scenario duration:
min: 1
max: 60.7
median: 3.6
p95: 7.6
p99: 19
Scenario counts:
0: 10000 (100%)
Codes:
200: 10000
```
### With Stoppable
```plain
Scenarios launched: 10000
Scenarios completed: 10000
Requests completed: 10000
RPS sent: 940.73
Request latency:
min: 0.5
max: 43.4
median: 2.1
p95: 3.8
p99: 15.5
Scenario duration:
min: 1.1
max: 57
median: 3.7
p95: 8
p99: 19.4
Scenario counts:
0: 10000 (100%)
Codes:
200: 10000
```
## License
MIT
|
