MultiChain Developer Q&A - Recent questions tagged performance

Single cold node, in-wallet address performance

Mon, 21 Jun 2021 15:55:53 +0000

Hello,

for a University project, we're currently evaluating the possibility of using Multichain as a financial transaction journal engine, with the basic principle of representing each user account as an address in the wallet and using direct RPC calls to read and write information. With this central database approach in mind, we're thinking of running one node only as there's nothing we'd gain from the decentralisation, simply inside our cluster away from the public.

As part of a performance estimation, we tried setting up a chain to the best of our understanding, aiming to optimise as much for performance as possible:

chain-protocol = multichain
chain-description = MultiChain test-10k
root-stream-name = root
root-stream-open = true
chain-is-testnet = false
target-block-time = 2
maximum-block-size = 8388608
maximum-chunk-size = 1048576
maximum-chunk-count = 1024

anyone-can-connect = false
anyone-can-send = true
anyone-can-receive = true
anyone-can-receive-empty = true
anyone-can-create = false
anyone-can-issue = true
anyone-can-mine = false
anyone-can-activate = false
anyone-can-admin = false
support-miner-precheck = true
allow-arbitrary-outputs = false
allow-p2sh-outputs = false
allow-multisig-outputs = false

setup-first-blocks = 3
mining-diversity = 0.0
admin-consensus-upgrade = 0.0
admin-consensus-txfilter = 0.0
admin-consensus-admin = 0.0
admin-consensus-activate = 0.0
admin-consensus-mine = 0.0
admin-consensus-create = 0.0
admin-consensus-issue = 0.0

lock-admin-mine-rounds = 0
mining-requires-peers = true
mine-empty-rounds = 0
mining-turnover = 0.0

initial-block-reward = 0
first-block-reward = -1
reward-halving-interval = 52560000
reward-spendable-delay = 1
minimum-per-output = 0
maximum-per-output = 100000000000000
minimum-offchain-fee = 0
minimum-relay-fee = 0
native-currency-multiple = 100000000

skip-pow-check = true
pow-minimum-bits = 1
target-adjust-freq = -1
allow-min-difficulty-blocks = true

only-accept-std-txs = true
max-std-tx-size = 4194304
max-std-op-returns-count = 32
max-std-op-return-size = 2097152
max-std-op-drops-count = 5
max-std-element-size = 40000

default-network-port = 4771
default-rpc-port = 4770
chain-name = test-10k-fixed
protocol-version = 20012
network-message-start = f9f9cff0
address-pubkeyhash-version = 00330835
address-scripthash-version = 051c4624
private-key-version = 8013627a
address-checksum-value = 906c59f5

genesis-pubkey = 036b0f05c206bb7ac8e6bfd2869f473cf4b4acb0b94195944fe0371a2bfb3157f7
genesis-version = 1
genesis-timestamp = 1618841128
genesis-nbits = 536936447
genesis-nonce = 271
genesis-pubkey-hash = f0b759e6726332558339c7b7a8f6f8721e7927c5
genesis-hash = 00e08d153bf75996cfd758c6d09fd1fca23e7bb836fb47ea59ba15e473f381c5
chain-params-hash = b846252b96d6e3bc24b74eaaaa94163e3fe65584f1d1325992849054dfe07045

We then proceeded to create a total of one million addresses on the chain, using a custom golang script with 10 goroutine workers. This process took about 7 hours. Not stellar, but seeing as it would not be part of a burst phase and only needed for new user signups, it's acceptable.

We then proceeded to issue some different assets for each of the generated addresses using IssueMore (to simulate a user entering the ecosystem and having "paid in" to his account), also using a golang script. This process unfortunately is very slow. Each calls takes about 2 seconds. Since the IssueMore would only be used as a "user is paying in new currency" action, it also should not be that burstable, but 2 seconds on a completely empty chain sounds bad. It also prevents us from creating an equal distribution of currency among the addresses, as it would 2 million seconds per asset.

We have not yet proceeded to test the performance of sending assets between addresses. We were thinking of using SendAssetFrom to send currencies between different addresses - and sending to the burn address in order to simulate a user "cashing out" (with the currency leaving the ecosystem again)

Concrete questions

With the problem and data laid out above, I'd appreciate any feedback, especially regarding:

Is Multichain a sensible choice for a centralised financial transaction database with high throughput?
Are there any steps we can look at to further improve the current performance?
Is there any data available on general scalability of Multichain?

We're happy to supply more information as required and thankful for any further insights.

Kind regards,

Peter

Multichain Benchmarking

Tue, 25 May 2021 09:20:24 +0000

Hello,

We are running multichain network with 10 nodes to test our application which is working on node JS. One complete request takes data from front-end of our application, passes it to backend, and backend pushes it to Multichain node using stream publish. We are using Apache-Jmeter to see the throughput and latency for each node. In my opinion, this is the performance of requests that are sent to multichain node. But in a broader view, how we can analyse multichain network performance.

Setup for 200-300 Tx per second

Tue, 14 Jan 2020 20:38:17 +0000

Hello MC team

I am developing a solution based on 3 nodes ( one for main , second for receiving all the transactions generated against the first node and a third node for backup purposes ) that will have mining permission and this nodes will receive a top peak of 300 transaction per second (api calls) to one of the nodes.What is the recommended hardware and configuration ( of the chain) for supporting this burden and give flexibility for more than 1000 transactions per second in a near future.? These transactions include validating of course.

I am using multichain Comunity edition

Best regards.

How to improve tx/s performance

Sat, 20 Apr 2019 09:07:48 +0000

Hi,

i have deployed a Multichain blockchain on my desktop pc (i5@3.20Ghz, 8GB RAM) with 2 nodes. The performance is really low, since i am getting like 1 tx/s.

My params configurations looks as follows:

target-block-time = 2
maximum-block-size = 1000000000
anyone-can-send = true
anyone-can-receive = true
setup-first-blocks = 60
mining-diversity = 0.5

max-std-tx-size = 10000

Also i am using Windows cmd with a for loop to generate transactions:

for /l %x in (1,1, 10) do multichain-cli blockchain2 sendassettoaddress 1CtfVVPeXsvfdo9C1X37sh3B7hQxgNPsyAjEU2 multicoin 1

I would like to get the maximum tx/s out of my resources, can you help me on identifying the bottlenecks?

Thank you!

Blockchain stops working with 3 nodes using a stream with 2M transactions

Thu, 07 Mar 2019 16:26:18 +0000

I have the following scenario:

1 node that created the blockchain and a stream, which I used to create a stream and add 2M items into it, with random off-chain content (images).
2 nodes that join the blockchain after all the data has been imported through the master node, so on startup they begin to catch up with the master node at their own pace.

At the very beginning when the 2 new joined nodes are initially catching up, I can issue commands to any of the 3 nodes using the multichain-cli tool. For instance, I send this command to the master node and I get the reply back immediately:

multichain-cli ipregister -rpcuser=multichainrpc -rpcpassword=m4lt1ch41nRpC! getaddresses
{"method":"getaddresses","params":[],"id":"85616894-1551974478","chain_name":"ipregister"}
[
"1WTvECnAdMgvXDqMDQeiwXExCfvvMuHwq1HR7S"
]

However, at some point in time, when the volume of data being already synced up grows, the multichain-cli tool stops responding for all the nodes, and as the volume of synced data still grows, the nodes start to degrade dramatically until they just do not respond to commands.

Both 2 nodes join the blockchain through the DNS name of the master and they just subscribe to the stream to be able to find data by key, that's all.

Then I stop everything (without deleting the data) and restart first the master node. It starts to respond again to multichain-cli commands. But when I start again the first of the 2 additional nodes, I start getting this from it:

Node started
mchn: Sending minimal parameter set to 174.16.60.237:8099
receive version message: /MultiChain:0.2.0.6/: version 70002, blocks=28632, us=174.16.138.178:50952, peer=1
Added time data, samples 2, offset +0 (+0 minutes)
mchn: Parameter set from peer=1 verified
Loading addresses from DNS seeds (could take a while)
0 addresses found from DNS seeds
dnsseed thread exit
socket sending timeout: 61s

And then in the master:

Sending minimal parameter set to 174.16.138.178:50952
receive version message: /MultiChain:0.2.0.6/: version 70002, blocks=28627, us=174.16.60.237:8099, peer=7
Added time data, samples 3, offset +0 (+0 minutes)
mchn: Parameter set from peer=7 verified
ResendWalletTransactions()
Sending minimal parameter set to 174.16.138.178:8099
receive version message: /MultiChain:0.2.0.6/: version 70002, blocks=28627, us=174.16.60.237:58276, peer=12
mchn: Parameter set from peer=12 verified

Clearly, the 2nd node degrades just after joining again the blockchain. If I join the 3rd node it gets even worse.

How to properly test transactions throughput?

Fri, 01 Mar 2019 18:25:11 +0000

Hello,

I’d like to test transactions throughput.

My idea was:

only one node
only one address involved
only one asset issued
make n transactions (calls to sendasset(); one unit sent)

I am using python 3.7 and Savoir. I take the time used to make n transactions, thus the average time per transaction and finally the transactions per second.

I tested on different machines (with n = 100, 1000, 10000) and I don’t get good results when comparing to these: https://www.multichain.com/blog/2017/06/multichain-1-beta-2-roadmap/ .

In particular, with n=10000, I get ~11 TX/s. Am I doing something wrong? Is my machine not good enough (Intel Core i7 2600 @ 3.40 GHz with 8 gigabytes of ram)?

Also, are there any initial blockchain parameters that could influence the throughput so much?

Thank you very much.

Performance impact depending on the number of miners

Mon, 11 Feb 2019 12:34:11 +0000

Hi,

We are currently implementing a private blockchain that has initially 15 nodes as miners. If we increase the number of miners, would this have a significant impact on the a.) confirmation time of a transaction, b.) and the propagation time of committed blocks across the blockchain network.

I am new to the blockchain technology so I would like to understand how exactly the number of miners impacts the blockchain network.

Thank you!

Why is wallet folder size large in contrast to blocks folder?

Fri, 21 Dec 2018 13:26:32 +0000

Hello,

We are running tests to determine per-node storage requirements with:

- 2 Nodes

- Publishing items (key-values) to a stream (Not Subscribed)

Observations:

Change in file size after publishing 1 item to a stream in 1 block
Change in size of ./Blocks folder	3409 bytes
Change in size of ./Wallet folder	4492 bytes

Change in file size after publishing 10 items to a stream in 1 block
Change in size of ./Blocks folder	3839 bytes
Change in size of ./Wallet folder	18576 bytes

Change in file size after publishing 100 items to a stream in 1 block
Change in size of ./Blocks folder	7732 bytes
Change in size of ./Wallet folder	187561 bytes

Note: Publishing one item corresponds to one transaction on-chain.

Questions:

Q1: Why does the node wallet that created the item store such large amount of data in contrast to blocks folder? Even though we have not subscribed to the stream!

Q2: Does Multichain have an option of not storing transactions in wallet? (This is because we are indexing and keeping the reference to on-chain transactions in an external off-chain database)

Thank you !

How to achieve highest TPS for simple asset transfer?

Thu, 06 Dec 2018 18:45:20 +0000

We are using 2 VMs having t3.xlarge( 4 vCPU core, 16 Gib RAM, 2.5 GHZ processor) configuration.

We are sending asset from admin node to other peer node for a constant span with "sendfromaddress" API.

Please let us know whether we need to vary default blockchain parameters and what will be the number of users per node to attain 1000Tx/second.

Multichain in-node wallet adresses performance

Fri, 16 Nov 2018 15:00:29 +0000

Hello,

We are currently developing an application in Python (Django) using Multichain to control all the transaction and currency related user information.

The transactions we make are pretty simple: getnewaddress, grant, issuemore, getaddressbalances and sendassetfrom. Everything is working fine, however, we have experienced a serious slow down in the response time when increasing the number of adresses in the chain.

To give some numbers we have developed a set of unit tests with the basic functionality of the application:

Tests completion time without multichain implementation: 80s-100s
Tests completion time with multichain implemented and 1000 adresses in the wallet: 120s-150s
Tests completion time with multichain implemented and 60k adresses in the wallet: 800s-1000s

Note that these are the same tests just varying the amount of adresses in the wallet.

Right now we just have one node with all the addresses. What's the maximum addresses a node can hold without degrading its performance? Is it the same as if the adresses were watch only (no private keys in the node)? What's the right architecture to support massive numbers of addresses?

Thank you very much for your time.

IssueFrom and Publish performance as asset number grows

Tue, 10 Jul 2018 15:13:50 +0000

I've noticed the performance of both the IssueFrom and Publish calls degrade significantly as the number of assets on the chain grows, even at relatively small numbers.

I found that the first issue command took 4ms, but the 10,000th issuance took over 100ms

My setup is a Node JS app and chain(single node) spun up with docker-compose.

Multichain version is 1.0.5.

I have been using the multichain-node library but also tried my own code to directly talk to the chain. There wasn't much performance difference (my own code was actually a bit slower).

Apologies for the code snippet below but is there something I'm doing wrong? Any help would be appreciated.

async function issue(counter) {
  const assetId = uuid.v4().replace(/-/g, '');
  const metadata = {
    streamId: `streamId-${counter}`,
    cData: `c-${counter}`,
    lData: `l-${counter}`,
    sData: `s-${counter}`,
    mData: `m-${counter}`,
    dateCreated: new Date().toString(),
  };

  const body = JSON.stringify({ jsonrpc: '1.0', id: 'curltest', method: 'issuefrom', params: [MY_ADDRESS, MY_ADDRESS, assetId, 1, 1, 0, metadata] });

  const url = `http://${multichainHost}:8571`;
  const options = {
    url,
    method: 'POST',
    headers:
    {
      'content-type': 'text/plain',
    },
    auth: {
      user: 'user',
      pass: `${multichainPassword}`,
    },
    body,
  };

  const start = now();
  const response = await rp(options);
  const end = now();
  const duration = (end - start).toFixed(1);
  console.log(`${counter}, ${duration}`);
  return response.body;
}

async function directTest() {
  const nToCreate = 10000;
  for (let i = 0; i < nToCreate; i += 1) {
    await issue(i);
  }
}

how many streams can be created and subscribed by a node without affecting performance

Fri, 25 May 2018 06:03:51 +0000

Hi Multichain Team,

At this moment i have around 1000 stream and all the stream are subscribed by my node.could you please give me an rough idea about how long can these number be.

Performance of importwallet

Thu, 03 May 2018 08:44:19 +0000

Hi.

I am working on HA cluster at the moment:

1. two servers (master / slave) are connected and start with the same wallet.dat

2. master checks periodically if result of dumpwallet has changed

3. if true master sends dump to slave

4. slave does an "importwallet"

The problem here is that importwallet rescans the complete blockchain.
Rescanning all blocks seems to be quite slow and the multichain rpc is not responding in this period of time.

For example:

- 60GB blocks folder
- importwallet with one new privatekey runs since 2h and is still running
- machine is ec2 m5.xlarge
- rpc is not responsive

here is the debug.log output

2018-05-03 07:03:26 Skipping import of 1CNpcJb2xBQ15LgNQCKjFBYAZGXabMXXuHZTrh (key already present)
2018-05-03 07:03:26 Skipping import of 19uWPgKbkn4uGBuf3RQFgpUL71XWoghzAgnMJj (key already present)
2018-05-03 07:03:26 Importing 1TaY4J9DsfMBcbY8mTusciKJfnTgD5G1RD3x2c...
2018-05-03 07:03:26 Skipping import of 177Myj4T8aqYrJJ6ZrDP6md85GLzu7g9BYYRYm (key already present)
2018-05-03 07:03:26 Rescanning all 50954 blocks
2018-05-03 08:25:16 Still rescanning. At block 1. Progress=1.000000
2018-05-03 08:26:48 Still rescanning. At block 15. Progress=1.000000
2018-05-03 08:27:57 Still rescanning. At block 30. Progress=1.000000
2018-05-03 08:29:16 Still rescanning. At block 32. Progress=1.000000
2018-05-03 08:31:06 Still rescanning. At block 35. Progress=1.000000

First of all it took nearly 1,5h to actually start scanning. (?)
Then it seems like it needs 10 seconds to scan one single block. (Maybe this is ok since there are about 5000 transactions in a single block).
So it would take nearly a week to rescan all 55000 blocks.

My problem is that a cannot use importprivkey with rescan=false, since I do not know if this address has already been used. That's because I only sync the wallet periodically. I am also not able to intercept calls like "getnewaddress".

Maybe an option could be that there is a parameter for importwallet (and also importprivkey) that tells multichain how far in the past it should search for an address transaction.

e.g. if I do an hourly sync, only the last e.g. 500 blocks must be rescanned for the new address.
(I also have a timestamp information in the dumpwallet file itself)

for example:

importwallet dump.dat 500
to rescan the last 500 blocks for all new addresses

or
importprivkey ABC123 true 500
to rescan last 500 blocks for key ABC123
(but even this would still take over an hour)

But having a cluster with a HA node that takes about 6 days to catch up with a single address is quite bad.

Same holds true for backup and restore. If after a server crash I need to restore the blockchain, it seems to be reasonable to reindex / rescan the restored chain. But this also shouldn't take a week.

In general I am a little bit concerned to hopefully never be forced to do a reindex / rescan on a huge blockchain, since this would take several days to be operational again.

Do you have similar experiences?

Maximum number of assets and streams per node performance-wise

Fri, 30 Mar 2018 02:17:08 +0000

Hi Multichain folks,

You have mentioned previously that the wallet on multichain can only track a few thousand addresses and their balances before performance starts to degrade.

Does the node wallet also keep track of assets and streams and how many assets and streams can it scale to while performing well?

rpckeepalive: performance drops vs port freeze

Wed, 14 Mar 2018 09:20:58 +0000

Hi,

is there any news on the rpc freeze problem?
https://www.multichain.com/qa/7006/node-rpc-completely-freezes-rpcssl?show=7178#a7178

What I still experience (v1.0.4):
Everything works fine using rpckeepalive=0 but there is another problem:

The performance (tx/s) decreases a lot when using rpckeepalive=0
I only get ~ 100 tx/s throughput when using rpckeepalive=0 (and rpcssl).

If I enable rpckeepalive I get ~800 tx/s (!)
But still the rpc api freezes after some time.

I think the problem only appears when using it together with rpcssl because every new requests has to open a new connection and has to do the ssl handshake all over again.

So:
keepalive=0 has a really bad performance (at least when using rpcssl?)
keepalive=1 freezes the node on high load after no more than 30 seconds.

Performance impact as number of Nodes in Blockchain increase

Mon, 12 Mar 2018 09:53:53 +0000

Hi

We are trying to implement a private blockchain starting with 10 nodes. Going forward we want to expand it to hundreds of nodes.

In our blockchain we want to credit points to user account based on certain action. This has to happen in near real time hence we have performance as one of the most important criteria for selecting blockchain platform.

I understand multichain based blockchain can do around 1000 TPS.

However as we know every commited block in blockchain has to be replicated to all nodes in blockchain network. So if the number of nodes in network increase it would add more latency due to increased number of nodes.

Is this understanding correct? If yes how TPS is affected with increased number of nodes.

Watch-only address limit.

Wed, 29 Nov 2017 12:14:17 +0000

Hi team,

Do you guys already have a benchmark done on how much performance can deteriorate with increasing number of watch-only address? Also how much memory one watch-only address or an UTXO would utilize.

Also is it feasible to keep 100k watch-only addresses in a node? or we need to apply some logic like sharding to distribute the addresses if there a a case of needed 100k or even more addresses. If this has to be done to rebalance nodes, is un-watching a address feasible ?

Thanks!

Regards,

Ashish

Performance tests: disk space distribution in mc folder

Fri, 24 Nov 2017 13:12:34 +0000

Hi.

At the moment we are running some performance tests:

- 4 Nodes

- write random key-values in root stream.

Now the disk usage is at 8 GB and I am interested in an explanation of the following information:

5.3M    ./permissions.db
4.1G    ./wallet/txs.db
7.1G    ./wallet
480K    ./entities.db
272K    ./database
208K    ./chainstate
183M    ./blocks/index
1.9G    ./blocks
8.9G    .
8.9G    total

I would assume to find the most data in /blocks but obviously it is in wallet / wallet.tx.

Can you explain what exactly is stored there and why it takes that much space compared to the /blocks folder?

Thanks,

Alex

Core switching

Tue, 21 Nov 2017 07:09:48 +0000

Hey team,

Does multichain utilizes multiple cores or it runs only on one core and relies on OS for core switching?

I 've a 2 core c4.large instance and no matter how much load I put on the multichain the CPU utilization caps at 50%. It never exceeds the 50% mark. So if I 've a 4 core system my 3 cores would lie idle?

Thanks,

Ashish

Multichain rpc server connection question (performance)

Thu, 21 Sep 2017 19:05:05 +0000

At the moment I am evaluating multichain performance measuring stuff like, network sync times, Max tx/s in a multi-node network ~ 20 Nodes, also on different locations.

A first step was to check the performance of a single node over the internet in regards to [tx/sec].

When there is a high load I observed an error on the operating system level (Ubuntu) that says too many open files. So it seems, that on high rpc request load the ulimit is fully used up, but this should not happen in my opinion.

How are connections handled on the internal rpc server? Is there some keep-alive or a too high connection timeout? It seems that rpc requests that opened a connection don't get closed immediately and at some point use up all the resources. Of course I could increase the "ulimit -n" but I just wanted to check if this could be a possible optimization on multichain side.

Would it help if the client that send the rpc-requests set the header "Connection: close"?

Better approach to retrieve data from streams

Tue, 02 May 2017 11:01:17 +0000

Hello Multichain team,

I have made a small program to retrieve data under a specific key. I have more than 90 keys each having 13,500 values stored under them.

When I try to retrieve all the values under any key, it takes around 1.5 seconds to 2.5 seconds.

Here is my code :

import subprocess, json

path = "/home/user/multichain-1.0-beta-1/multichain-cli"
id = "1493517600"
max_entries= "100000"
output = subprocess.check_output([path, "chain2", "liststreamkeyitems", "b", id, "false", max_entries]).decode("utf-8")

Is there any better way to improve it / another way to do it to be faster ?

Also, is it possible to retrieve only one value under a key by searching data inside that value ?

Data size for streams

Fri, 24 Feb 2017 17:10:34 +0000

Hi Multichain Team,

How much data size streams can handle? Can it handle millions of records (which means giga bytes of data) like a database can?

Thanks.

Publish Rate for streams

Fri, 24 Feb 2017 17:07:53 +0000

Hi Multichain Team,

Can you please tell us how many transactions we can do per second if we are using streams? I mean how fast can we publish for which we will get a good performance.

Performance Streams &. Key-Value

Fri, 03 Feb 2017 07:27:02 +0000

1. What is more performant (regarding r/w access time):

a) Creating a lot of Streams with several keys

b) Creating several Streams with a lot of keys

2. Are there measurements how the stream concept performs regarding numer of streams, number of key-value pairs?

Greetings

Performances benchmark

Thu, 19 Jan 2017 10:04:59 +0000

Hi guys,

I have not found a recent performances benchmark.

Is there one somewhere ? I have read that the new wallet was tremendously more efficient, and that multichain engine is able to handle millions of assets, but are there somewhere some performances reports, graphs?

I'm especially interested in benchmarks with a lot of assets, lot of transactions of course, and also measurement of the underlying DB volume space.

Our local tests show that with a 4 node cluster doing nothing (so 1 empty transaction every 15s) the .multichain folder is growing by ~80 MB a week, is this expected ? is there a way to reduce this volume (i mean something different than making the empty transaction occurs less often ;-) since the problem here is more the transactions/db volume ratio than the volume of the db when the node is doing nothing).

I understand that the volume of the db depends on the number of transactions, and the metadata size contained in the transactions/stream items (among other things), but the simple test of an idle cluster is showing us that the db is growing fast.

For example, if a node doesn't subscribe to a stream, will its DB volume grow the same way than if it has subscribed ?

thanks a lot for any information about this performances/db volume benchmarks.

cheers,

Sebastien

Performance measurement for Multichain streams

Sun, 15 Jan 2017 14:08:30 +0000

Hi,

Do you have any performance measurement for the use of Multichain stream as a nosql database?

R.

Network throughput computation

Thu, 27 Oct 2016 19:53:40 +0000

Hi,

I am interested in how the general network throughput of multichain can be computed (how you guys did it in "http://www.multichain.com/blog/2016/07/announcing-the-new-multichain-wallet/" quoting 200 to 800 tx/sec).

Thanks

R.

Throughput Issue with Streams

Tue, 25 Oct 2016 15:39:45 +0000

Hi,

1. Summary: Throughput of 'publish' is ~5.96 ops/s. Is this expected?

2. System configuration
Machine: Windows 7, Desktop, 12 hyper-threaded cores, 16GB RAM, SSD drive
Multichain: 1.0-alpha-24
Client: Java 1.8.0_91, Vert.x

3. Operation Steps (pseudo code)

3.1 Warmup
create stream "accounts" true
for (i from 1 to 10) {

  account = "account-" + i
  when(publish "accounts" account hex("active")).then(publish "accounts" account hex("inactive")
}

All calls to 'publish' are performed concurrently.

3.2 Run
for (i from 11 to 1000) {

  account = "account-" + i

  when(publish "accounts" "account-"+i hex("some data")).then(publish "accounts" account hex("inactive")
}

All calls to 'publish' to create "accounts" are carried out asynchronously and concurrently.

We measure the duration for each 'publish'.

4. Result
mean-time: 5.96 ops/second

Is this expected? Seems rather slow.

kind regards,

farzad

Performance data

Fri, 21 Oct 2016 11:14:39 +0000

Hi,

Please how can I compute some blockchain performance and scalability results like number of transactions per seconds etc. or do you have this documented somewhere?

Thanks.

R.

Long transactions performance

Mon, 13 Jun 2016 16:46:54 +0000

We have the Multichain configured to support native currency. Some transfer transaction takes a long time to execute. We think that the reason is the fragmented wallet for the account because of the mining rewards. In fact I need to increase transaction and block limits to avoid 'transaction too long' error.

CTransaction(hash=ef32615102, ver=1, vin.size=978, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(0001800122, 0), scriptSig=3045022100a9c6bb6f7aa9f9)
    CTxIn(COutPoint(005774ffe0, 0), scriptSig=3045022100cdad08e9253d40)
....
    CTxIn(COutPoint(ffc8ca487c, 0), scriptSig=3045022100d3d003a63c5a5d)
    CTxIn(COutPoint(fff759534e, 0), scriptSig=304402207532997f738e1735)
    CTxOut(nValue=1.00000000, scriptPubKey=OP_DUP OP_HASH160 f8732cf97b91)
    CTxOut(nValue=0.00008618, scriptPubKey=OP_DUP OP_HASH160 62525c7cfc25)

But my question is, does not autocombine feature works in background to avoid this? Is it enabled by default? What is not working in my configuration?

Anyway I try to execute by hand: combineunspet in multchain-cli, and I get this error:

mincoins: combineunspent
{"method":"combineunspent","params":[],"id":1,"chain_name":"mincoins"}

error code: -4
error message:
Not enough inputs

Thanks a lot,

Fernando

High transaction volumes

Wed, 09 Sep 2015 13:24:18 +0000

How well will multichain scale in terms of transactions per second when configured for high volume transaction solutions?