Throughput Issue with Streams

+1 vote
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
asked Oct 25, 2016 by anonymous

1 Answer

0 votes
That does seem slow. We know the Windows version is significantly slower than the Linux version, but I would not expect by that much. Are you able to try this on Linux to see if that's the issue?
answered Oct 25, 2016 by MultiChain
Thanks. I will do so (will take some time to get access to a server).
In the meantime, could you say anything about the concurrency characteristics of the current version of multichain, specifically the streams? e.g. are there any pessimistic synchronization points for activity such as creation of streams, keys? Would these impact read ops?

Thanks and kind regards,
Farzad
Unlike the network, the node itself does not currently have strong concurrency, for example the API uses a global lock. But even without that, you should be seeing 100 tx/sec for writing to streams, at a minimum.
Thanks.
I've got a server - however, rather low end. 2 Cores 2.7GHz.
My test suite carries out the steps described in my post, in iteration sizes starting at 200 and increasing by 100 up to 1000 concurrent requests.

 concurrent requests,mean duration (ms),mean_rate (ops/s)
 200, 1,724 , 55.72
 400, 3,521 , 54.63
 600, 5,243 , 54.67
 800, 7,140 , 52.90
 1,000 , 10,487 , 45.12
 1,200 , 11,228 , 49.52
 1,400 , 12,830 , 48.79
 1,600 , 15,411 , 46.68
 1,800 , 16,697 , 46.68
 2,000 , 19,692 , 44.94
So you're seeing 50+ ops/second? That is closer to what we would expect. Now try just 1 concurrent request?
...