n-st / nench Goto Github PK

VPS benchmark script — based on the popular bench.sh, plus CPU and ioping tests, and dual-stack IPv4 and v6 speedtests by default

License: Apache License 2.0

Shell 100.00%

benchmark vps speedtest

nench's Introduction

nench.sh ("new bench.sh")

Current version always available at https://github.com/n-st/nench

IPv4- and v6-enabled download at http://wget.racing/nench.sh

loosely based on the established freevps.us/bench.sh
includes CPU and ioping measurements
reduced number of speedtests (9 x 100 MB), while retaining useful European and North American POPs
runs IPv6 speedtest by default (if the server has IPv6 connectivity)
has a 10-second timeout for each speedtest, so you don't end up waiting 10 minutes for that one slow speedtest from halfway around the globe — but thanks to the power of curl -w, you still get to see what speed your server achieved during those 10 seconds
successfully tested on Arch Linux, Debian, FreeBSD, and Ubuntu

The script was originally intended to be used only by me, so I didn't put much effort into ensuring safety, security, and interoperability.
I welcome any improvements, just send me a pull request.

Disclaimer

You've probably noticed that the usage examples below have you directly run a script from an unauthenticated source (as so many "easy-install" and benchmark scripts do).

I didn't think I'd have to mention that this is a potential security risk — really, if you're at the point where you're benchmarking Linux VMs, I would assume you know how much harm a rogue shell script could potentially do to your system…

What's more, nench.sh downloads a statically built binary to run the IO latency tests. I assure you it is and always will be a clean unmodified build of ioping, but how do you know you can trust me?

So, basically: use nench.sh at your own risk, and preferably not on production systems (which is a bad idea anyway, because it will hammer your harddisk and network for up to several minutes).

Usage example

(curl -s wget.racing/nench.sh | bash; curl -s wget.racing/nench.sh | bash) 2>&1 | tee nench.log

(wget -qO- wget.racing/nench.sh | bash; wget -qO- wget.racing/nench.sh | bash) 2>&1 | tee nench.log

Example output

Output from a VPS hosted with Vultr in Frankfurt:

-------------------------------------------------
 nench.sh v2017.05.08 -- https://git.io/nench.sh
 benchmark timestamp:    2017-05-08 20:36:54 UTC
-------------------------------------------------

Processor:    Virtual CPU a7769a6388d5
CPU cores:    1
Frequency:    2394.454 MHz
RAM:          494M
Swap:         871M
Kernel:       Linux 3.16.0-4-amd64 x86_64

Disks:
vda  20G  HDD

CPU: SHA256-hashing 500 MB
    4.183 seconds
CPU: bzip2-compressing 500 MB
    6.830 seconds
CPU: AES-encrypting 500 MB
    1.636 seconds

ioping: seek rate
    min/avg/max/mdev = 148.6 us / 280.9 us / 9.22 ms / 234.7 us
ioping: sequential speed
    generated 2.15 k requests in 5.00 s, 536.2 MiB, 428 iops, 107.2 MiB/s

dd test
    1st run:    339.51 MiB/s
    2nd run:    345.23 MiB/s
    3rd run:    342.37 MiB/s
    average:    342.37 MiB/s

IPv4 speedtests
    your IPv4:    108.61.179.xxxx

    Cachefly CDN:         205.34 MiB/s
    Leaseweb (NL):        140.55 MiB/s
    Softlayer DAL (US):   0.08 MiB/s
    Online.net (FR):      0.17 MiB/s
    OVH BHS (CA):         11.13 MiB/s

IPv6 speedtests
    your IPv6:    2001:19f0:6c01:xxxx

    Leaseweb (NL):        101.06 MiB/s
    Softlayer DAL (US):   2.89 MiB/s
    Online.net (FR):      0.18 MiB/s
    OVH BHS (CA):         9.84 MiB/s
-------------------------------------------------

nench's People

Contributors

Stargazers

Watchers

Forkers

enmaskarado gsdu8g9 djtms lewellyn haydenjames anacondaq andrewbayangan ariselia tenacy pengshulin 001101 ajip18 rvong iandk akwmak catonisland matthiaskauer kyroskoh thekilleddead zoonderkins atxiu wujcheng avasni justafakename waiducom hero1471 itseasy21 daokebid raymanchester interbiznw marksagal lcbo2 gragonvlad pakdoz decompiled finas d02415021 ymakeev qqjameqq1 ammarun11 lenonhere rgfernandes wcasanova musthari sinsixx asylumcorp 680642546274012521547861302794192049193 sokratis1904 qimomo coinblockers nicholaswan jeff-alves davje88 r3nic1e lguzzon-scratchbook james-quinto zserverz iamindian nonomal gabrielpetry-forks ryanbekabe rjroot sokratis1988 mredition cicerolneto galaxydata shannon-6block try2go kyaky heartshare laashub-soa areagui mk386 fate2077 svirmi shopwhizzy jkvint lol4ever4ever sitedata huangyingting mikumikume m4k3r-org g0rdonx skiyet wlamir nobuenhombre thytetgc unimol andynechen mrmm sajibekanti ismailh zhifengsong sanbt-ree alligator-1 youseflotfiasef dench7 germanosbh siimaarmaa rere-dnaw

nench's Issues

Redirecting output to a file misses time output / CPU benchmarking

The CPU benchmarking values measured using time are not redirected to the file appropriately, since time prints to stderr by default. I.e. when running bash nensh.sh > nensh.txt the times will be printed to the console (stderr) and not show up in nensh.txt

Changing the lines

    time "$gnu_dd" if=/dev/zero bs=1M count=500 2> /dev/null | \
        "$@" > /dev/null

    ( time "$gnu_dd" if=/dev/zero bs=1M count=500 2> /dev/null | \
        "$@" > /dev/null ) 2>&1

Fixes the issue. There may be an easier solution to this, I'm not well versed in shell programming.

Does not show CPU time in Ububtu 20.04

Ubuntu 20.04

Disks:
sda   38.2G  HDD

CPU: SHA256-hashing 500 MB
    CPU: bzip2-compressing 500 MB
    CPU: AES-encrypting 500 MB
    
ioping: seek rate
    min/avg/max/mdev = 102.7 us / 315.6 us / 19.9 ms / 252.1 us
ioping: sequential read speed
    generated 7.51 k requests in 5.00 s, 1.83 GiB, 1.50 k iops, 375.6 MiB/s

While in CentOS 7, 8

Disks:
sda  152.6G  HDD
sdb    100G  HDD

CPU: SHA256-hashing 500 MB
    2.062 seconds
CPU: bzip2-compressing 500 MB
    6.318 seconds
CPU: AES-encrypting 500 MB
    1.390 seconds

ioping: seek rate
    min/avg/max/mdev = 93.3 us / 363.1 us / 17.9 ms / 363.8 us
ioping: sequential read speed
    generated 5.03 k requests in 5.00 s, 1.23 GiB, 1.01 k iops, 251.7 MiB/s

Getting rid of the static ioping binary

The static binary was originally added for three reasons:

Less effort and system clutter:
Among nench's software requirements, ioping is arguably the most uncommon
and least likely to be present by default.
Providing the static binary avoids additional installations, at least on
binary-compatible systems (Linux amd64 in this case).
Consistent output format:
ioping's output format changed between version 0.9 and 1.0, but 1.0 still
reports the old version:
```
% apt-cache policy ioping
ioping:
  Installed: 1.0-2
  Candidate: 1.0-2
  Version table:
 *** 1.0-2 500
        500 http://httpredir.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
% ioping -v
ioping 0.9
```
The same happens with the static binary, but there I can be certain which
version it is (and parse the output appropriately).

Consistent test scope:
ioping 1.0 added a second summary line (marked with > below) that reports
iops and throughput for the full deadline period (-w) requested on the
commandline, rather than the old summary that excludes data from some of the
probes (such as the "warmup" at the beginning):

% ioping -DRL -w 5 . # ioping 0.9

--- . ( ) ioping statistics ---
301 requests completed in 5.11 s, 58 iops, 14.7 MiB/s
min/avg/max/mdev = 778 us / 17.0 ms / 236.0 ms / 31.4 ms

% ioping -DRL -w 5 . # ioping 1.0

--- . ( ) ioping statistics ---
1.65 k requests completed in 4.99 s, 413.5 MiB read, 331 iops, 82.9 MiB/s
> generated 1.66 k requests in 5.00 s, 413.8 MiB, 330 iops, 82.7 MiB/s
min/avg/max/mdev = 2.75 ms / 3.01 ms / 66.0 ms / 2.10 ms

Long story short, the static binary could be made superfluous by switching to
the "opportunistic" summary line (which is present in both old and new
versions) and selecting it by its content rather than its position in the
output.

It would also be possible to use the -B option (which I wasn't aware of when
I created nench, but which is present even in older versions) and parse the
"raw" output it produces. It may be possible to re-use the Bps_to_MiBps
formatter that's already used for the dd and curl output.

The primary disadvantages would be potentially breaking comparability between
old and new nench results, and requiring the installation of ioping just
for the test.
Perhaps offer the static binary for manual installation (then documented in
the README) and use only the system-installed version if the user doesn't
request otherwise?

dd test
nench.sh: line 161: printf: 2.3e+09: invalid number
    1st run:    0.00 MiB/s
nench.sh: line 164: printf: 2.4e+09: invalid number
    2nd run:    0.00 MiB/s
nench.sh: line 167: printf: 2.6e+09: invalid number
    3rd run:    0.00 MiB/s
nench.sh: line 171: printf: 2.43333e+09: invalid number
    average:    0.00 MiB/s

I should mention this is on a ZFS based fs.

--2019-07-19 14:22:21--  http://speedtest.dal01.softlayer.com/
Resolving speedtest.dal01.softlayer.com (speedtest.dal01.softlayer.com)... 2607:f0d0:1003:31::2
Connecting to speedtest.dal01.softlayer.com (speedtest.dal01.softlayer.com)|2607:f0d0:1003:31::2|:80... failed: Resource temporarily unavailable.
Retrying.

is it okay if i change the test to a another DC with working IPv6?

speedtest.dal05.softlayer.com
speedtest.dal06.softlayer.com
speedtest.dal09.softlayer.com