0.0.2 configure update
This commit is contained in:
parent
0fb17e2b70
commit
a8412268c0
@ -17,7 +17,7 @@
|
||||
#
|
||||
#
|
||||
AC_PREREQ([2.69])
|
||||
AC_INIT([taler-exchange], [0.0.1], [taler-bug@gnunet.org])
|
||||
AC_INIT([taler-exchange], [0.0.2], [taler-bug@gnunet.org])
|
||||
AC_CONFIG_SRCDIR([src/util/util.c])
|
||||
AC_CONFIG_HEADERS([taler_config.h])
|
||||
# support for non-recursive builds
|
||||
|
BIN
doc/paper/bw_in.png
Normal file
BIN
doc/paper/bw_in.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 7.2 KiB |
BIN
doc/paper/bw_out.png
Normal file
BIN
doc/paper/bw_out.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 7.4 KiB |
BIN
doc/paper/cpu_balance.png
Normal file
BIN
doc/paper/cpu_balance.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 11 KiB |
BIN
doc/paper/cpu_usage.png
Normal file
BIN
doc/paper/cpu_usage.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 7.3 KiB |
BIN
doc/paper/db_read.png
Normal file
BIN
doc/paper/db_read.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 11 KiB |
BIN
doc/paper/db_write.png
Normal file
BIN
doc/paper/db_write.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 14 KiB |
@ -32,6 +32,9 @@
|
||||
\usetikzlibrary{shapes,arrows}
|
||||
\usetikzlibrary{positioning}
|
||||
\usetikzlibrary{calc}
|
||||
\usepackage{caption}
|
||||
\usepackage{subcaption}
|
||||
\usepackage{subfig}
|
||||
|
||||
% Relate to:
|
||||
% http://fc14.ifca.ai/papers/fc14_submission_124.pdf
|
||||
@ -928,6 +931,83 @@ can then use the refresh protocol to anonymously melt the refunded
|
||||
coin and create a fresh coin that is unlinkable to the refunded
|
||||
transaction.
|
||||
|
||||
\section{Experimental results}
|
||||
|
||||
\begin{figure}[b!]
|
||||
\begin{subfigure}{0.45\columnwidth}
|
||||
\includegraphics[width=\columnwidth]{bw_in.png}
|
||||
\caption{Incoming traffic at the exchange, in bytes per 5 minutes.}
|
||||
\label{fig:in}
|
||||
\end{subfigure}\hfill
|
||||
\begin{subfigure}{0.45\columnwidth}
|
||||
\includegraphics[width=\columnwidth]{bw_out.png}
|
||||
\caption{Outgoing traffic from the exchange, in bytes per 5 minutes.}
|
||||
\label{fig:out}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}{0.45\columnwidth}
|
||||
\includegraphics[width=\columnwidth]{db_read.png}
|
||||
\caption{DB read operations per second.}
|
||||
\label{fig:read}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}{0.45\columnwidth}
|
||||
\includegraphics[width=\columnwidth]{db_write.png}
|
||||
\caption{DB write operations per second.}
|
||||
\label{fig:write}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}{0.45\columnwidth}
|
||||
\includegraphics[width=\columnwidth]{cpu_balance.png}
|
||||
\caption{CPU credit balance. Hitting a balance of 0 shows the CPU is
|
||||
the limiting factor.}
|
||||
\label{fig:cpu}
|
||||
\end{subfigure}\hfill
|
||||
\begin{subfigure}{0.45\columnwidth}
|
||||
\includegraphics[width=\columnwidth]{cpu_usage.png}
|
||||
\caption{CPU utilization. The t2.micro instance is allowed to use 10\% of
|
||||
one CPU.}
|
||||
\label{fig:usage}
|
||||
\end{subfigure}
|
||||
\caption{Selected EC2 performance monitors for the experiment in the EC2
|
||||
(after several hours, once the system was ``warm'').}
|
||||
\label{fig:ec2}
|
||||
\end{figure}
|
||||
|
||||
We ran the Taler exchange v0.0.2 on an Amazon EC2 t2.micro instance
|
||||
(10\% of a Xeon E5-2676 at 2.4 GHz) based on Ubuntu 14.04.4 LTS, using
|
||||
a db.t2.micro instance with Postgres 9.5 for the database. Using 16
|
||||
concurrent clients performing withdraw, deposit and refresh operations
|
||||
we then pushed the t2.micro instance to the resource limit
|
||||
(Figure~\ref{fig:cpu}) from a network with $\approx$ 160 ms latency to
|
||||
the EC2 instance. At that point, the instance managed about 8 HTTP
|
||||
requests per second, which roughly corresponds to one full business
|
||||
transaction (as a full business transaction is expected to involve
|
||||
withdrawing and depositing several coins). The network traffic was
|
||||
modest at approximately 50 kbit/sec from the exchange
|
||||
(Figure~\ref{fig:out}) and 160 kbit/sec to the exchange
|
||||
(Figure~\ref{fig:in}). At network latencies above 10 ms, the delay
|
||||
for executing a transaction is dominated by the network latency, as
|
||||
local processing virtually always takes less than 10 ms.
|
||||
|
||||
Database transactions are dominated by writes (Figure~\ref{fig:read}
|
||||
vs. Figure~\ref{fig:write}), as Taler mostly needs to log
|
||||
transactions and occasionally needs to read to guard against
|
||||
double-spending. Given a database capacity of 2 TB---which should
|
||||
suffice for more than one year of full transaction logs---the
|
||||
described setup has a hosting cost within EC2 of approximately USD 252
|
||||
per month, or roughly 0.0001 USD per full business transaction. This
|
||||
compares favorably to the $\approx$ USD 10 per business transaction
|
||||
for Bitcoin and the \EUR{0.35} plus 1.9\% charged by Paypal for
|
||||
domestic transfers within Germany.
|
||||
|
||||
In the Amazon EC2 billing, the cost for the database (using SSD
|
||||
storage) dominates the cost with more than USD 243 per month. We note
|
||||
that these numbers are approximate, as the frontend and backend in our
|
||||
configuration uses systems from the AWS Free Usage Tier and is not
|
||||
perfectly balanced in between frontend and backend. Nevertheless,
|
||||
these experimental results show that computing-related business costs
|
||||
will only marginally contribute to the operational costs of the Taler
|
||||
payment system.
|
||||
|
||||
|
||||
|
||||
\section{Discussion}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user