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> |
||
|---|---|---|
| .. | ||
| fabricators | ||
| fixtures | ||
| helpers | ||
| import_export | ||
| initializers | ||
| integration | ||
| integrity | ||
| jobs | ||
| lib | ||
| mailers | ||
| models | ||
| multisite | ||
| requests | ||
| script/import_scripts | ||
| serializers | ||
| services | ||
| support | ||
| system | ||
| tasks | ||
| views | ||
| rails_helper.rb | ||
| regenerate_swagger_docs | ||
| swagger_helper.rb | ||