A Horrible Way to Benchmark Rails’ Request Processing # This is not a very beautiful code, but it's just an example... # And it kinda works... require 'benchmark/ips' Rails.application.config.after_initialize do Rails.application.extend Module.new { def call(e) super Benchmark.ips do |x| x.report('Rails.application#call') do super end end super end } end
Adding GC.stat to the ips Code Rails.application.config.after_initialize do Rails.application.extend Module.new { def call(e) super + p before: GC.stat Benchmark.ips do |x| x.report('Rails.application#call') do super end end + p after: GC.stat super end } end
Garbage Strings Used to Be a Big Concern There was a trend putting so many `.freeze` here and there in the code I thought that made our codebase super ugly. I did no more want to see PRs that adds `.freeze` to String literals in the framework So I proposed the magic comment (ruby 2.3): # frozen-string-literal: true Not mainly in order to improve the speed but in order to stop people's code pollution!
# frozen-string-literal: true Have anyone tried this? Maybe Rails will become a little bit faster if you put this to all .rb files in Rails Then we could remove all explicit `.freeze` calls We need to add some `.dup` calls though
Counting Method Calls Using TracePoint class MethodCounter def initialize(app) @app = app end def call(env) calls = [] trace = TracePoint.new(:call, :c_call) do |tp| calls << [tp.defined_class, tp.method_id, tp.lineno] end trace.enable ret = @app.call env trace.disable pp calls.group_by(&:itself).map {|k, v| {k => v.length}}.sort_by {|h| -h.values.first} ret end end use MethodCounter
However, These are well known theories that you might heard of before I’ll take a different approach today I’ll show you some known problems (to me) through my experience
How about ActionPack? ActionPack sits on top of Rack Let's see if we could find a bottleneck in the middleware stack Or maybe we could compose a minimum Rack middleware stack for our app?
Measuring Each Rack Middleware # Again, very roughly implemented monkey-patch that kinda works... $RACK_BENCH_BEFORE_CALL = $RACK_BENCH_AFTER_CALL = nil module RackBench def call(*) p "#{self.class}: before call" => Time.now - $RACK_BENCH_BEFORE_CALL if $RACK_BENCH_BEFORE_CALL $RACK_BENCH_BEFORE_CALL = Time.now ret = super p "#{self.class}: after call" => Time.now - $RACK_BENCH_AFTER_CALL if $RACK_BENCH_AFTER_CALL $RACK_BENCH_AFTER_CALL = Time.now ret end end Rails.configuration.middleware.each do |m| if m.klass.respond_to? :prepend m.klass.prepend RackBench else m.klass.singleton_class.prepend RackBench end end
Measuring Each Rack Middleware - Result {"ActionDispatch::Static: before call" => 8.0e-06} {"ActionDispatch::Executor: before call" => 0.000107} {"AS::Cache::Strategy::LocalCache::Middleware: before call" => 0.002279} {"Rack::Runtime: before call" => 1.9e-05} {"Rack::MethodOverride: before call" => 8.0e-06} {"ActionDispatch::RequestId: before call" => 1.0e-05} {"Rails::Rack::Logger: before call" => 4.8e-05} {"ActionDispatch::ShowExceptions: before call" => 0.00023} {"ActionDispatch::DebugExceptions: before call" => 1.0e-05} {"ActionDispatch::RemoteIp: before call" => 1.0e-05} {"ActionDispatch::Callbacks: before call" => 1.5e-05} {"ActionDispatch::Cookies: before call" => 1.6e-05} {"ActionDispatch::Session::CookieStore: before call" => 1.0e-05} {"Rack::Head: before call" => 3.1e-05} {"Rack::ConditionalGet: before call" => 5.0e-06} {"Rack::ETag: before call" => 6.0e-06}
Measuring Each Rack Middleware - Result (2) {"Rack::ConditionalGet: after call" => 2.4e-05} {"Rack::Head: after call" => 5.0e-06} {"ActionDispatch::Session::CookieStore: after call" => 0.000269} {"ActionDispatch::Cookies: after call" => 7.8e-05} {"ActionDispatch::Callbacks: after call" => 4.0e-06} {"ActionDispatch::RemoteIp: after call" => 1.3e-05} {"ActionDispatch::DebugExceptions: after call" => 6.0e-06} {"ActionDispatch::ShowExceptions: after call" => 2.0e-06} {"Rails::Rack::Logger: after call" => 2.2e-05} {"ActionDispatch::RequestId: after call" => 1.0e-05} {"Rack::MethodOverride: after call" => 3.0e-06} {"Rack::Runtime: after call" => 1.4e-05} {"AS::Cache::Strategy::LocalCache::Middleware: after call" => 7.0e-06} {"ActionDispatch::Executor: after call" => 5.0e-06} {"ActionDispatch::Static: after call" => 2.0e-06} {"Rack::Sendfile: after call" => 7.0e-06}
And creates another buffer, runs another template compilation & rendering per each partial
We don't always need a new context for a partial Simply concatenating templates (just like PHP's include) would be enough in some cases e.g. `<%= render 'footer' %>`
Parallelized render partial - Concept `render_collection` could be parallelized Partials are basically individual We could render all of them at once using Threads
Parellelize render partial - Result I tried, But with this patch, ActiveRecord connections very easily bloats up And that very often causes "Too many connections" error
Current Implementation # template/handlers/erb.rb module ActionView class Template module Handlers class ERB def call(template) # First, convert to BINARY, so in case the encoding is # wrong, we can still find an encoding tag # (<%# encoding %>) inside the String using a regular # expression template_source = template.source.dup.force_encoding(Encoding::ASCII_8BIT) erb = template_source.gsub(ENCODING_TAG, '') encoding = $2 erb.force_encoding valid_encoding(template.source.dup, encoding) # Always make sure we return a String in the default_internal erb.encode! self.class.erb_implementation.new( erb, :escape => (self.class.escape_whitelist.include? template.type), :trim => (self.class.erb_trim_mode == "-") ).src ennnnnd
Who Needs This Encoding Support? Who actually writes a non-UTF8 view file? Who actually puts an encoding magic comment in the view files? We see some test cases concerning Shift JIS encoded templates, but I'm sure nobody does this in Japan
Current Status 99.9% of Rails apps in the world do not require this feature But this default behavior puts the brakes on everyone’s apps [citation needed]
My Suggestion No Encoding conversion! Let’s assume that everybody writes their template in UTF-8 If that’s too aggressive, maybe we could extract this feature to a gem
Memory Usage Result # The Original ERBHandler allocated memory by class ----------------------------------- 1989 String 640 MatchData 232 Hash 160 Array 144 ActionView::Template::Handlers::Erubis 80 Symbol 40 Range # Patched ERBHandler allocated memory by class ----------------------------------- 1660 String 640 MatchData 232 Hash 160 Array 144 ActionView::Template::Handlers::Erubis 80 Symbol 40 Range
I18n Alternative I18n is unnecessarily complex (e.g. who uses a non-Yaml backend?) What if we make a simple I18n alternative that does nothing but just a simple Hash lookup?
Reducing Arel Objects - Concept If the query is simple enough, directly compose an SQL statement, just like we were doing in AR1 and 2 If the query is not simple enough, fallback to `super` (AR default behavior) No caching! (because building the whole query is as cheap as computing a cache key)
Arenai find - Implementation # The code is a little bit shortened for the presentation slide module Arenai module Base def find(*ids) return super unless ids.length == 1 return super if block_given? || primary_key.nil? || default_scopes.any? || columns_hash.include?(inheritance_column) || ids.first.kind_of?(Array) id = ids.first return super if !((Fixnum === id) || (String === id)) # SELECT "users".* FROM "users" WHERE "users"."id" = $1 [["id", 1]] find_by_sql("SELECT #{quoted_table_name}.* FROM #{quoted_table_name} WHERE #{quoted_table_name}.#{connection.quote_column_name primary_key} = $1", [[columns_hash[primary_key], id]]).first ennnd
AR 5 creates an Object per each attribute in a model instance
This brings a flexibility
But it's sometimes too much
For example, think of a batch system that selects 100,000 records that has 20 columns. That would create 2,000,000 "attribute" Objects I'm thinking of a plugin that can reduce this Object creation somehow
https://github.com/rails/ rails/pull/23394 I suggested a patch to fix this situation, but the proposal was turned down Because Rails is expecting you all to be careful enough never to walk into this trap
Maybe There's an Initializer Taking Too Much Time # railties/lib/rails/initializable.rb module Rails module Initializable def run_initializers(group=:default, *args) return if instance_variable_defined?(:@ran) initializers.tsort_each do |initializer| + now = Time.now initializer.run(*args) if initializer.belongs_to?(group) + p initializer.name => Time.now - now if Time.now - now > 0.1 end @ran = true end
Which Gem Takes Time When Being required? # bundler/lib/bundler/runtime.rb module Bundler class Runtime < Environment def require(*groups) groups.map!(&:to_sym) groups = [:default] if groups.empty? @definition.dependencies.each do |dep| # Skip the dependency if it is not in any of the requested # groups next unless (dep.groups & groups).any? && dep.current_platform? + now = Time.now required_file = nil ... end + p dep.name => Time.now - now ennnnd
This Way, I Found Dozens of Gems That Slows Down Our App Boot (And so I sent dozens of patches) Most of them just didn't use `AS.on_load` properly e.g.) https:/ /github.com/zdennis/ activerecord-import/pull/136
Prying out the Mechanism pry-doc takes 0.2sec to load on my MBP(SSD) When booting pry, it scans through all the installed gems and tries to require every gem that matches pry-* (see lib/pry/plugins.rb) You do not at all have to require pry-* via Bundler. You might not need them until you boot pry
Squashing All Gems Into One Directory Every RubyGem has its own path, and its own namespace inside Can’t all these gems be merged into one directory so we could make $LOAD_PATH shorter, then make require faster?
Kernel#require vs Kernel#require_relative ko1 once told me that require_relative must be faster Can we speed up Rails boot by replacing `require` => `require_relative`?
autoload in production We should better avoid autoloading in production, especially on a forked process Let’s make sure that we’re not autoloading anything
Detecting autoload TracePoint.new(:call, :c_call) do |tp| if tp.method_id == :autoload b = tp.binding case tp.event when :call p [tp.lineno, tp.defined_class, b.local_variable_get(:const_name)] when :c_call if b.local_variable_defined?(:const_name) p [tp.lineno, tp.defined_class, b.local_variable_get(:const_name), b.local_variable_get(:full), b.local_variable_get(:path)] else p [tp.lineno, tp.defined_class, b.local_variables] puts caller puts end end end end.enable
I Found 2 Occurrences When posting a form: rack-2.0.0.alpha/lib/rack/ multipart.rb:8 rack-2.0.0.alpha/lib/rack/ multipart.rb:9 There’ll probably be more?
What Was Happening "INSERT INTO schema_migrations (version) VALUES ('20160504000000');" "INSERT INTO schema_migrations (version) VALUES ('20160504000001');" "INSERT INTO schema_migrations (version) VALUES ('20160504000002');" … (600 SQLs)
If You Feel Like Your Database Cleaning Is Slow database_cleaner’s delete and truncate strategy deletes (truncates) all tables That is unbearably slow if you have hundreds of tables ✕ thousands of test cases
AS::Multibyte Consists of Multibyte::Chars and Multibyte::Unicode Loads the whole Unicode database file (AS/ values/unicode_tables.dat), which consumes time and memory I’m not sure if we still need this (doesn’t ruby have this?) I suppose we Japanese don’t use most of the features provided here
Boosting with C Extensions CGI.escapeHTML (ruby 2.3) CGI.escape (ruby 2.4) fast_blank (SamSaffron’s gem) hwia (HashWithIndifferentAccess in C for Rails 2)
YMMV There will be no one single bottleneck for every app Some apps might have 1000 models, some apps might have 3000 lines of routes.rb If you feel your Rails app is slow, you need to find your solution
Rails is Omakase It’s a really good thing for newbies that we don’t need no special configuration But in some cases we need some special customization on certain parts
Everybody Let’s Hack! There remains so many problems So many possibilities of improvements Everyone, do reveal your hacks! Let there be more alternatives That would bring the missing “Merbism” back to the community
a_matsuda
yuhta28
murabayashi
kazue
hazumirr
ogiwarat
pospome
ivargrimstad
peaceiris
stanby_inc
loic425
lhespanha
chrislema
jnunemaker
morganepeng
mthomps
cherdarchuk
lara
carmenintech
philhawksworth
marcduiker
addyosmani
brettharned
notwaldorf