Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

increase section experiment limit to 2K #58172

Merged
merged 1 commit into from Apr 23, 2024

Conversation

davidsbailey
Copy link
Member

see slack. we are running into this limit while trying to add users to the ai-rubrics experiment. we have 1000 of these objects in production today, so unless there are signs of performance problems, I'd like to propose increasing the limit.

@davidsbailey davidsbailey marked this pull request as ready for review April 22, 2024 22:51
@sureshc
Copy link
Contributor

sureshc commented Apr 23, 2024

During peak utilization (5AM PDT to 5PM PDT) our web application is issuing about 10 SELECT statements per second on the experiments table and is retrieving about 4500 rows per query with an average latency of ~5ms (10X slower than our overall SELECT latency). These queries are somewhat intensive ... they retrieve all active experiments and then inspect the result set within the web application server to determine which experiments apply to the current user session. Increasing the number of experiments will increase the size of these result sets, but likely will not degrade overall database performance.

These data is from Performance Insights on the writer database instance
image

NewRelic confirms that ActiveRecord Experiment find is being executed about 10 times per second during peak usage. The latency from the web application server is 10ms.

image

Several different Rails controller actions are invoking this ActiveRecord find method. I haven't looked at how they invoke the Experiment model, but we must be caching the result set in memory because our SELECT throughput is very low (10/second) for something that has to be checked several thousand times per minute across a wide variety of high throughput controller actions:

image

@sureshc sureshc self-requested a review April 23, 2024 01:41
Copy link
Contributor

@sureshc sureshc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our application is inefficient when querying this data, but is likely caching the result set, so increasing the size of the result set should not significantly degrade database system performance.

@davidsbailey davidsbailey merged commit 44e134b into staging Apr 23, 2024
2 checks passed
@davidsbailey davidsbailey deleted the increase-section-experiment-limit branch April 23, 2024 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants