While load testing our user creation code path in production, we identified that executing the DB statement to update the `Group#user_count` column within a transaction is creating a bottleneck for us. This is because the creation of a user and addition of the user to the relevant groups are done in a transaction. When we execute the DB statement to update `Group#user_count` for the relevant group, a row level lock is held until the transaction completes. This row level lock acts like a global lock when the server is creating users that will be added to the same group in quick succession. Instead of updating the counter cache within a transaction which the default ActiveRecord `counter_cache` option does, we simply update the counter cache outside of the committing transaction. Co-authored-by: Rafael dos Santos Silva <xfalcox@gmail.com> Co-authored-by: Rafael dos Santos Silva <xfalcox@gmail.com> |
||
|---|---|---|
| .. | ||
| admin_controller.rb | ||
| api_controller.rb | ||
| backups_controller.rb | ||
| badges_controller.rb | ||
| color_schemes_controller.rb | ||
| dashboard_controller.rb | ||
| email_controller.rb | ||
| email_styles_controller.rb | ||
| email_templates_controller.rb | ||
| embeddable_hosts_controller.rb | ||
| embedding_controller.rb | ||
| emojis_controller.rb | ||
| groups_controller.rb | ||
| impersonate_controller.rb | ||
| permalinks_controller.rb | ||
| plugins_controller.rb | ||
| reports_controller.rb | ||
| robots_txt_controller.rb | ||
| screened_emails_controller.rb | ||
| screened_ip_addresses_controller.rb | ||
| screened_urls_controller.rb | ||
| search_logs_controller.rb | ||
| site_settings_controller.rb | ||
| site_texts_controller.rb | ||
| staff_action_logs_controller.rb | ||
| staff_controller.rb | ||
| themes_controller.rb | ||
| user_fields_controller.rb | ||
| users_controller.rb | ||
| versions_controller.rb | ||
| watched_words_controller.rb | ||
| web_hooks_controller.rb | ||