ORDS 24.1.0 is faster

ORDS 24.1.0 was released today and is available for download at https://oracle.com/rest. The release notes outline the enhancements and bug fixes. Many are notable. That includes performance improvements for JSON-Relational Duality Views and AutoREST in general.

Here’s an outline of test results using ORDS 24.1.0 running in my Developer DB VM on my laptop. It’s not a blindingly fast Oracle Exadata database setup so the absolute response times are nothing to write home about but the comparison of ORDS 24.1.0 over 2 previous ORDS releases is the point of the exercise here.

Noticeable improvement in the Duality View response time statistics for ORDS 24.1.0
Similarly, a noticeable improvement in the Table response time statistics for ORDS 24.1.0

Data Shape

The data shape is the RESTful Car-Racing Example. In particular the GET of TEAM and TEAM_DV data through ORDS. Using k6 scripts for generating requests, there are 10 concurrent clients that are sending GET resource item requests 1,000 times each. The resource item identifier, team_id, is random so not the same row is returned ever time. The data set is not huge by any stretch of the imagination and does not reflect a likely production data shape. However, the purpose here is to compare changes in response times and throughput.

Authentication

Those AutoREST services provided by ORDS for the tables and duality views are protected because that’s most likely to be the situation in production. The k6 script is hard coded with client id and client secret for authentication. When the k6 test script starts the first thing performed is to get an access / bearer token which is then subsequently used for every request generated by the script. You will notice in every script run this output indicating the token that will be sent for every request.

INFO[0000] {"access_token":"u2mkjkD3lyJXDQYqgjedag","token_type":"bearer","expires_in":3600}  source=console

Checks

There is also the output for checks performed on every response to ensure the expected data is returned. For example, if the authorisation token was invalid, the response status code would not be 200.

     ✓ is status 200
     ✓ is application/json
     ✓ is requested team resource

More on the k6 scripts later. Now let’s look at the database and ORDS configuration.

Configuration

Here’s a breakdown of the Developer DB VM configuration where the database and various versions of ORDS were run for the tests. The version of both ORDS and the Java Runtime Environment have been modified so if you are not familiar with that process see Get the latest – Enhance your DB Developer VM

Database

The same Oracle Database 23 Free edition that came with the Developer DB Virtual Machine is used. The HR schema is REST Enabled and contains the Car-Racing Duality View database objects.

ORDS Settings

The default configuration settings are used. These are the same configuration settings for all versions included in the test.

Default, out of the box, configuration that came with the Developer DB VM

Java Runtime Environment

The virtual machine was originally packaged with Oracle Java 11.0.19 but it is easy to change that. In this virtual machine Oracle GraalVM for Java 17 is used.

It is straight forward to download another JRE distribution and create a symbolic link to it from your $ORDS_HOME/jre directory. The ORDS shell script will use that Java Runtime Environment irrespective of the $PATH or $JAVA_HOME environment variable.

[oracle@localhost ~]$ /home/oracle/ords/jre/bin/java --version
java 17.0.9 2023-10-17 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 17.0.9+11.1 (build 17.0.9+11-LTS-jvmci-23.0-b21)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 17.0.9+11.1 (build 17.0.9+11-LTS-jvmci-23.0-b21, mixed mode, sharing)

That is the setup for every test run. Startup a specific version of ORDS in standalone mode using the same configuration folder, and JRE, for each ORDS version.

  • Start ORDS in standalone mode: /home/oracle/ords-23.3.0/bin/ords serve
  • Start the test run: k6 run team_dv.js
  • Gather the results
  • Start the test run: k6 run team.js
  • Gather the results
  • Shutdown ORDS

Repeat for /home/oracle/ords-23.4.0/ and /home/oracle/ords-24.1.0/ to cover those releases too. Not sure how to get your Developer DB VM to have multiple versions of ORDS? Take a look at Get the latest – Enhance your DB Developer VM.

Results

The test runs involve sending requests to GET a random team record, either as a Team Duality View query or query directly on the Team Table that the duality view uses.

Results – ORDS 23.3.0

ORDS 23.3.0 AutoREST Duality View

Duality View row GET using ORDS 23.3.0
iteration_duration:
avg=474.61ms
min=77.88ms
med=469.71ms
max=1.79s
p(90)=671.22ms
p(95)=741.16ms

throughput 20.917985/s

ORDS 23.3.0 AutoREST Table

Table row GET using ORDS 23.3.0
iteration_duration:
avg=130.91ms
min=18.3ms
med=132.64ms
max=390.02ms
p(90)=190.82ms
p(95)=212.67ms

throughput: 75.742323/s

Results – ORDS 23.4.0

ORDS 23.4.0 AutoREST Duality View

Duality View row GET using ORDS 23.4.0
iteration_duration: 
avg=451.33ms
min=76.64ms
med=450.22ms
max=1.22s
p(90)=642.21ms
p(95)=696.75ms

throughput 22.055704/s

ORDS 23.4.0 AutoREST Table

Table row GET using ORDS 23.4.0
iteration_duration: 
avg=163.61ms
min=19.53ms
med=160.07ms
max=1s
p(90)=241.68ms
p(95)=270.31ms

throughput: 60.703901/s

Results – ORDS 24.1.0

Now for the test run with the latest version of ORDS.

Oracle REST Data Services version : 24.1.0.r0960841
Oracle REST Data Services server info: jetty/10.0.20
Oracle REST Data Services java info: Java HotSpot(TM) 64-Bit Server VM 17.0.9+11-LTS-jvmci-23.0-b21

ORDS 24.1.0 AutoREST Duality View

Duality View row GET with ORDS 24.1.0
iteration_duration:
avg=134.29ms
min=9.97ms
med=90.28ms
max=1.41s
p(90)=261.21ms
p(95)=522.78ms

throughput: 73.321615/s

ORDS 24.1.0 AutoREST Table

Table row GET with ORDS 24.1.0
iteration_duration:
avg=88.72ms
min=11.99ms
med=84.26ms
max=619.03ms
p(90)=134.83ms
p(95)=153.84ms

throughput: 111.435388/s

K6 Scripts

The scripts are quite simple. There are effectively only 3 files involved and they are all available at this github gist: https://gist.github.com/pobalopalous/dcf572abfce1b18f7f49168918231765

  • ords_auth.js provides a function for getting a bearer token
  • team.js tests the AutoREST endpoint for TEAM table and uses a function imported from ords_auth.js to get an access token. It is hardcoded with a client_id and client_secret and randomly gets team data based on their team_id.
  • team_dv.js tests the AutoREST endpoint for TEAM_DV duality view and uses a function imported from ords_auth.js to get an access token. It is hardcoded with a client_id and client_secret and randomly gets team data based on their team_id.

Do it yourself

With the RESTful Car-Racing Example data you should be able to run the same k6 scripts for testing your environment. If you have not done so already install k6 and download the team.js and team_dv.js script files. Just note that the CLIENT_ID and CLIENT_SECRET values will have to change for you database.

const ORDS_CLIENT_ID = 'ymDCZv5ePvte2kN8seOygw..';
const ORDS_CLIENT_SECRET = 'alU5L4Xp5GXOoT-qo9v6UQ..';

It is explained in the RESTful Car-Racing Example article how to get this information from the database. If your schema or port number is different, you’ll have to modify those too.

The upshot from my test runs is approximately 3 times improvement on throughput per second for JSON-Relational Duality Views and 2 times improvement for the throughput per second for a table. Your results may show different absolute response times but I expect you will see a similar improvement ratio when comparing with previous versions of ORDS.

Reply in the comments with your own findings. I look forward to hearing from you.

Leave a comment