RUrubiquity·May 16, 2016
Most developers have pretty short attention spans and we expect things to be fast. In development on a large-ish Rails application due to the way Rails autoloading works (I heard this is changing soon?) just editing certain files is not that far off from a full-restart. So the "F5 Driven Development" flow is very slow on our app. The Rails app I work on is 9 years old (no rewrites, go us!).
We've tried to use pre-forking preloaders like Spring but we found ourselves force killing Spring more often than it was useful for us.
EDIT: Performance is complicated and can be a sensitive topic so I'm going to elaborate. While dev restart/refresh times are annoying, the real elephant in the room are Rails test suites. We (and many other places I've worked at) rightfully use our test suite as a signal of when to merge and when to deploy. This means
Read the rest
the entire suite (~4000 tests - it's a big app!) needs to come back as passing before we will merge a branch that can be deployed. Our current test suite takes about 40 minutes to run in a single process (more on this later) if the planets align.
Here's a list of a few things I've done in my career (I'm very grateful Ruby and Rails have given me a career, btw) to get around Ruby and Rails' performance gotchas:
- Caching logic so complicated that you would think our business domain is actually caching and not our real business.
- Converted a test suite from TestUnit to RSpec (it was fashionable) and then finally back to MiniTest.
- Stopped writing the type of test that is by far the most valuable (End-to-end browser specs) for all but the most important features due to how slow these types of tests are and the amount of false negatives they produce.
- Tried the whole shared_connection.rb[0] trick to share a DB connection between feature spec thread and Rails server threads for transactions in feature specs. It's buggy and made our test suite worse off.
- I've gone back and forth between PhantomJS and capybara-webkit more times than is healthy.
- Wrote code to spoof the User session in the above tests so we didn't have to browse to login_path all the time.
- Set DEBUG_ASSETS to false in development (except for when we're editing CoffeeScript files) to reduce the amount of work that sprockets need to do.
- Used our hosted CI's parallel test runner to try and run things faster. Marginal improvement, proprietary, and lots of yucky config files.
- Used Aman Gupta's test-queue[0] to parallelize our test suite under our own control and now we're looking for automate spinning up instances with 8+ CPUs to hopefully get our test suite to run in less than 5 minutes.
0 - https://gist.github.com/josevalim/470808
1 - https://github.com/tmm1/test-queue