In my experience, if we had many models (ex. one hundred), Rails boot was slowly.
According to production log, it seems that AR's schema data loading is slowly especially.
Thus I've implemented schema cache dumping. Please review it.
I guess this implementation has many fixing point ;)
schema cache dumping
$ edit config/environments/production.rb
config.use_schema_cache_dump = true
$ RAILS_ENV=production bundle rake db:schema:cache:dump
=> generate db/schema_cache.dump
$ RAILS_ENV=production rails s
I like this idea, but can we change a few things?
First, can we just implement marshal_dump and marshal_load on the SchemaCache object? Second, I'm not sure that loading every model is the best idea for the schema cache. What about asking for all the tables and populating the cache that way? For example:
schema_cache.connection.tables.each do |table|
Maybe not a populate method, but something. I don't really like the idea of requiring every model in order to get the schema cache.
I have another idea that is related to this: can we enable schema caching by default? We can use the migration version to determine if the cache should be expired. Maybe add a version method to the schema cache object.
Anyway, I really like this feature.
Thank you for comment ! I'll improve the implement :)
Add support schema cache dump and load.
Add db:schema:cache:dump and db:schema:cache:clear tasks.
Load db/schema_cache.dump duaring boot time.
Support judgement expired schema cache dump.
Add entry for schema cache dump to CHANGELOG.md.
Please review new some commits.
A hash with default_proc can't be dumped.
This configuration should not be here. It is specific to Active Record and therefore should be defined in Active Record railtie.
Certainly, I agree with you.. Do you mean kennyj@82bd05a ?
Can you provide some benchmarks for this optimization? How much does it actually speed things up?
I'll provide it, but I've many works during this week. Please, just wait a moment a few days.
Sorry for keeping you waiting for this reply.
I tested about this performance.
But this result was not expected one.
・building environment steps
In my experience on Oracle, the queries to data dictionary were very slow when having many data.
Thus, by similar approache, we solved that problem.
I'll try to research a little more.