commit ce9f808efed022550dfc7aa3e3e0d38ada4ca8d8
parent c3950e69366ea927e8fa7d562ced959ed875b39f
Author: Christian Grothoff <christian@grothoff.org>
Date: Sun, 16 Jul 2023 15:37:15 +0200
update description of taler-merchant-benchmark
Diffstat:
2 files changed, 39 insertions(+), 50 deletions(-)
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
@@ -2257,6 +2257,8 @@ some options that are determined at runtime by the setup logic provided by
``taler-unified-setup.sh``.
+.. _Benchmark-choose-bank:
+
Choosing a bank
---------------
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
@@ -1036,64 +1036,57 @@ The database scheme used by the merchant looks as follows:
Benchmarking
------------
-The merchant codebase offers the ``taler-merchant-benchmark`` tool to
-populate the database with fake payments. This tool is in charge of
-starting a merchant, exchange, and bank processes, and provides them all
-the input to accomplish payments. Note that each component will use its
-own configuration (as they would do in production).
+The merchant codebase offers the ``taler-merchant-benchmark`` tool to populate
+the database with fake payments. The main goal of the benchmarking tool is to
+serve as a starting point (!) for merchants that are interested in developing
+stress tests to see how far their infrastructure can scale. As is, it
+currently is not actually good at stressing the payment system.
-The main goal of the benchmarking tool is to serve as a starting point (!) for
-merchants that are interested in developing stress tests to see how far their
-infrastructure can scale.
+The ``taler-unified-setup.sh`` script can be used to launch all required
+services and clients. However, the resulting deployment is simplistic
+(everything on the local machine, one single-threaded process per service
+type) and not optimized for performance at all. However, this can still be
+useful to assess the performance impact of changes
+to the code or configuration.
-The current tool has already a few options, but we expect that to deliver
-*relevant* results it will need to be customized to better reflect the
-workload of a particular merchant. This customization would at this point
-likely involve writing (C) code. We welcome contributions to make it easier
-to customize the benchmark and/or to cover more realistic workloads from the
-start.
-
-
-Benchmark setup
-^^^^^^^^^^^^^^^
-The ``taler-merchant-benchmark`` tool will automatically launch and configure the
-exchange, (Python) bank and other tools required for the benchmark. However,
-the configuration file must be provided and have consistent options set. The
-options that require special care include the exchange's public key (which
-must match the private key in the file specified by the configuration), the
-currency (which must be consistent across the file), the denomination
-structure (which must enable payments in the range of 100ths of the unit
-currency (often called cents)). Furthermore, the benchmark will set the
-Exchange bank account password to be "x", so the configuration must also
-specify "x" for the passphrase. Finally, the bank must be configured to allow
-for substantial debt least the transactions by the benchmark run out of
-digital cash.
+Various configuration files that can be used in the code snippets in this
+section can be found in the ``src/merchant-tools/`` directory of the
+merchant. These are generally intended as starting points. Note that the
+configuration files ending in ``.edited`` are created by
+``taler-unified-setup.sh`` and contain some options that are determined at
+runtime by the setup logic provided by ``taler-unified-setup.sh``.
-A relatively minimal configuration could look like this:
+See :ref:`Taler Exchange Manual <Benchmark-choose-bank>` for how to use ``taler-unified-setup.sh`` to setup the system and in particular on how to specify the bank to be used.
-.. literalinclude:: merchant-benchmark.conf
+Running taler-merchant-benchmark
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+You can run the tool as follows:
-Note that the public key must match the exchange's
-private key and that the PostgreSQL database must
-exist before launching the benchmark. You also
-will need to ensure that the Exchange's
-details are set up.
-For details, see the :ref:`Exchange Operator Manual <Bank-account>`.
+.. code-block:: console
+ $ CONF=benchmark-rsa.conf
+ $ taler-unified-setup.sh -emwt -c "$CONF" -f -u exchange-account-1
+ $ time taler-merchant-benchmark ordinary -c "$CONF".edited -u exchange-account-1 -f -p 20
-Running the benchmark command
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+The current tool has already a few options, but we expect that to deliver
+*relevant* results it will need to be customized to better reflect the
+workload of a particular merchant. This customization would at this point
+likely involve writing (C) code. We welcome contributions to make it easier
+to customize the benchmark and/or to cover more realistic workloads from the
+start.
The tool takes all of the values it needs from the command line, with
-one of them being mandatory:
+some of them being common to all subcommands:
-- ``--exchange-account=SECTION`` Specifies which configuration
+- ``--exchange-account-section=SECTION`` Specifies which configuration
section specifies the bank account for the exchange that
should be used for the benchmark. For the example
configuration above, the SECTION value provided must be
``exchange-account-exchange``.
+- ``--fakebank`` Specifies that the benchmark should expect to interact
+ with a fakebank (instead of libeufin).
The tool comes with two operation modes: *ordinary*, and *corner*.
The first just executes normal payments, meaning that it uses the
@@ -1124,17 +1117,11 @@ interesting, there are:
perform *UN* (one coin) payments that will be left unaggregated.
As for the ``ordinary`` subcommand, it is worth explaining the following
-options:
+option:
- ``--payments-number=PN`` Instructs the tool to perform *PN* payments.
-- ``--tracks-number=TN`` Instructs the tool to perform *TN* tracking
- operations. Note that the **total** amount of operations will be two
- times *TN*, since "one" tracking operation accounts for
- ``/track/transaction`` and ``/track/transfer``. This command should
- only be used to see if the operation ends without problems, as no
- actual measurement of performance is provided (despite of the
- ’benchmark’ word used in the tool’s name).
+
