3 ms·

When you hit scale. Rails is not the concern. It's the datastore. All of the major performance problems at scale I've dealt with came down to a super giant tab

When you hit scale. Rails is not the concern. It's the datastore. All of the major performance problems at scale I've dealt with came down to a super giant table that keeps getting locked.

itake 4y ago
In another comment, it said Gitlab moved off ActiveRecord. The fundamental problem with rspec + ActiveRecord is for each test: you create db state (tons of inserts), run the test (more db reads and writes), and then tear down the state. This is very expensive when you have 100,000s of tests each taking 500ms. Rails/rspec does not make it easy to stub db state with ActiveRecord.
- worker_person 4y ago
  http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rails-7-12.html http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rail... Use transactional fixtures as much as possible. Minimal db usage between tests.
  - itake 4y ago
    yes, that improves clean up time, but doesn't help with all of the db writes you have to make to create db state for each test case.
    - worker_person 4y ago
      Initial state is loaded via fixtures or whatever. (slow and expensive) Transaction is started. Run Test 1 Transaction rolled back. (quick) Test 2 can be run without the expensive fixtures. Repeat for all tests.
      - itake 4y ago
        Does this mean if you only want to run the tests for `users_controller` during development, you still have to load the fixtures for all other tests with each run?
        worker_person 4y ago
        In the normal case. When you start a test it loads from fixtures into its own database. Any test can make use of what is in that database. So you tend to put a bunch of stuff that is useful for most tests. If a specific test needs an unusual setup, then it can do whatever is needed to load data. Generate data, load extra fixtures, etc. You can do this on a per test basis, or a group of tests, etc. An option is to reload everything between each test. Not recommended. Normal usage is to rollback any changes a test did, so that each test has a clean slate. This tends to be plenty fast. Parallelism can usually be done. If speed is still a concern, you can get fancy and load up multiple databases with fixtures and divide tests between them. Maybe have 2-8 sets of tests running at same time. It's been a few years, but I've inherited test suites that take 14 hours and been able to get them down to a few minutes with above techniques. Something like Guard can be setup to automatically run tests relevant to what you're working on. So you don't have to run full suite each time.

When you hit scale. Rails is not the concern. It's the datastore. All of the major performance problems at scale I've dealt with came down to a super giant table that keeps getting locked.

itake 4y ago

In another comment, it said Gitlab moved off ActiveRecord. The fundamental problem with rspec + ActiveRecord is for each test: you create db state (tons of inserts), run the test (more db reads and writes), and then tear down the state. This is very expensive when you have 100,000s of tests each taking 500ms. Rails/rspec does not make it easy to stub db state with ActiveRecord.

worker_person 4y ago
http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rails-7-12.html http://underpop.online.fr/r/ruby/rails/tutorial/ruby-on-rail... Use transactional fixtures as much as possible. Minimal db usage between tests.
- itake 4y ago
  yes, that improves clean up time, but doesn't help with all of the db writes you have to make to create db state for each test case.
  - worker_person 4y ago
    Initial state is loaded via fixtures or whatever. (slow and expensive) Transaction is started. Run Test 1 Transaction rolled back. (quick) Test 2 can be run without the expensive fixtures. Repeat for all tests.
    - itake 4y ago
      Does this mean if you only want to run the tests for `users_controller` during development, you still have to load the fixtures for all other tests with each run?
      - worker_person 4y ago
        In the normal case. When you start a test it loads from fixtures into its own database. Any test can make use of what is in that database. So you tend to put a bunch of stuff that is useful for most tests. If a specific test needs an unusual setup, then it can do whatever is needed to load data. Generate data, load extra fixtures, etc. You can do this on a per test basis, or a group of tests, etc. An option is to reload everything between each test. Not recommended. Normal usage is to rollback any changes a test did, so that each test has a clean slate. This tends to be plenty fast. Parallelism can usually be done. If speed is still a concern, you can get fancy and load up multiple databases with fixtures and divide tests between them. Maybe have 2-8 sets of tests running at same time. It's been a few years, but I've inherited test suites that take 14 hours and been able to get them down to a few minutes with above techniques. Something like Guard can be setup to automatically run tests relevant to what you're working on. So you don't have to run full suite each time.