BitShares Forum
Main => Stakeholder Proposals => Topic started by: emski on August 27, 2014, 03:26:35 pm
-
Now that BitsharesX is running stable more than a month...
And we have the testnet experiencing all kinds of attacks ... (Good Job! Once again to alt)
We have also stress tested the test networks many times during the dry runs, and the networks were remarkably reliable...
We see the REAL BitsharesX network loaded below 10% of its capacity... (correct me if I'm wrong here, but I haven't seen significant transaction volume, except some isolated peaks)
I'm ready to execute a controlled "stress test" - creating significant amount of transactions to show the world what the network is capable of. (of course this was done many times on the dry runs but this is the real deal). The aim is about 0.8 transaction per second for a few minutes.
This should be done at pre-anounced time when everyone is online monitoring the delegates, the network, the seed nodes and the performance.
Perhaps this might include some network flood against some of the seed nodes and/or delegates. The entire procedure should last only a few minutes and will be closely monitored.
Of course such test is costly so the minimal transaction fee should be paid. The normal users that pay default fee should still be able to use the network normally because their transactions should be included with priority.
If this idea is accepted by the community I'll suggest this to be the first project funded by the angel fund (collected by angel delegate which is ~ 7000 BTSX ) and see if that will be approved by voters (how will this happen is TBA).
This will effectively burn the sum acquired by angel delegate AND provide proof that the network is reliable. This might give us some insights on how the network is prepared to handle the approaching waves of new users. It might also show us weak spots.
Given the relatively inexpensive nature of the test it is better to be done sooner than later.
Share your thoughts on this.
-
+5%
Excellent idea! You have my vote.
-
+5%
Excellent idea! You have my vote.
A controlled stress test will degrade user experience due to increased sync times and scan times. I think we keep "stress tests" on the "test network".
-
+5%
Excellent idea! You have my vote.
A controlled stress test will degrade user experience due to increased sync times and scan times. I think we keep "stress tests" on the "test network".
My point is that such "stress" will be reached with normal use sooner or later.
The test network is completely different than the real one (unless all delegates run another instance in the test network).
I think such test will be beneficial for the confidence in the network (any marketing words on this?).
The parameters can be altered of course but I think something like this should be done and possible issues identified before the horde of users attack.
Have you played Diablo III on the launch week ? Sims?
PS: I'm not going to attempt anything unless I have community approval !
-
Lets get known bugs resolved first ;)
-
Lets get known bugs resolved first ;)
Wise.
-
I think we REALLY need to fix all bugs that
a) make delegates crash
b) decrease user-experience
we tested the DPOS pretty much in the testnets already and I think we will handle the most traffic that will come at us in the next 3 months at least ..
just my 2 bitcents
-
I think we REALLY need to fix all bugs that
a) make delegates crash
b) decrease user-experience
we tested the DPOS pretty much in the testnets already and I think we will handle the most traffic that will come at us in the next 3 months at least ..
just my 2 bitcents
True.
What I want to iterate: Real net is not testnet. We saw the performance on the testnets but we had different delegates there different amount of nodes, different setups. Real network is not tested.
I agree about first fixing the bugs though.
-
Is it time yet ?
-
Devshares is a good platform for this.
-
Devshares is a good platform for this.
+5%
Excellent idea! You have my vote.
A controlled stress test will degrade user experience due to increased sync times and scan times. I think we keep "stress tests" on the "test network".
My point is that such "stress" will be reached with normal use sooner or later.
The test network is completely different than the real one (unless all delegates run another instance in the test network).
I think such test will be beneficial for the confidence in the network (any marketing words on this?).
The parameters can be altered of course but I think something like this should be done and possible issues identified before the horde of users attack.
Have you played Diablo III on the launch week ? Sims?
PS: I'm not going to attempt anything unless I have community approval !
-
Devshares is not just a test network, it is more or less an exactly replay of the bitshares network. It is much better than XTS for stress testing.
-
Devshares is not just a test network, it is more or less an exactly replay of the bitshares network. It is much better than XTS for stress testing.
Software is a copy of the real network. Delegates and seed nodes are not.
Anyway we'll see how BTS handles the load when it grows.