Distribution pages are wicked slow

[dorner]

Summary

Viewing or updating distributions is incredibly slow - we are seeing an average of about 15-20 second load time. Let's speed this up!

Things to consider

No response

Criteria for Completion

No response

[johanbtrg]

Hello! @dorner can I take It?

[dorner]

Please do!

[manuel1280]

Sorry @dorner Can you reassigned It to this profile please. I was in the wrong account

[manuel1280]

Hi @dorner , I have a question. On average, how many distribution items are there per distribution? The bigger problem that I see is there isn't pagination for distribution items. When I view or update a distribution with 20 or 100 items, it works fine. However, when it's a huge amount, like 500 items, it takes a long time, as you mentioned.

I saw other code refactors but they dont have a sifnificant performance impact

[dorner]

The number of items is usually very low. The biggest I could find was about 30 or 40 items.

[manuel1280]

Ok, Im going to do the code refactors

[manuel1280]

Hello @dorner, I've seen that you are familiar with the code, so I'm refactoring the query to retrieve distributions with this new scope in distribution.rb.

scope :selected_attributes_by_id, ->(id) { includes(:line_items).includes(:storage_location).includes(:items) .select( :agency_rep, :comment, :created_at, :delivery_method, :id, :issued_at, :organization_id, :partner_id, :reminder_email_enabled, :shipping_cost, :state, :storage_location_id) .find(id) } Here, I added the corresponding .includes and limited the attributes for use in show, edit, and update actions. This has improved performance a bit. However, the major refactor would involve changing the logic to update the line_items_attributes, updating only the line_items modified instead of all of them as is happening now, even when they don't have modifications.

That refactor is big, but what do you think, Do you have some ideas to refactor?

[dorner]

I'd have to look at the flame graph to see what's actually going on. It definitely seems like a lot of queries even on a simple create (I see traces of > 10 seconds).

Btw, I wouldn't put all the includes etc. in a scope, that's pretty big for that. You can make it a class method instead.

[manuel1280]

Hi @dorner, I'm looking into 'create' flow, but It would be too helpful to see the trace of the flame graph. Looking forward to it

[dorner]

@manuel1280 you should be able to create the flame graph yourself using tools like RBSpy: https://rbspy.github.io/profiling-guide/using-flamegraphs.html

[github-actions[bot]]

This issue is marked as stale due to no activity within 30 days. If no further activity is detected within 7 days, it will be unassigned.

[github-actions[bot]]

Automatically unassigned after 7 days of inactivity.

[manuel1280]

Hi @dorner

I've analyzed the flamegraph and utilized stackprof for GET requests (view, edit, show). I've implemented small performance optimizations that would be worth. For instance, on the edit response went from ~500 to ~300 milliseconds.

for performance improvements on update and create, I consider It's necessary to figure something out to send and process only the modified items, in order to avoid redundancies.

I would like to start with a PR for these small refactors as an GFI. What are your thoughts?

Thanks!

[dorner]

I think it's worth a shot! If you put up your PR, I can grab it with production data and test response time with and without the changes to see if it's a significant difference.