BitShares Forum
Main => General Discussion => Topic started by: clayop on September 30, 2015, 07:09:07 am
-
From the third stress test (spamming) I decided to post the report on a separate thread.
3rd Test Plan:
- Time: TBD
- Duration: 30 min
- Number of VPS Used: 67
- Parameter: Using Xeroc's python script. Interval 1, 10 txs (= 10 tps per each vps)
- Goal: 500 tps
-
From the third stress test (spamming) I decided to post the report on a separate thread.
3rd Test Plan:
- Time: 2015/10/1 00:00 UTC
- Duration: 30 min
- Number of VPS Used: 67
- Parameter: Using Xeroc's python script. Interval 1, 10 txs (= 10 tps per each vps)
- Goal: 500 tps
cool test
twitter facebook gogogo
-
The 3rd test is postponed due to the network problem.
-
thanks for updating. this is good stuff :)
-
I'm waiting for graphene ppa update and over 90% witness participation rate. Once the conditions meet, I will update a stress test plan.
-
I will run preliminary spam test in 15 min (21:30 UTC)
-
Spamming will begin at 2015/10/3 00:30 UTC
VPSs will send about 1200 txs per second for 10 minutes
-
With five different account and vps, I made the biggest block with 3524 txs (391.6 tps)
https://graphene.bitshares.org/#/block/15655
My next goal is four times than this result, with 20 vps and 20 different account, 1000 tps.
-
We made over 1000 TPS!!! (1132.7 tps)
(http://imgur.com/tNQkK2N.png)
26233 '1.6.8' 'init7' 1820
26232 '1.6.10' 'init9' 3398
26231 '1.6.13' 'betaxtrade' 483
26233 '1.6.8' 'init7' 1820 '2015-10-03T14:00:18'
26232 '1.6.10' 'init9' 3398 '2015-10-03T14:00:15'
26231 '1.6.13' 'betaxtrade' 483 '2015-10-03T14:00:12'
-
Next spamming will begin at 23:30 UTC today, for 10 minutes.
-
Did your spam kill the testnet network?
Good work!
-
Did your spam kill the testnet network?
Good work!
Yeah 8) I will upload the screenshot soon
-
Here are screenshots
(http://i.imgur.com/iWEanF6.png)
(http://i.imgur.com/1gGNE3l.png)
-
Maximum: block 36375 : 3238.7 TPS
-
(http://i.imgur.com/iWEanF6.png)
impressive
-
Next stress test will take plact at 2015/10/5 21:00 UTC.
The goal is maintaining 100 tps on average for 30 min (Since I don't have enough CORE, I cannot run for 1 hour)
-
Are you starting the test now
-
eagerly waiting...
-
eagerly waiting...
haha
-
Sorry I made a mistake. The test will start in 50 min (22:10 UTC)
-
Sorry I made a mistake. The test will start in 50 min (22:10 UTC)
:'(
-
Sorry I made a mistake. The test will start in 50 min (22:10 UTC)
:'(
It was simple omission. I forgot input screen session names... :'(
-
Warming up soon... for 1 min.
-
1 minute left...
-
5 min elapse. NO witness is down (!) and around 70-130 TPS
-
I think web-wallet server should be upgraded :P
-
I think web-wallet server should be upgraded :P
:P yep block explorer extremly stucking currently ..
-
(http://imgur.com/V2VrGw3.png)
-
(http://imgur.com/V2VrGw3.png)
Great! +5%
-
(http://imgur.com/V2VrGw3.png)
Nice Job ！ :D
-
8) that is awesome job +5% +5% +5% +5%
-
+1
-
Next small test in 15 min (22:25 UTC). 30 TPS for 1 hour.
-
(http://imgur.com/skUHD3S.png)
-
30 TPS / 1 hour test. Seems quite stable.
(http://imgur.com/GZsIbKf.png)
-
If there was a way of preventing a witness node from sharing any blocks other than the block they just produced, I think we could reduce the network lag that seems to be the issue with higher tps.
Said another way. If a witness node only had to worry about receiving transactions, receiving blocks, and broadcasting a block on there turn would it reduce the performance requirements enough to make it worth the changes?
-
If there was a way of preventing a witness node from sharing any blocks other than the block they just produced, I think we could reduce the network lag that seems to be the issue with higher tps.
Said another way. If a witness node only had to worry about receiving transactions, receiving blocks, and broadcasting a block on there turn would it reduce the performance requirements enough to make it worth the changes?
Cool, other than nodes doing that, will make them a prime targets for a ddos attack...
-
If there was a way of preventing a witness node from sharing any blocks other than the block they just produced, I think we could reduce the network lag that seems to be the issue with higher tps.
Said another way. If a witness node only had to worry about receiving transactions, receiving blocks, and broadcasting a block on there turn would it reduce the performance requirements enough to make it worth the changes?
Cool, other than nodes doing that, will make them a prime targets for a ddos attack...
There are ways to mitigate DDoS attacks that I am certain the best and brightest will be utilizing now and inn coming years. :)
-
If there was a way of preventing a witness node from sharing any blocks other than the block they just produced, I think we could reduce the network lag that seems to be the issue with higher tps.
Said another way. If a witness node only had to worry about receiving transactions, receiving blocks, and broadcasting a block on there turn would it reduce the performance requirements enough to make it worth the changes?
Cool, other than nodes doing that, will make them a prime targets for a ddos attack...
There are ways to mitigate DDoS attacks that I am certain the best and brightest will be utilizing now and inn coming years. :)
I definitely have mixed fillings on the term 'inn coming' :)
...especially when combined with 'the best'
-
If there was a way of preventing a witness node from sharing any blocks other than the block they just produced, I think we could reduce the network lag that seems to be the issue with higher tps.
Said another way. If a witness node only had to worry about receiving transactions, receiving blocks, and broadcasting a block on there turn would it reduce the performance requirements enough to make it worth the changes?
Cool, other than nodes doing that, will make them a prime targets for a ddos attack...
There are ways to mitigate DDoS attacks that I am certain the best and brightest will be utilizing now and inn coming years. :)
I definitely have mixed fillings on the term 'inn coming' :)
...especially when combined with 'the best'
damn your spell checker tony! :'(
-
60 TPS / 20 min test will begin at 21:25 UTC
-
5 min... looks really awesome
(http://imgur.com/A2K8f1Q.png)
-
Some inits seems to be forked.
-
Some inits seems to be forked.
Actually all of them.
-
It looks perfect ;)
(http://imgur.com/vTvrIi0.png)
-
Some inits seems to be forked.
Actually all of them.
This was not because of the flood, but due to a loss of internet connectivity in our office. They recovered automatically (with no intervention on my part) when the internet came back up. This is especially interesting because they produced a very long fork because all 10 were on one machine.
-
100 TPS / 1 hour test will take place at 10/8 18:00 UTC (14:00 EST, 11:00 PST)
-
100 TPS / 1 hour test will take place at 10/8 18:00 UTC (14:00 EST, 11:00 PST)
I always have a hard time converting to my local time, so if anybody has the same promblem here you go:
http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=8&year=2015&hour=18&min=0&sec=0 (http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=8&year=2015&hour=18&min=0&sec=0)
-
Flooding nodes are forked :'( I have to setup them again... I will notice the next test schedule soon.
-
100 TPS / 1 hour test will begin at 10/8 20:00 UTC
-
Stress test will begin at 10/9 19:00 UTC
-
Looks very stable.
(http://imgur.com/LZLTMun.png)
-
How long is it gonna run for? Just had to stop working on the GUI due to this because it's killing my witness_node... :(
-
How long is it gonna run for? Just had to stop working on the GUI due to this because it's killing my witness_node... :(
1 hour... Sorry about that :(
-
delegate.btsnow is out
-
How long is it gonna run for? Just had to stop working on the GUI due to this because it's killing my witness_node... :(
1 hour... Sorry about that :(
Me too. Stopping the test would be preferred at this point.
-
delegate.btsnow is out
Talking with him now. His machine is running with a debug build on windows on a home internet connection with FULL logging on VM.
-
100 TPS / 23 min stress test result. Result: "Stable"
(http://i.imgur.com/Qs4HGwf.png)
-
I think there should be enough time to test, for example, for 10 hours.
-
(http://i.imgur.com/iWEanF6.png)
impressive
@kenCode
That`s the screenshot
-
That is the coolest grab I have ever seen. Sexy.