fixed in shoreline
|1 week ago|
|benchmarks||2 weeks ago|
|pixelflut||1 week ago|
|render||1 week ago|
|rpc||1 week ago|
|.gitignore||2 years ago|
|IDEAS.md||2 weeks ago|
|LICENSE||2 years ago|
|README.md||2 weeks ago|
|main.go||2 weeks ago|
Highly efficient distributed Pixelflut client.
Pixelflut endlich durchgespielt.
- Steffen Cybert
N-no more micro-ddosing: bring on ssome Hochwasser and exppperience colors never seen befffore!1!
Hochwasser brings back the D in social DDoSing! Man, I forgot which one..
- Doc Brown
goinstallation >= 1.12
go get github.com/SpeckiJ/Hochwasser
go install github.com/SpeckiJ/Hochwasser
The help texts may be lacking, it's recommended to read
Look at the
github.com/SpeckiJ/Hochwasser/pixelflut subpackage, it contains the performance sensitive core.
The code is getting somewhat
bloatedenterprise-ready, so if you want to quickly render a fun thing,
it may be easier to just build a separate executable on top of
pixelflut.Flut(), than to extend Hochwasser.
The following benchmark was run on a max-spec X280 against version d4c574b.
I could not figure out what the performance bottleneck is, but it doesn't seem to be CPU limited, as turbo-boost doesn't kick in.
To reproduce, run the following commands in separate shells:
iperf -s -p 1234 go run main.go -image benchmark/test.png -connections 10
55 Gbps on average! 🌊🌊🌊
./sturmflut 127.0.0.1:1337 benchmark/test.png -t 10, version
8ec6ee9) managed to get 48 Gpbs throughput on this system.
Hint: Benchmarking throughput against the pixelnuke server is pointless, as performance is then CPU-limited to ~1 Gbps by the server. Using iperf removes the server limitation. This also means that these metrics of several Gbps are far higher than realworld scenarios.