Ruby Is Already Doing Very Well Even if we completely disable Ruby GC, we don't actually get that much performance gain Freezing Strings in your application code may not solve the performance problem
"Microservices" Microservices will not solve your performance problem It can be a solution for your scalability problem It would rather add some extra network overhead on your app
"Future Pattern" Thread.new { (do something) }.value Thread#value waits for the block to finish (internally with Thread#join) You can do anything else in the main thread while other threads are running
Turbo Boosting External API Calls Using Threads Push an I/O blocking task to a child Thread The main thread can do some other heavy tasks I know the reality is not that simple For example, in many cases, you will be caching some results in the client side. In such case, you need to synchronize the threads before caching But anyway, think about using threads. This is the basic idea
DB Queries Are So Time Consuming Obviously, the most time- consuming tasks in most of the real-world Rails apps It's essentially just another kind of I/O blocking task
How AR Deals with Connections AR pools the DB connections Each HTTP request kicks one Ruby Thread (or Process) in the app server AR checks out a connection from the pool per each Thread
Takes 3 Seconds for heavy_finding User 1 and 2 % rails r "User.first; p Benchmark.realtime { p User.heavy_find(1).name, User.heavy_find(2).name }" "user 1" "user 2" 3.129794000182301
We Can Do This in 2 Seconds Using Threads! % rails r "User.first; p Benchmark.realtime { t1= Thread.new { User.heavy_find(1).name }; t2 = Thread.new { User.heavy_find(2).name }; p t1.value, t2.value }" "user 1" "user 2" 2.0408139997161925
Problem with This Approach Each Thread automatically establishes a new connection You'd better use with_connection to explicitly checkout and release a connection in a Thread User.connection.pool.with_conne ction { ... }
With the Following 2 APIs: # Fires the query in a background Thread. Joins at #records call AR::Relation#future # e.g. @posts = current_user.posts.future # Runs the block in a background Thread, checking out a new AR connection and releasing it. Returns a Future object FutureRecords.future(&block)
GH/amatsuda/ future_records Very roughly implemented No tests, no documentations, no comments But it works Actually, it's already used in our production app at Money Forward Please be careful not to exhaust all the connections in the connection pool
Sharing the Main Connection Mutex.synchronize { Pass the main connection to a child thread when querying } Cannot run queries in parallel. Less performance gain Maybe we can use Thread + Fiber
Async Connection Example (mysql2) client.query(some_very_heavy_query, async: true) # This method immediately returns nil # and once the query finishes, result = client.async_result # This returns a normal ResultSet
Async Connection + Active Record + EventMachine I could kind of make this work locally, but it required super crazy monkey-patches on AR::Relation, FinderMethods, connection adapters, etc. Also, maybe we need to create another connection pool instance that handles async connections There's an existing library for doing this. Check out em-synchrony project if you're interested in this approach I personally don't want my production Rails app to heavily depend on EM though
We Often Have Slow Partial Templates render_partial of course blocks the main thread And in most cases partials do not depend on each other So, we may be able to render them asynchronously
GH/amatsuda/ ljax_rails Actually I did this 5.years.ago And realized that this is not really a good approach Because the partial needs an extra routes and a controller. It’s like creating a whole set of API for just a partial template It adds another huge overhead for Ajax roundtrip, especially on narrowband
Like This # routes.rb resources :users do collection do get :a end end # show.html.erb A <%= render 'b', locals: {async: true} %> <% sleep 1 %> # _b.html.erb B <% sleep 1 %>
Let's Check the Compiled Template Source Maybe the easiest way to show the Ruby code is to add something like puts source; puts at the bottom of the bundled actionview gem's ActionView::Template#compile
Implementation of @output_buffer.append= module ActionView class OutputBuffer < ActiveSupport::SafeBuffer #:nodoc: ... def <<(value) return self if value.nil? super(value.to_s) end alias :append= :<< ...
Immediate to_s Call is Happening @output_buffer.append= calls to_s on the future object immediately after its creation Then it causes the background Thread's join
But Why Do We Need to Call to_s There? Because ActionView::OutputBuffer < ActiveSupport::SafeBuffer < String You need to make sure that the value is_a String before <Otherwise, it may cause an error, or an unexpected result
How Can We Make Future Partial Objects Live Longer? Immediate to_s call is inevitable so far as the buffer is_a String What if we store the view fragments in an Array, then concat them at the very last?
The Array Buffer module ArrayBuffer def initialize(*) super @values = [] end def <<(value) @values << value unless value.nil? self end alias :append= :<< def to_s @values.join # or something like that end ... end ActionView::OutputBuffer.prepend AsyncPartial::ArrayBuffer
BTW, If You're Looking for the Fastest Template Engine on the current String-based OutputBuffer There's an implementation that is faster than Erubi, or Haml, or any other existing template engine in the world The gems is called string_template
GH/amatsuda/ string_template It compiles the whole template in one single String literal with interpolations Which is of course significantly faster than string << another_string << another_string...
This Happens Because of Action View's capture Helper Which is used to render the block content inside <%= ... do %> capture creates a new buffer, swaps @output_buffer ivar, then swaps it back at the end It's impossible to do such thing for a lvar
Thread Pool Implementation We can create our own Or concurrent-ruby ships with a good one concurrent-ruby should be already bundled on your app through Active Support
So, I Finally Finished Implementing an Async Partial Renderer! With a lot of monkey-patches But, this works only with Erubi so far We have so many other template engines, such as Erubis, Haml, Slim, etc. Especially, monkey-patching Haml is so tough (Even for the main maintainer of Haml...!)
With the Data % rails r '(1..1000).each {|i| Post.create! col1: i, col2: i, col3: i, col4: i, col5: i, col6: i, col7: i, col8: i, col9: i, col10: i, col11: i, col12: i, col13: i, col14: i, col15: i, col16: i, col17: i, col18: i, col19: i, col20: i, col21: i, col22: i, col23: i, col24: i, col25: i, col26: i, col27: i, col28: i, col29: i, col30: i, col31: i, col32: i, col33: i, col34: i, col35: i, col36: i, col37: i, col38: i, col39: i, col40: i, col41: i, col42: i, col43: i, col44: i, col45: i, col46: i, col47: i, col48: i, col49: i, col50: i, col51: i, col52: i, col53: i, col54: i, col55: i, col56: i, col57: i, col58: i, col59: i, col60: i, col61: i, col62: i, col63: i, col64: i, col65: i, col66: i, col67: i, col68: i, col69: i, col70: i, col71: i, col72: i, col73: i, col74: i, col75: i, col76: i, col77: i, col78: i, col79: i, col80: i, col81: i, col82: i, col83: i, col84: i, col85: i, col86: i, col87: i, col88: i, col89: i, col90: i, col91: i, col92: i, col93: i, col94: i, col95: i, col96: i, col97: i }'
IMO Active Record Model is Designed to Do Too Much Work What we really need here in this situation is just a value object (something like "entity bean" in the Java world) AR model is apparently an overkill for this usage AR object has too many features such as type casting, dirty tracking, serialization, validation, etcetc.
AR Implements Two Different Roles in One Class Data transfer object that transfers readonly data between MVC layers Form object that accepts user inputs and safely saves them to the DB
It Should Kinda Work for a Simple Use Case Like the Example in This Slides But we don't want to do that in Ruby. Ruby is not Java. And we want to use associations, some other methods defined on the model class, etc. And it won't play nice with our favorite decorator plugin
Instead, Why Don't We Just Store the Attributes as a Hash Instance? And just delegate the attribute accessors to the Hash instance? (Actually, AR used to be designed that way)
Can’t We Opt-out This Rarely Used Feature? And let AR objects work speedily by default? It's great that AR has a lot of elegant features, but we want the model instances to perform as fast as possible by default
If The Model Declares No Custom Attribute, Return a Good Old Simple Hash Based Model Instance I suppose this would speed up 99.8% of AR models in the world
An AttributeSet Alternative That Simply Delegates to a Given Hash Attributes module LightweightAttributes class AttributeSet delegate :each_value, :fetch, :except, :[], : []=, :key?, :keys, to: :attributes def initialize(attributes) @attributes = attributes end def fetch_value(name) self[name] end ... ennd
An AttributeSet Builder that Builds the Lightweight AttributeSet when Building an Instance from DB Query Result module LightweightAttributes class AttributeSet class Builder ... def build_from_database(values = {}, _additional_types = {}) LightweightAttributes::AttributeSet.new values ennnnd
Overriding AR::Base.attributes_builder to Return the Lightweight AttributeSet Builder module ARBaseClassMethods def attributes_builder # If the model has no custom attribute if attributes_to_define_after_schema_loads.empty? LightweightAttributes::AttributeSet::Builder.new(...) else super ennnd
Other Possible APIs Add a new method on AR::Relation that returns a lightweight Model collection, and don't change the default behavior Change Relation#readonly method to return a lightweight Model collection
What We Learned (1) If you have external API calls in your app, consider doing them in child threads You can run AR queries in Threads, but be careful not to use up all pooled connections ActionView::OutputBuffer can be Array based, for some future extensions Monkey-patching Haml is hard LazyAttribute is so lazy, and opting this out may drastically boost the performance url_for is slow, and we need to fix it
What We Learned (2) You can find what’s slow in your app And YOU can fix it If the problem lies inside the framework, just hack the framework It should be fun!
What We Learned (3) Performance is not for free There are certain trade offs In Rails' case, we need to craft so many evil monkey-patches Maybe because the framework is not flexible enough
What We Learned (4) Thread programming, especially debugging is hard I don’t wanna do this anymore I'm really looking forward for the new Thread model planned to be introduced in Ruby 3
Future Plans Finish implementing the plugins that I introduced today All these plugins are experimental. They basically have no tests, no documentations, no comments at the moment Put them in actual production apps I'm sorry but the title of this talk was probably a little bit misleading Introduce more extensibility to the framework I realized some things that should better be changed in the framework side rather than in monkey-patch plugins
a_matsuda
ayaka1230
77web
yosuke_furukawa
prof18
umizaru
ksudate
nearme_tech
koba04
dalance
mraible
heronshoes
sachag
yeseniaperezcruz
chrislema
paigeccino
erikaheidi
soudai
searls
keavy
mclloyd
cherdarchuk
bkeepers
zakiwarfel