performance: add db indexes and cache frequent db queries

[beesaferoot]

Improves on #1036

Brief summary of the change made

Are there any other side effects of this change that we should be aware of?

Describe how you tested your changes?

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[dmohns]

Hey @beesaferoot

Can you explain a bit what is happening here? I see your are adding some caching and indexes. But why? Which (underlying) problem does it solves which lead to the sluggishness? How did you identified these issues?

[beesaferoot]

Hey @beesaferoot

Can you explain a bit what is happening here? I see your are adding some caching and indexes. But why? Which (underlying) problem does it solves which lead to the sluggishness? How did you identified these issues?

Sorry I left out a description; I was too tired from working past midnight 🙈.

Background:
My focus was on the search endpoint latency, previous improvements were entirely on the frontend. The next improvement possibility was to cut down the server response.

I profiled the performance of the customer search endpoint using laravel telescope (too bad I didn't make any screen shots), it had a lot of details about each server request. One of these was the database queries that happened during the duration of the request.

There were 11 db queries (some indirectly) in total; there are roughly three parts that contribute to the latency data serialization, db queries, and network latency.

I focused on the DB queries because they accounted for over 80% of the server response latency.

My approach was to employ low-hanging performance improvements that don't further complicate the logical flow of the search endpoint just yet.

Adding Indexes:
I noticed we didn't have indexes for the search fields used in the db queries above. Tables like people, addresses and devices. Outside the search endpoint we do often query these fields, so it was a cheap way to improve queries that happen often on those fields.

Caching:
One of the db queries that happened often (for every request) was fetching the company database from the company_databases table using the company id. It was about 1.13 ms each request.

Caching this query cut down the total queries to 10 during the call to the search endpoint.

I added caching to the database proxy table, which itself is not related to the search endpoint improvement but has shown a good improvement to the login endpoint call.