The Hyperledger on paper states that it supports 3500 transactions per second
But what is the time it takes to commit/execute one transaction?
is it equal to one block time?
can we use Hyperledger for a realtime application that needs a transaction to be done within 100 ms?
3500 transactions per second means that on average, 3500 transactions were created by some clients and then appeared in some next newly created block within one second.
It can be that several blocks were created in that second.
You can't use Fabric, or any other consensus mechanism that uses IP networks for a real time application, simply because that if the network transmission can be delayed for more than 100ms.
You can, however - make the consensus service in Fabric use low batch timeouts (say, of 10ms) and then blocks would be formed on a frequent basis and you'll have a transaction latency less than 100ms on average.
Related
If selected OrdererType: etcdraft, then is it must to have odd no. of orderers ?, referred to the following hyperldger fabric documentation but not found anything specific on that?
https://hyperledger-fabric.readthedocs.io/en/release-2.2/raft_configuration.html
Consenters:
- Host: raft0.example.com
Port: 7050
ClientTLSCert: path/to/ClientTLSCert0
ServerTLSCert: path/to/ServerTLSCert0
- Host: raft1.example.com
Port: 7050
ClientTLSCert: path/to/ClientTLSCert1
ServerTLSCert: path/to/ServerTLSCert1
Hyperledger Fabric wrote many pages on the documentation about RAFT, but not specifically shared a single example with raft and without a raft, not shared the word: "distributed consensus", saw hundreds of technical articles where the demonstration was done to run X orderers, but when you work on real problems then the real Q comes, how many orderers you may need? (sure all depends on the problem you working on)
Found following reference on this topic :
Reference: https://lists.hyperledger.org/g/fabric/topic/71083347
While it's possible to use the console to build a configuration of any
number of ordering nodes (no configuration is explicitly restricted),
some numbers provide a better balance between cost and performance
than others. The reason for this lies in satisfying the needs of high
availability (HA) and in understanding the Raft concept of the
"quorum", the minimum number of nodes that must be available (out of
the total number) for the ordering service to process transactions.
In Raft, a majority of the total number of nodes is needed to form a
quorum. In other words, if you have one node, you need that node
available to have a quorum, because the majority of one is one.
Similarly, if you have two nodes, you will need both available, since
the majority of two is two (for this reason, a configuration of two
nodes is discouraged; there is no advantage to a two node
configuration). In a similar vein, the majority of three is two, the
majority of four is three, the majority of five is three, and so on.
While satisfying the quorum will make sure the ordering service is
functioning, production networks also have to think about deployment
configurations that are highly available (in other words,
configurations in which the loss of a certain number of nodes can be
tolerated by the system). Typically, this means tolerating two nodes
failing: one node going down during a normal maintenance cycle, and
another going down for any other reason (such as a power outage or
error). This is why five nodes is a good number for a production
network. Recall that the majority of five is three. This means that in
a five node configuration, the loss of two nodes can be tolerated. If
your configuration features four nodes, only one node can be down for
any reason before another node going down means a quorum has been lost
and the ordering service will stop processing transactions.
Also did a few experiments e.g.
with 1 orderer
with 2 orderers
and it worked.
But even after doing the above, I got an idea that system is working with 1 orderer and 2 orderers or .., but not actually cleared like why we really need 5 to start with.
Possibly start with 1 orderer, and see the complexity of Txns, if we have multiple client applications and those reaching to blockchain network via multiple peers, submitting complex Txn proposals and then it may require 1+X orderers, but yes we have to see what problematic Txns we have. We may not require distributed consensus all time, so not many orderers.
As per latest (Fabric 2.x) documentation, it is recommended to deploy at least three and optimally five nodes in an ordering service.
wherever you choose to deploy your components, you will need to make sure you have enough resources for the components to run effectively. The sizes you need will largely depend on your use case. If you plan to join a single peer to several high volume channels, it will need much more CPU and memory than if you only plan to join to a single channel. As a rough estimate, plan to dedicate approximately three times the resources to a peer as you plan to allocate to a single ordering node (as you will see below, it is recommended to deploy at least three and optimally five nodes in an ordering service). Similarly, you should need approximately a tenth of the resources for a CA as you will for a peer. You will also need to add storage to your cluster (some cloud providers may provide storage) as you cannot configure Persistent Volumes and Persistent Volume Claims without storage being set up with your cloud provider first. The use of persistent storage ensures that data such as MSPs, ledgers, and installed chaincodes are not stored on the container filesystem, preventing them from being destroyed if the containers are destroyed.
I have a durable functions app, running on a premium elastic service plan in Azure, wherein I
(a) perform a one off task that returns a potentially large number of results
(b) run some independent processing on each result from part (a)
Part (a) relies on an external database, which starts rejecting requests when I hit a certain number of concurrent requests.
Part (b) doesn't have such a third party dependency, and should theoretically be able to scale indefinitely.
I'm aware of the ability to place limits on:
The maxmimum number of instances my service plan will scale out to
The number of concurrent requests per-instance
The number of concurrent activity functions
However, using any of these options to limit (a) would also limit (b), which I'd like to leave as concurrent as possible.
Is there a way I can limit the number of concurrent invocations of activity function (a), without placing restrictions on the number of invocations of (b)?
(If all else fails I can track the number of current executions myself in storage as part of running activity (a), but I'd much prefer to either configure this, or be able to drive it from the durable functions framework, if possible - as it is already tracking the number of queued activity functions of each type.)
Is there a way I can limit the number of concurrent invocations of activity function (a), without placing restrictions on the number of invocations of (b)?
Yes, there are plenty of tools in Azure which will allow you to build publish / subscribe segregation of (a) and (b). Perhaps the mistake here is to think that the results from (a) need to be processed in-process / synchronously with the consumer which sinks / processes these results.
i.e. If there is a good chance that (b) cannot keep up with the messages retrieved from (a), then I would consider separating the task of obtaining data from (a) from the task of processing the data in (b) via a queue or log technology.
Concentrating on (b):
If (b) requires command or transaction semantics (i.e. exactly once, guaranteed), then Azure Service Bus can be used to queue commands until they can be processed, and consumers of messages can be scaled independently of the production of messages in (a), using subscriptions. Think RabbitMQ.
If (b) can handle less reliable guarantees, e.g. at-least-once semantics, then Azure Event Hubs will allow you to partition messages across multiple concurrent consumers. Think Kafka.
Other alternatives exist too, e.g. Storage queues (low cost) and Event grids (wide number of subscriber protocols).
So TL;DR, buffer the accumulation of data from the processing, if you fear that there are throughput disparities between your ability to acquire and process the data.
Interestingly enough, if the process delivering to (a) IS a queue in itself, then you need only concern yourself with the performance of (b). The golden rule of queues is to leave data on the queue if you do not have the capacity to process it (since you will just need to buffer it, again).
Can someone answer?
what is the failover time if a node goes down, I did see it take 2 to 3 seconds but do we have control to make it faster than this? if yes how much. Typically, we cannot take this hit on the application queue it is that sensitive.
In YugabyteDB, tables are shared into tablets, and tablets are replicated among nodes using Raft (a distributed consensus protocol). Raft is also used to elect, for each tablet, one of the tablet's peers as the leader.
In a typical situation, a node will have many tablets-- some in follower role, and some in leader role. When a node fails, tablets for which this node is a leader can have a small amount of unavailability until new leaders are elected for those tablets. (Note: YugabyteDB is a CP database). This leader (re)election is triggered when the followers of a tablet have not heard from their leader for a certain number of heartbeats. The knobs that govern this, and hence determine the failover time, are the following gflags:
raft_heartbeat_interval_ms (default 500ms)
leader_failure_max_missed_heartbeat_periods (6)
In other words, by default, if a follower doesn't hear for 6 heartbeats from the leader, then after 6 * ~500 ms (the default heartbeat interval), i.e. about 3 seconds, new leaders will get elected.
It is possible to override the above settings to reduce the failover time. However, care must be exercised to not make this too aggressive, as that can cause leaders to unnecessarily ping/pong even for small network hiccups.
NOTE: This question is framed in the context of a private network where the business network operator owns and manages all the nodes on the network as a service and only provides access via a REST API or a web gui.
Assuming that the application is mostly batch based and not real time, is it possible to run nodes in bursts so that they start once an hour, process any transactions and then shut down again when the processing is complete?
Or maybe have a trigger that starts up the node automatically when it is needed.
Azure has per second billing which has the potential to drastically reduce infrastructure costs.
Generally speaking this wouldn't be possible. You can think of nodes being like email servers -- You never know when an email (ie a transaction for a Node) comes in, so they have to be online all the time.
However if you control all nodes on the network, you could build a queuing system outside of Corda, once an hour spin up all the nodes on the network, and then process your own queue by sending the transactions then.
This would be likely to become tricky once you have other entities you don't control on the network though. You could also run the nodes on the smallest possible instances on Azure and keep the cost down that way?
The Azure Event Hubs overview article states the following:
The number of partitions is specified at the Event Hub creation time
and must be between 8 and 32. Partitions are a data organization
mechanism and are more related to the degree of downstream parallelism
required in consuming applications than to Event Hubs throughput. This
makes the choice of the number of partitions in an Event Hub directly
related to the number of concurrent readers you expect to have. After
Event Hub creation, the partition count is not changeable; you should
consider this number in terms of long-term expected scale. You can
increase the 32 partition limit by contacting the Azure Service Bus
team.
Since you cannot change the number of partitions on your event hub after initial creation, why not just always configure it to the maximum number of partitions, 32? I do not see any pricing implications in doing this. Is there some performance trade off?
Also, as another side note, I appear to be able to create an event hub with less than 8 partitions. The article says it must be between 8-32. Not sure why it says that...
Its my understanding that each partition requires its own consumer. You could do this via multi-threading on a single process, multiple processes, or even via multipage machines each running a process. But this comes with a degree of complexity. Either the management of all the processes to ensure that all partitions are being consumed, or for synchronizing items/events that span partitions.
So the implicates are less about pricing then they are about scalability/complexity. :)