Skip to content

Instantly share code, notes, and snippets.

@jrochkind
Created July 18, 2017 14:20
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jrochkind/6c3f4ef347347327f5979c422617cf1c to your computer and use it in GitHub Desktop.
Save jrochkind/6c3f4ef347347327f5979c422617cf1c to your computer and use it in GitHub Desktop.
profiling slow sufia show page

Sufia 7.3 curation_concerns/base/show.html.erb

We’ve customized this page, but like the original, it lists all members (for the purpose of this profile all filesets), without pagination, with some metadata and hyperlink actions, along with some cancancan guards for some of them. I’m not sure if the original uncustomized would have exactly the same performance characteristics — it’s possible we’ve added more calls to metadata attributes and generation of hyperlinks than the original.

We have already implemented the Solr fetch n+1 workaround. Adapted from https://github.com/pulibrary/plum/blob/master/app/factories/efficient_member_presenter_factory.rb.

This profile is of a sample work with 200 file set members — with each page of a manuscript being a member, we do have works with 200-400+ members in our actual data. This profile was done with production-like config, and after a few requests were made to warm things up.

This profile is not of the whole action/render, but just wrapped around what I identified as the “hot spot” — around the each loop over the 200 members, inside of which each is rendered (using some partials).

After identifying the ‘hot spot’ basically manually (deleting parts of the templates until I found the slow part), I tried doing the same inside the ‘hot spot’, but couldn’t find a slow part — deleting code sped things up, proportional to how much code was deleted, with no code seeming (from manual investigation) to take up a disproportional share.

At that point I went to ruby-prof.

It appears to me from this profile that Solrizer.solr_name is taking an unusual amount of time. especially from the “GraphHtml” report. 28% of total time spent in Solrizer.solr_name. I personally have more trouble interpreting the “CallStack” report.

It’s not clear to me what makes Solrizer.solr_name so slow. It is clear why it’s called a lot though. Solrizer.solr_name is called every time you ask for nearly any attribute of any show presenters (work or fileset). Attributes delegated to :solr_document end up calling Solrizer.solr_name (I think caught by method_missing?). And curation_concerns solr_document_behavior.rb (which is mixed into both show presenters) defines things like hydra_model and title in terms of using Solrizer.solr_name as well.

I’ve just begun trying to figure out how to deal with this on the assumption it is Solrizer.solr_name, so it either needs to be called less often or optimized. But my initial attempts don’t seem to be resulting in much speed up. It’s possible I am misinterpreting the profile.

https://jrochkind.github.io/GraphHtmlPrinter.html

https://jrochkind.github.io/CallStackPrinter.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment