# Code-level performance testing

**URL:** <https://meta.discourse.org/t/code-level-performance-testing/282856>\
**Category:** Development\
**Created:** [October 20, 2023, 3:44am UTC](https://meta.discourse.org/t/code-level-performance-testing/282856 "2023-10-20T03:44:49Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![angus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/angus/32/341715_2.png) [@angus](https://meta.discourse.org/u/angus)\
**Post date:** [October 20, 2023, 3:44am UTC](https://meta.discourse.org/t/code-level-performance-testing/282856/1 "2023-10-20T03:44:49Z")

</div>

I’ve been looking at the performance of the [ActivityPub plugin](https://meta.discourse.org/t/activitypub-plugin/266794) recently and considering the best ways to reliably test, and prove, performance for the purpose of such a project. Here’s a few initial pieces of context:

- The plugin is an open source project with multiple parties involved (i.e. Discourse, who owns the plugin, and Pavilion who is currently building it).

- Different parties may have different internal performance testing tools / systems.

- Multi-party open source projects benefit from commonly available methods of testing, and proving, that something works, or in this case performs, reliably.

- Discourse (laudably) cares about performance.

- Currently, the only commonly available method of testing / proving server-side performance in Discourse (that I’m aware of) is [track\_sql\_queries](https://github.com/discourse/discourse/blob/467e1a1bddb8266e4ab1165fbba71745d4f9c269/spec/support/helpers.rb#L197), which is typically (but not exclusively) used in request tests.

- While the query count is one indicator of performance, it’s not the only one (some queries are bigger than others).

For a recent example of the use of `track_sql_queries` see

> <https://github.com/discourse/discourse-activity-pub/pull/32>
>
> @pmusaraj This is the first of a few performance related PRs. This one is focuse…d on topics.
> 
> The next one will likely be focused on categories, and will come after https://github.com/discourse/discourse/pull/23969 is merged. I'm going to circle back to topics again after this is and the first categories performance PR is handled to see what additional gains can be made.
> 
> Note that all the actual performance gains here are being made in the topic \`show\` action. The AP plugin seems to have little discernible impact on topic lists (category lists are a different story) and I've added a spec to both (partially) demonstrate that and also as a guard against regression.
> 
> With respect to topic \`show\` I'll let the specs speak for themselves, but just to illustrate the gain being made there (and as a sanity check) these are the different profiles of a topic on my local. The topic has:
> \- Full Topic publication type (when AP is enabled)
> \- 7 posts from 4 different actors (users)
> 
> \##### No AP plugin (vanilla discourse)
> \<img width="741" alt="Screenshot 2023-10-19 at 14 16 28" src="https://github.com/discourse/discourse-activity-pub/assets/5931623/bd3be390-56f1-4d2e-a0dd-68365647552f"\>
> 
> \##### AP plugin on this branch
> \<img width="730" alt="Screenshot 2023-10-19 at 14 12 32" src="https://github.com/discourse/discourse-activity-pub/assets/5931623/45555532-fcbd-4b0b-a24a-26e330ff0d59"\>
> 
> \##### AP plugin on main
> \<img width="733" alt="Screenshot 2023-10-19 at 14 14 21" src="https://github.com/discourse/discourse-activity-pub/assets/5931623/fbcd3b7b-2027-42f0-ac50-d3e8089e3763"\>

If you’re familiar with this area, you probably know something like

> The rule of thumb is that unit tests need speed and performance tests need time.

(quote from [this decent explainer](https://www.testrail.com/blog/performance-testing-at-unit-level))

Which, on the face of it, can make performance testing (beyond query counting) somewhat hard to integrate into an rspec (or similar) suite. That said, some people try

> **[GitHub - piotrmurach/rspec-benchmark: Performance testing matchers for RSpec](https://github.com/piotrmurach/rspec-benchmark)**
>
> Performance testing matchers for RSpec

I’m curious what other practical methods, suggestions or ideas folks may have to add more commonly available performance testing, and performance proofs, to the Discourse ecosystem. Or if there are methods or approaches I haven’t mentioned here. I would emphasise the words “practical” and “commonly available” there.

One thought that occurs is that it could be possible to use [MiniProfiler](https://github.com/MiniProfiler/rack-mini-profiler) in a spec, i.e. something like `Rack::MiniProfiler.profile_singleton_method`. But I have neither tried that, or know whether that’d be a good idea.

---

_[View the full topic](https://meta.discourse.org/t/code-level-performance-testing/282856)._