Closed saracarl closed 7 years ago
We're seeing very slow performance generating the IIIF manifest for works with a lot of pages. So: http://fromthepage.com/iiif/for/https://data.ucd.ie/api/img/manifests/ivrla:1602 takes 10s of seconds.
@tbl73 can we look at the iiif controller for the performance improving opportunities in particular?
I'm thinking here might be ad good first candidate:
https://github.com/benwbrum/fromthepage/blob/master/app/controllers/iiif_controller.rb#L250
@saracarl - I commented in #596, which appears to be the same issue on IIIF manifest generation.
We're implementing a change to the IIIF manifest generation to improve performance, which is discussed further in #596. Some other places we think might benefit from joins/includes as discussed above are the export controller, deeds controller, dashboard controller, and possibly the update_statistics and tex_figure processing (both triggered on page saves), so those are the areas that will be investigated next. This is a link to a Rails guide to performance testing, which seems like it could be useful in this effort: http://guides.rubyonrails.org/v3.2.13/performance_testing.html.
Here's the thing that I've been seeing. Let's say you've got a parent object or better, a child object so, say, you have a list of deeds, and you want to print each deed, and its user If you say Deeds.all.each { |d| print d.user.name } It's going to do a SELECT * FROM USER WHERE .... for each deed Even though it could could join DEEDS to USERS in the original query. So any time you loop over a result set, you execute a new query N (or more) times There's an ActiveRecord method called include (or "includes"?) that should do the join fo ryou. So Deeds.all.includes(:user).each { |d| print d.user.name } There's also an ActiveRecord method called "join" (or "joins"?) that's similar. I think that understanding those and implementing them may be the next place we should focus
http://guides.rubyonrails.org/active_record_querying.html#joining-tables