App Install
Measure app installation speed. This scenario has two roles:
minimal: Installs a simple app which implements initialisation callbacks but otherwise doesn't contain a lot of code.large: Installs a larger app that contains some dependencies and some generated data as padding to make the bundle larger.
These are intended to catch a compilation slowdown or issues with copying around large WASMs (e.g. accidental cloning or tracing). In each case, the behaviour will uninstall the app it installed so that it can re-install it on the next iteration.
-
large(1 agent)
Warning Memory growing at 981.42 MB/s
Additional Host Metrics
//efi-boot/nix/storeDHT Sync Lag
Measure lag time between an agent publishing data and other peers being able to see it. This scenario has two roles:
write: A simple job that just creates entries with a timestamp field. Those entries are linked to a known base hash. For each write, the metricws.custom.dht_sync_sent_countis incremented.record_lag: A job that repeatedly queries for links from the known base hash. It keeps track of records that it has seen and when a new record is found, and calculates the time difference between the timestamp of the new record and the current time. That time difference is then recorded as a custom metric calledwt.custom.dht_sync_lag.
After each behaviour loop the metric ws.custom.dht_sync_recv_count is incremented.
-
record_lag(1 agent) -
write(1 agent)
post_commit durationWarning CPU p99 reached 98.2%
Warning Memory growing at 178.05 MB/s
Additional Host Metrics
//boot/efi-boot/etc/hostname/etc/hosts/etc/resolv.conf/nix/storeFirst Call
This scenario installs a simple app which implements the init callback, and measures the time elapsed between start of install and calling init. It will uninstall the app it installed so that it can re-install it on the next iteration. This is required to re-run the initialisation callback.
-
default(1 agent)
init.Warning Memory growing at 145.57 MB/s
Warning Moderate swap usage (11.5% swap used)
Additional Host Metrics
/etc/hostname/etc/hosts/etc/resolv.confFull-Arc Create (Validated) / Zero-Arc Read
A full-arc/zero-arc mixed scenario where full-arc nodes create data that gets validated and zero-arc nodes read the data. The scenario has two roles:
full: A full-arc conductor that creates entries with a timestamp field. Those entries get validated and then retrieved by zero-arc nodes.zero: A zero-arc conductor that reads the entries created by the full-arc node(s) and records the time lag between when the entry had been created and when it was first discovered.
-
full(1 agent) -
zero(1 agent)
Local Signals
This scenario is for testing the speed and reliability of local signals. It uses a zome with a function that will emit 10,000 signals. The scenario measures how long it takes to send the signals and how many have been received by the time the zome call ends.
-
default(1 agent)
Warning Memory growing at 21.01 MB/s
Additional Host Metrics
/etc/hostname/etc/hosts/etc/resolv.confRemote Call Rate
Test the throughput of remote_call operations. Each agent in this scenario waits for a certain number of peers to be available or for up to two minutes, whichever happens first, before starting its behaviour.
-
default(1 agent)
Warning Memory growing at 35.91 MB/s
Warning Moderate swap usage (11.5% swap used)
Additional Host Metrics
/etc/hostname/etc/hosts/etc/resolv.confRemote Signals
This scenario tests the throughput of remote_signals operations.
-
default(1 agent)
Additional Host Metrics
//efi-boot/nix/storeSingle-write, many-read
Creates an entry in the agent setup, then read one's own record back. This tests the maximum read performance for reading back local data when the chain is short.
-
default(1 agent)
read call timingread call rateWarning Memory growing at 117.37 MB/s
Additional Host Metrics
//efi-boot/nix/storeTwo-party countersigning
This scenario tests the performance of countersigning operations. There are two roles: initiate and participate. The participants commit an entry to advertise that they are willing to participate in sessions. They listen for sessions and participate in one at a time.
-
initiate(1 agent) -
participate(1 agent)
Warning Memory growing at 622.59 MB/s
Additional Host Metrics
//efi-boot/nix/storeValidation Receipts
Creates an entry, wait for required validation receipts, then repeat. Records the amount of time it took to accumulate the required number of receipts for all DHT operations. This is measured to the nearest 20ms so that we don't keep the agent too busy checking for receipts.
Each agent in this scenario waits for a certain number of peers to be available or for up to two minutes, whichever happens first, before starting its behaviour.
By default, this scenario will wait for a complete set of validation receipts before committing the next record. If the NO_VALIDATION_COMPLETE environment variable is set, it will instead publish new records on every round, building up an ever-growing list of action hashes to check on.
-
default(1 agent)
Warning CPU p99 reached 99.9%
Warning Memory growing at 603.92 MB/s
Additional Host Metrics
//efi-boot/etc/hostname/etc/hosts/etc/resolv.conf/nix/storeWrite/get_agent_activity
A scenario where write peers write entries, while get_agent_activity peers each query a single write agent's activity with get_agent_activity.
Before a target write peer and the requesting get_agent_activity peer are in sync, this will measure the get_agent_activity call performance over a network. Once a write peer reaches sync with a get_agent_activity peer, the write peer will publish their actions and entries, and so the get_agent_activity calls will likely have most of the data they need locally. At that point this measures the database query performance and code paths through host functions.
-
get_agent_activity(1 agent) -
write(1 agent)
get_agent_activity_full zome call timingwrite peer's source chain.Warning Memory growing at 760.18 MB/s
Additional Host Metrics
/etc/hostname/etc/hosts/etc/resolv.confWrite/get_agent_activity with volatile conductors
A scenario where write peers write entries, while get_agent_activity_volatile peers each query a single write agents activity with get_agent_activity but shutdown and restart their conductors at semi-random intervals.
Before a target write peer and the requesting get_agent_activity_volatile peer are in sync, this will measure the get_agent_activity call performance over a network. Once a write peer reaches sync with a get_agent_activity peer, the write peer will publish their actions and entries, and so the get_agent_activity calls will likely have most of the data they need locally. At that point this measures the database query performance and code paths through host functions.
-
get_agent_activity_volatile(1 agent) -
write(1 agent)
action_seqget_agent_activity. This reflects the DHT's ability to propagate agent activity ops and make them available to querying peers.get_agent_activity_full zome call timingwrite peer's source chain.get_agent_activity_volatile peers.get_agent_activity_volatile conductor.get_agent_activity_volatile conductor was running before being stopped.get_agent_activity_volatile conductor was stopped before being started again.get_agent_activity_volatile peer reach their target arc in the moment before they were shutdown.get_agent_activity_volatile_agent:uhCAk3njXkxLdA4ScgMH1HPoGnBSg7MvVN6UsCWpSrk67W7kr3rJr
get_agent_activity_volatile_agent:uhCAkHCjA-cXZEG9onoF6SpUec5Z1z8DzjH_AU6n3Wq_exk30IwX2
get_agent_activity_volatile_agent:uhCAkIh0dwKx3IzzF1w4azIiNMAMZTx1pGxLH-yuC7QmcCFDTNJid
get_agent_activity_volatile_agent:uhCAkIpzItDgetli49r3x4P1p1bI4dTgKUPwzq7TjeB0U58d78cUv
get_agent_activity_volatile_agent:uhCAkRgYpfGiss6PyY2-ENpi5KgIv9SPQ3DjpJyEsQzqstOMjQ61Y
get_agent_activity_volatile_agent:uhCAkWPliPW_j8K5tTafbmMfI85emPCl3oILNbyqoChSW7U7FuRdG
get_agent_activity_volatile_agent:uhCAkaLiC93543hwg4uJvcsaY7SQ4wxW5fYIFSYKh3jjc1eX0av3I
get_agent_activity_volatile_agent:uhCAkdFTj9g1GzfeoTOThdrJW2UJYde5iIJCH9WDZrLQGYkZUskIj
get_agent_activity_volatile_agent:uhCAkgfJl7M5VWQXz0boRvtzjfNRv3LDkbQbqzhTpaauC3HdnXh3y
get_agent_activity_volatile_agent:uhCAkgtdtFCCNuhobZDrZ5FMhZb0SAz6krYXT3LPWym4vPdm4721T
get_agent_activity_volatile_agent:uhCAkoFiredHrNOW7dHngpY41J7eI0OHxWRPhYHiBzyiWF5goKH7p
get_agent_activity_volatile_agent:uhCAkudc9_pIcPJPd5zriaFNt4ZBgA7Qt1IlMxfR-7Z8j0ljfgtfs
get_agent_activity_volatile_agent:uhCAkx2251wsi5sd76unF9C2iUsv_mcIcY0V2_2bqywGEkuf3m9fM
get_agent_activity_volatile_agent:uhCAkxEqme9RZXaRo2QKtr_sFpMEv3DS0qMuzzLbvoaSZkAavGVbK
Write/Query
Creates an entry, then queries the source chain and performs a simple operation on the entries, then repeats.
-
default(1 agent)
chain_query_count_len zome call that queries the source chain.Warning Memory growing at 92.31 MB/s
Additional Host Metrics
//efi-boot/nix/storeWrite/Read
Creates an entry and reads it back, then repeats.
-
default(1 agent)
Warning CPU p99 reached 97.3%
Additional Host Metrics
/etc/hostname/etc/hosts/etc/resolv.confWrite validated
Creates an entry, updates it and links the create to the update, then repeats. Each of the three actions is validated by the included hApp.
-
default(1 agent)
Warning Memory growing at 46.86 MB/s
Additional Host Metrics
//efi-boot/nix/storeWrite Validated must_get_agent_activity
A scenario where write agents create entries in batches of 10, while must_get_agent_activity agents each pick a random write agent and repeatedly attempt to create an entry that references the chain top of their latest batch. This reference means that the entry's validation function needs to make a must_get_agent_activity call.
The purpose of this scenario is to measure the time it takes for published agent activity data to be gossiped among authorities and become available to peers that query it via must_get_agent_activity.
This test is similar to Mixed-Arc must_get_agent_activity, but all agents are full-arc.
-
must_get_agent_activity(1 agent) -
write(1 agent)
action_seqwrite agent, aggregated across all reading agents. The reading dimension is collapsed by taking the maximum observed value for each write agent (any successful read counts as propagation). This reflects the DHT’s ability to propagate agent activity ops and make them available to querying peers.write agent's creation of a batch and a must_get_agent_activity agent's successful discovery of the batch and creation/self-validation of a new entry that depends on it.must_get_agent_activity agent was able to discover batches and create/self-validate new entries that depend on them.create_validated_sample_entry zome call timingwrite agent's source chain.must_get_agent_activity calls.Warning Memory growing at 783.98 MB/s
Additional Host Metrics
//efi-boot/nix/storeZero-Arc Create and Read
A zero-arc/full-arc mixed scenario with two types of zero-arc nodes -- ones that create data and ones that read data -- as well as full arc nodes to "relay" the data. The scenario has three roles:
zero_write: A zero-arc conductor that just creates entries with a timestamp field. Those entries are linked to a known base hash so thatzero_readnodes can retrieve them.zero_read: A zero-arc conductor that reads the entries created by the zero-arc node(s) and records the time lag between when the entry had been created and when it was first discovered.full: A full-arc conductor that is just here to serve entries to zero arc nodes.
-
full(1 agent) -
zero_read(1 agent) -
zero_write(1 agent)
get_timed_entries_network zome function.Zero-Arc Create Data
zero: A zero-arc conductor that just creates entries with a timestamp field. Those entries are linked to a known base hash so that full-arc nodes can retrieve them.full: A full-arc conductor that reads the entries created by the zero-arc node(s) and records the time lag between when the entry had been created and when it was first discovered.
-
full(1 agent) -
zero(1 agent)
get_timed_local_entries zome function.Warning CPU p99 reached 93.8%
Warning Memory growing at 101.98 MB/s
Warning Moderate swap usage (19.8% swap used)
Warning 10% of hosts overloaded (load5/ncpus > 1.0)
Additional Host Metrics
//efi-boot/etc/hostname/etc/hosts/etc/resolv.conf/nix/storeZero-arc Create Data (Validated)
A zero-arc/full-arc mixed scenario where zero-arc nodes create data that gets validated and full-arc nodes read the data. The scenario has two roles:
zero: A zero-arc conductor that just creates entries with a timestamp field. Those entries are linked to a known base hash so that full-arc nodes can retrieve them.full: A full-arc conductor that reads the entries created by the zero-arc node(s) and records the time lag between when the entry had been created and when it was first discovered.
-
full(1 agent) -
zero(1 agent)
get_timed_local_entries zome function.Warning Memory growing at 702.38 MB/s
Additional Host Metrics
//efi-boot/etc/hostname/etc/hosts/etc/resolv.conf/nix/storeZome Call, Single Value
Calls a zome function that returns a fixed value. This tests the maximum performance of zome calls when the zome function is not calling into Holochain other otherwise doing any work.
-
default(1 agent)
Warning Memory growing at 75.42 MB/s
Additional Host Metrics
//efi-boot/nix/store