Topic: a simple traffic load test run (Read 10521 times)

The same could be said about any currency or object, but to come to the forum to ask for advice, expect to get plenty of advice. The test network is there to test and if anything it would be the best place to start. You would want to move up to more production testing later on once you are certain that the test is doing what you want it to do and NOT what you want it to do.

You can't test for something looking for a certain result and end up getting 20 other results that you didn't expect and have no idea why they are being produced until each was examined later on.

You could always build you own network with the -connect=xxx.xxx.xxx.xxx option to make a private network of actual release version BitCoin clients and try to blow it up that way. 

From a purely ethical view no one "owns" the distributed system nor "owes" anyone else anything.  If someone is generating a ton of transactions to the point of annoying people then transaction fees start to apply.    Otherwise, the system *is broken* and needs to be fixed.

I want to use bitcoin to enable a  "micro payment" system but need the system to operate at a much higher speed.

Effectively, you cannot depend upon "trust" and "fair play" in the usage of a P2P system.  This is why we uses economics and money to allocate limited resources to those who will pay the most.   The result is that the "cost" to post transactions to the test network should be much less than the cost to post transactions to the real network. 

So assume someone started a p2p system that was generating one million small transactions per second among 10 million unique addresses each belonging to a unique individual conducting legitimate business.  What would happen?   

My example here would be a distributed "world wide web" where individuals were paid to host content "bit torrent style" and peers would pay BTC per block of the torrent downloaded. 

Ok, I hear you, I just wonder about your situation. Why are you putting so much "Real Money" with capitalization and value into a beta experimental system? Are you over-committed to something flaky? Declaring it so doesn't make it so. Is the "beta" designation in error? Should it be promoted to  version 1.0?

I agree the first test, even if it would be inconclusive, should have been on the test net. Sorry, like I said I wasn't aware. I hadn't read hardly any of the forums even. Bitcoins just seemed like a cool toy and I wanted to play with it.

I guess I never expected people to stake their life's saving or even a day's wages on the thing at its current stage of development. It still doesn't make sense to me to do anything of the sort. Obviously some people see it differently. I will try not to repeat my mistake.

bitcoins are experimental, and the system may fail for any number of reasons.

However, there is Real Money and value attached to bitcoins.  You're not being a good network citizen if you're messing with that.

I think the point here is that the test network is there for tests specifically. If you are going to try and test something, say stealing everyone's bitcoins, it is preferred you do that on the test network for obvious reasons.

Now a load test is not really very useful on a test network if you are interested in real world data because, you are just testing the test network. I would guess that the test net has less clients on it then the production network. Now that being said I would test my code against the test net first until I know it's not going to break anything. I don't think this type of test would be too annoying on the production network as long as it doesn't violate two rules. The first is that it not cause a denial of service on the network or real actual transactions. The second is that it should not fill up everyone disk with a large data log.

I would be willing to add a node or two to the test network for a load test. I have window and linux boxes that I could use.

Ok seems to be a philosophical difference here. Is it really a "production" network? It is still running on software labeled as "beta" sending the signal that it is not ready for "production". Are we really already to the point of being unwilling to tolerate failure because bitcoins still seems to be very much experimental. I am confused.

It's preferable, when possible to identify and fix vulnerabilities before they can harm the production system. The test network is more vulnerable in most cases, so it's a better candidate to find vulnerabilities and as a bonus it doesn't annoy lots of people.

Any chance to get the test network into bitcoin/trunk, #ifdef'd out?

The goal (my goal, at least) is to have some working distributed monetary system, not to keep a (potentially) broken system online without interruption. The whole idea of a "test" network is nonsense -- every test should be done on the main network if possible, since real problems that could occur might otherwise be missed.

I would also be willing to run tests for this. I have about 6000kh/s at my disposal.

If we kept the test relatively short I don't mind throwing on a few EC2 instances on the test network to help out.

Sorry, I wasn't even aware of the test network. My bad.

Can we organize a LARGER test for the test network? More people at once.

Stress testing the "test network" is a way to at least not annoy those who are trying to do positive things with Bitcoins.  Tests of this nature will naturally be causing more work for others who are not necessarily wanting to be involved in these kind of tests.  Those running the test network realize the very experimental nature and don't mind CPU and disk bandwidth being wasted for those efforts.

From a purely ethical point of view, I think it is much better to test on the test network first, especially if it is to exploit something in the communications protocol that you think needs to be strengthened.

Really? I would think/hope that the real one is way more robust. No?

Well, at least do it on the TEST network FIRST!

If you manage to break the TEST network, it's a pretty good bet that you'll be able to break the production network.  If it doesn't break the TEST network, then I'd say go ahead and run against the production network to look for "scaling up" problems.

You can't get real data from such a small network. Besides, a reliable network must be able to withstand any kind of testing.

Please do these tests on the test network.  That's what it's for.  Thanks.

No.

Was that on the test network?
https://bitcointalksearch.org/topic/test-network-for-experimental-development-and-hacking-363

There was a lot of slowdown in the rate of transactions during the second half of the test. If this was a problem with the network, then I would be very worried about future denial of service attacks. Hopefully a bigger test can be organized later.

Here is a packet capture of the event (from an "edge" computer with only one connection) if anyone is interested in exact times and stuff.
http://www.freefilehostingnow.com/filedownload.aspx?code=6bb2dbeea18e6a419daaadda5798bb05ec6b

I was able to run IRC and discus the progress of the test thruout so I don't think I was anywhere near saturating any network resources.

I have seen some speculation about scalability and denial of service by spam transactions in the IRC channel so I thought it would be a good idea to try a test.

I set up a stupid little bitcoind script on a couple of my linux machines to send 1000 tiny transaction to a third machine as quickly as they would run.

I asked on IRC for any obvious reasons why I shouldn't do it and got one supporting response thinking it was a good idea to try and one reserved response saying I should ask here first. I brashly decided to go ahead with it.

The scripts just printed a countdown of the number of remaining steps in the loop and the output of the bitcoind sendtoaddress command, normally just "sent".

They both started out quickly till there was something like 600 transactions submitted then both senders started to slow down perceptibly. One was quite a bit faster than the other, 3 or 4 times faster, due I think to a faster CPU. I thought at first it was the clients throtteling me to save the net from overload or something but that was just speculation. We later figured maybe it was the databases getting a bit slow on my old disks.

Then one of my machines suddenly seemed to speed up. But it wasn't really. It was an error, the bitcoind daemon had died. A little bit of investigation found the .bitcoin drive was full so you can't fault the program for giving up there! grin

The other machine was grinding pretty slow by then down to maybe 5 sec per transaction or so just judging by eye. It eventually finished after about 50 minutes. no errors at all.

The machine that crashed after I gave it some more disk space started right back up and showed it had only sent 424 transactions so there is an initial benchmark then - 1424 transactions in 50 minutes. It should be easy to get more.

I think the main thing slowing them down was the .bitcoin/database directory. They seemed to get a lot of data written to them some 184MB on the one that ran outa disk space and 1341 MB on the one that did the full 1000 transactions.

It seems another test with more people more distributed around the net might be in order to try to shake down any potential problems.

The net seemed to shrug it off as if nothing special happened anyway so that is a positive result. The clients mostly did just what they were told and expected except for a possible performance problem with the database.

Thats all I can think of for now.