In order to use Axiom, a SQL database is required. This database ingests results from the clients under test to be retrieved later for individual observation or statistical analysis.

This project was designed around a PostgreSQL database using the node-postgres package as as an interface. Most other SQL implementations would easily support Axiom with little modification.

Axiom's database is a straight hierarchical schema. Benchmarks contain frameworks, frameworks contain tests, and tests contain results - this hierarchy is followed in the table structure outlined below.

At the end of this guide, SQL statements are provided that will recreate the schema.

This table tracks benchmark jobs that have been requested by clients. A benchmark is considered an individual test request, representing 1 or more frameworks that were tested.

benchmarkid is the human-friendly way of identifying a benchmark. It can be used to recall the result later using the home page of Axiom.

timestamp is the timestamp of the beginning of the test, given in UTC format.

iscomplete tracks whether the benchmark has been completed. This field is included so that unfinished results can be removed by a scheduled job. Another option was to only add benchmark results on completion - this route was chosen instead so that future improvements could be flexible in execution.

All other fields are information collected about the client for the sake of comparing clients to each other. Each field is given by a user agent API, further customized by the custom rules outlined in the user agent string section elsewhere in the manual.

This table contains each framework that was tested in the associated benchmark.

benchmarkid references the benchmark that the benchmark was executed in.

frameworkid allows the test table to reference the framework being tested. This is automatically generated when a framework is inserted, and is only used internally.

frameworkname is the name of the framework being tested.

frameworkversion is the version of the framework being tested. Future versions may improve the performance, so it will be important to track the version being tested.

This table contains each test that was tested in the associated framework.

frameworkid references the framework that ran the test.

testid allows the result table to reference the test that produced the result. It is only used internally.

description describes the type of test that was ran. For example, a test could cover lifecycle events or row manipulation.

This table contains each result that was produced in the associated test.

testid references the test that created the result.

floatresult contains the actual numeric result produced by the test. Typically stored as milliseconds, but could contain any numeric result as long as it is correctly used on the reporting side.

description describes the result generated by the test. For instance, a lifecycle test might have a render timing result and a create timing result.

Axiom has few requirements for database setup. The main requirement is running **PostgreSQL Server 10.0+ **running on a host that is accessible from the system that runs the Axiom backend.

Once a database is created, the table schema must be in place for Axiom to boot and run correctly.

Attached is a SQL setup script that will recreate the schema described above.

Create a non-superuser account for Axiom to use. It needs read/write privileges only.

Once the database is in place, Axiom needs to know the location and credentials of the database. This information is provided in the environmental variables for the project. If developing locally, a .env file can be placed in the** **root of the project folder containing the environment variables in the format given below.

The environment variables are:

PGHOST=<host url>
PGPORT=<port of sql instance>
PGDATABASE=<database to access>
PGUSER=<username>
PGPASSWORD=<password>
TIMEZONE=<tz timezone>

Where the timezone is one specified in the TZ database: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

The database_access/ReportingJobs.js file provides a place to schedule regular jobs to run on the SQL server. Using a Node.js implementation of cron to run SQL queries through node-postgres, jobs can be run at any interval. The first version of Axiom provides one job that deletes unfinished benchmarks every Sunday night.

The database_access/ResultDbAgent.js file is the interface between the benchmark server and the database. This handles the creation of benchmarks and insertion of frameworks, tests, and results.

The database_access/ReportingDbAgent.js file is the interface between the reporting engine and the database. It is used by the routes/report.js route to accept and process queries. Upon inspection, one will see several common queries to pull individual benchmarks, as well as statistical queries on all results.