-
Notifications
You must be signed in to change notification settings - Fork 19
Measuring Oracle Net Throughput
Many database application transfer large amounts of data between the database and some client or application server, and often does that using one or many concurrent "streams" of data. This is in particular the case for data warehouse style applications that import or export to or from the database. There are often figures available for the transfer speeds of the physical network, but in addition to these, getting an actual measure on the "database wire" is in many cases valuable information.
As part of the RWP*Load Simulator, there is a tool that estimates the throughput between the database and the client. In addition to being part of the complete RWP*Load Simulator, this tool is also available completely stand-alone.
The netthroughput tool measures download (database to client) throughput by executing a query with the following properties:
- Each row returned is close to 16kB in size.
- Although not guaranteed random, each row is different from the previous and has a high entropy.
- The array interface is used receiving a total of 64 rows or close to 1MB.
For measuring upload throughput, the following is used:
- A query returning a short, simple row, but designed to require about 100kB from the client side via bind variables.
- The bind variables are filled with high entropy data.
In both cases, the following is assumed:
- The database time (purely CPU) is small compared to the network time such that the network time dominates.
- The process is repeated to have sufficient data to give a reasonable average estimate of actual throughput.
- One or more concurrent streams, each with their own database connection, are executed.
The goal of this approach is to ensure network traffic dominates such that calculations of the transfer speed can be expected to truly represent Oracle Net throughput. The (almost) random and high entropy nature of the data should also ensure no or only little compression takes place.
To use the tool, credentials to connect to the database (username, password, connect string) are needed, and if these allow queries to v$ views, the results will include values based on physical byte counts. Otherwise, only ability to connect to the database is needed and no schema objects are created or used.
A sample call only measuring download and output is:
netthroughput -l username/{password}@//host/db --period=20 --concurrency=2 --download
RWP*Load Simulator Release 3.0.2.11 Development on Wed, 14 Sep 2022 09:36:56 UTC
Connected default database to:
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Connecting sessions
All threads connected
Actual throughput test now running 20 s
Download throughput estimate 0.248 GB/s logical, 0.248 GB/s physical
A typical call with increasing concurrency is:
for cur in 2 4 6 8 10 12 14 16 18 20
do
netthroughput --csvappend=mytp.csv --upload --download --concurrency=$cur -l username/{password}@service
done
after which the mytp.csv file may contain
#streams logicalMBdownload/s physicalMBdownload/s logicalMBupload/s physicalMBupload/s rampupneed
2 470.438 470.049 298.882 298.869 0
4 770.245 769.615 567.157 567.132 0
6 1041.642 1040.795 701.218 701.189 0
8 1124.310 1123.409 807.000 806.967 0
10 1162.961 1162.045 864.303 864.269 0
12 1172.542 1171.634 873.437 873.404 0
14 1175.067 1174.175 898.137 898.104 0
16 1175.537 1174.662 904.262 904.231 0
18 1175.659 1174.802 911.445 911.415 0
20 1175.503 1174.662 924.683 924.655 0
showing that the maximum throughput in both directions concurrently is around 1GB/s.
The tool is documented using rwlman nettrhoughput if you have a full installation of
the RWP*Load Simulator. Otherwise, if you have a download of the generated executable, it
can be provided a -h option, which produces this output:
This utility uses one or more database connections to run queries sending or
receiving large data volumes to allow measuring the possible throughput.
You provide a number of concurrent streams doing this and can by increasing
the count get an estimate of the maximum throughput available.
If there is access to v$mystat, both physical and logical throughput
will be measured; otherwise only logical is available.
-l u/p@c : Compulsory option providing database credentials
--period=N : Set run period, default is 60s
--verbosetest : Make output more verbose
--concurrency=N : Run this many concurrent throughput tests, default 1
--rampup=N : Set rampup period for throughput tests, default is 5s
--upload : Measure upload performance
--download : Measure download performance
--upload-pct=N : When using both upload and download, by default, every
every other will do upload or download. Use --upload-pct
with a value different from 50 implies the split between
the two will be uneven
--end2end : Also gather end-to-end timing
--csvoutput=file : Write pure csv data to this file
--csvappend=file : Append pure csv data to this file
--csvexcel : Use ';' field separator and CRLF line terminator in csv
If you create a csv file, it has at least six columns:
1: the value of concurrency
2: the logical download throughput in MB/s
3: the physical download throughput in MB/s or 0 if not available
4: the logical upload throughput in MB/s
5: the physical upload throughput in MB/s or 0 if not available
6: 0 if data is reliable, otherwise the needed rampup
With end-to-end timings, six further columns are added with
download and upload total, oci, and database time
- The -l option is compulsory and is the username, password and connect string (either URL style or entry in tnsnames.ora) to the database. You can omit the password in which case the tool will prompt for it. This is similar to how SQL*Plus works.
- By default, the test runs for 60s, the --period option can be used to change this.
- By default, only one stream executes the query. To use multiple streams, use the --concurrency option.
- Specify either or both of --upload and --download.
- If you want the actual network packages to be different from the roughly 100kB, use --fetcharray with a value different from 8. You can similarly change the total size of each query using the --mbperquery option.
- When multiple concurrent streams are running, it is important that the start and therefore run at exactly the same time. If rampup is slow, the tool will warn about some streams being late and suggest a new value for the --rampup parameter.
- For generating csv files, see below.
You typically need to perform multiple executions with increasing values for the --concurrency option. To further analyze data from doing this, you can use the various csv options to create a csv file with the data. One suggestion is to use a loop like:
for cur in 2 4 6 8 10 12 14 16 18 20
do
netthroughput --csvappend=mytp.csv --upload --download -l username/{password}@//host/db --concurrency=$cur
done
After execution, the generated mytp.csv file may contain:
which potentially could be used as input to gnuplot. If you additionally had provided the --csvexcel option, the format will be useful for processing using typical office software on a Windows PC.
Note that each execution of the tool writes one line of data to the csv file and that each line contains these six values:
- The concurrency used.
- The logical download throughput in MB/s, i.e. based on the amount of data received by the query executed.
- The physical download throughput in MB/s which is based on queries against v$ tables for the statistics 'bytes sent via SQL*Net to client'. If the necessary v$ views cannot be accessed, the value will be 0.
- The logical upload throughput in MB/s
- The physical upload throughput in MB/s
- A value of 0 indicates the results are valid and that all concurrent streams started at the same time. A non zero value indicates some streams were late in starting making results unreliable. The actual value is the required value for the --rampup parameter.
The tool has a relatively high resource consumption both on the database, on the client where it is executed, and on the network. Although it is assumed that increased concurrency eventually will result in the network being the bottleneck, this cannot be guaranteed. If possible, it is therefore suggested to run "top" or similar on both the client and the database server to ensure neither of these reach cpu exhaustion.
The command is available in both the full rwloadsim installation and in the stand alone binary distribution. With the full installation, you additionally have access to the complete man page if you type:
rwlman netthroughput
See https://github.com/oracle/rwloadsim/wiki/Measuring-Oracle-Net-Latency#download for download details.