feat: performance measurement APIs

[BobdenOs]

This PR adds a new perf property to the cds.test API. Which is a wrapper around the commonly used autocannon node module. Which allows developers to measure the performance of their endpoints. To make the API as simple to use as possible the APIs have axios integration. Which means that by default the same base url is used by perf as it currently used by axios.

Additionally perf introduces the fn API. Which accepts a callback function which will be measured in a similar way as all the autocannon APIs are. Providing flexibility for not just measuring http request performance, but also for measuring the performance of any javascript function. For the use cases where multiple requests have to be chained together the fn callback can be async and the promise will be awaited and the connections configuration of autocannon will apply so that if there async function detaches from the event loop. It will trigger multiple parallel calls to the callback function.

const { POST, DELETE, perf: {GET, report, fn} } = cds.test()

it('GET', async () => {
  report(await GET`/browse/Books`)
})

it('complex', async () => report(await fn(async () => {
  const book = await POST('/admin/Books', {})
  await DELETE`/admin/Books(${book.ID})`
}))

it('compute', async () => report(await fn(() => {
  cds.db.cqn2sql(cds.ql`SELECT * FROM Books`)
})))

[patricebender]

just out of curiosity, whats the advantage of this over:

const time = process.hrtime() // nano precision
…
const diff = process.hrtime(time)

[BobdenOs]

It is more precise then performance.now and I got this from the node repository benchmark code.

[patricebender]

I know hrtime is more precise, I was just wondering why we need the bigint() API here. Also the diff calculation can be done by the function itself (but it yields a [seconds, nanoseconds] tuple).

Smt like this:

- const d = process.hrtime.bigint() - s
+ const d = process.hrtime(s)

[patricebender]

Hi @chgeo / @danjoa I tried this out in a small benchmarking suite for cqn4sql. Does anything speak against merging this?

[mauriciolauffer]

What's the value in embedding autocannon or any other benchmark/performance tool into cds-test? What about customers using other tools like k6, vegeta, artillery, jmeter, etc? Using any of these tools is easy, the effort is minimum...

[BobdenOs]

@mauriciolauffer the primary benefit of this integration is the setup that @cap-js/cds-test provides. Allowing developers to use APIs they are already familiar with to quickly write performance tests.

It provides the same portability that all the other tests provide. If you already have a test setup that works with both @cap-js/sqlite and @cap-js/hana there is no additional configurations required to start adding performance tests. You can run them locally with @cap-js/sqlite knowing that once you push this test to the pipeline that it will work just like any other test.

It is not required to use these APIs to write performance tests. If customers are already using other performance testing tools they can still keep using them. This PR is the first step in the process of improving performance measurement capabilities in the CAP framework. The reason autocannon is used in the current implementation is related to internal tooling support for autocannon. Once the performance APIs have stabilized it will be possible to provide support also for other libraries and backend.