loadtest 7.1.0 → 7.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/FUNDING.yml +13 -0
- package/README.md +11 -7
- package/lib/loadtest.js +1 -1
- package/package.json +1 -1
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# These are supported funding model platforms
|
|
2
|
+
|
|
3
|
+
github: alexfernandez
|
|
4
|
+
patreon: # Replace with a single Patreon username
|
|
5
|
+
open_collective: # Replace with a single Open Collective username
|
|
6
|
+
ko_fi: # Replace with a single Ko-fi username
|
|
7
|
+
tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
|
|
8
|
+
community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
|
|
9
|
+
liberapay: # Replace with a single Liberapay username
|
|
10
|
+
issuehunt: # Replace with a single IssueHunt username
|
|
11
|
+
otechie: # Replace with a single Otechie username
|
|
12
|
+
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
|
|
13
|
+
custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
|
package/README.md
CHANGED
|
@@ -85,14 +85,18 @@ so that you can abort deployment e.g. if 99% of the requests don't finish in 10
|
|
|
85
85
|
but it is still limited.
|
|
86
86
|
`loadtest` saturates a single CPU pretty quickly,
|
|
87
87
|
so it uses half the available cores in your processor.
|
|
88
|
-
|
|
89
|
-
which happens approx. when your load is above 4000~
|
|
90
|
-
please adjust the number of cores.
|
|
88
|
+
The Node.js processes can reach 100% usage in `top`,
|
|
89
|
+
which happens approx. when your load is above 4000~7000 rps per core.
|
|
90
|
+
In this case please adjust the number of cores.
|
|
91
91
|
So for instance with eight cores you can expect to get a maximum performance of
|
|
92
|
-
8 * 5000
|
|
93
|
-
|
|
92
|
+
8 * 5000 = 40 krps.
|
|
93
|
+
|
|
94
|
+
You can measure the practical limits of `loadtest` on your specific test machines by running it against a simple
|
|
94
95
|
[test server](#test-server)
|
|
95
|
-
and seeing when it reaches 100% CPU.
|
|
96
|
+
and seeing when it reaches 100% CPU. Run the following commands on two different consoles:
|
|
97
|
+
|
|
98
|
+
$ node bin/testserver.js
|
|
99
|
+
$ node bin/loadtest.js -n 1000000 -c 100 http://localhost:7357/
|
|
96
100
|
|
|
97
101
|
If you have reached the limits of `loadtest` even after using all cores,
|
|
98
102
|
there are other tools that you can try.
|
|
@@ -100,7 +104,7 @@ there are other tools that you can try.
|
|
|
100
104
|
* [AutoCannon](https://www.npmjs.com/package/autocannon): also an `npm` package,
|
|
101
105
|
awesome tool with an interface similar to `wrk`.
|
|
102
106
|
* [Apache `ab`](http://httpd.apache.org/docs/2.2/programs/ab.html)
|
|
103
|
-
has great performance, but it is
|
|
107
|
+
has great performance, but it is limited by a single CPU performance.
|
|
104
108
|
Its practical limit is somewhere around ~40 krps.
|
|
105
109
|
* [weighttp](http://redmine.lighttpd.net/projects/weighttp/wiki) is also `ab`-compatible
|
|
106
110
|
and is supposed to be very fast (the author has not personally used it).
|
package/lib/loadtest.js
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "loadtest",
|
|
3
|
-
"version": "7.1.
|
|
3
|
+
"version": "7.1.1",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "Run load tests for your web application. Mostly ab-compatible interface, with an option to force requests per second. Includes an API for automated load testing.",
|
|
6
6
|
"homepage": "https://github.com/alexfernandez/loadtest",
|