Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.