7c321d3aad
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> |
||
|---|---|---|
| .. | ||
| benchmarks | ||
| bulk_import | ||
| demon_test | ||
| import_scripts | ||
| .gitignore | ||
| alice.txt | ||
| analyse_message_bus.rb | ||
| analyze_sidekiq_queues.rb | ||
| bench.rb | ||
| biggest_objects.rb | ||
| boot_mem.rb | ||
| cache_critical_dns | ||
| check_forking.rb | ||
| copyright-deposit | ||
| db_timestamps_mover.rb | ||
| diff_heaps.rb | ||
| discourse | ||
| docker_test.rb | ||
| i18n_lint.rb | ||
| measure.rb | ||
| memory-analysis | ||
| memstats.rb | ||
| micro_bench.rb | ||
| mwrap_sidekiq | ||
| profile_db_generator.rb | ||
| promote_migrations | ||
| rails | ||
| redis_memory.rb | ||
| require_profiler.rb | ||
| spawn_backup_restore.rb | ||
| start_test_db.rb | ||
| switch_container_ruby | ||
| test_email_settings.rb | ||
| test_mem.rb | ||
| test_memory_leak.rb | ||
| test_pretty_text.rb | ||
| thread_detective.rb | ||
| user_simulator.rb | ||