Bug 1383465

Summary: Improve performance by skipping asset pipeline resolution for Service nodes
Product: Red Hat CloudForms Management Engine Reporter: Satoe Imaishi <simaishi>
Component: PerformanceAssignee: Nick LaMuro <nlamuro>
Status: CLOSED CURRENTRELEASE QA Contact: Shveta <sshveta>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.7.0CC: cpelland, jhardy, nlamuro, obarenbo
Target Milestone: GAKeywords: TestOnly, ZStream
Target Release: 5.7.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.7.0.3 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1383469 (view as bug list) Environment:
Last Closed: 2017-01-11 19:57:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1383469    

Description Satoe Imaishi 2016-10-10 17:35:41 UTC
From PR: https://github.com/ManageIQ/manageiq/pull/10929

we are using customer images from the DB when rendering trees like the /service/explorer. The cached hash ends up looking something like this:


  "../../../pictures/XXXr1.jpg" => "/images/100/../../../pictures/XXXr1.jpg",
  "../../../pictures/XXXr2.jpg" => "/images/100/../../../pictures/XXXr2.jpg",
  "../../../pictures/XXXr3.jpg" => "/images/100/../../../pictures/XXXr4.jpg"


This means that these will not end up on the file digest of sprockets, and thus cause some slow down.

Comment 3 Shveta 2016-10-31 13:43:08 UTC
Hi Nick , 

Can you please tell me how to verify this bug .

Thanks, 
shveta

Comment 4 Nick LaMuro 2016-10-31 15:49:33 UTC
Hi Shveta,

This "bug" (I would call it more a performance fix), will present it self if you go to, say, the `/service/explorer` with a lot of services that all (or at least most) have custom images attached to them.  The custom images, for each service, would need to do a directory scan that was unnecessary to determine the URL for displaying the image.

I was testing with a database that had about 9.5k services in it, and all of them had a custom image attached.  When testing against that database locally, I was seeing about 7 seconds for rendering the page on the backend, and with this patch in place, the time dropped to about 2.5 seconds.

Keep in mind that this is more noticeable when there is a large number of services to render in a tree.  If there is less, the amount of times this calculation had to be done is decreased, so the improvement is less impactful, but the result should be the same regardless.  This is a fix specifically for users with a large DB.



Thanks,
-Nick

Comment 5 Shveta 2016-10-31 16:36:52 UTC
Verifying based on above comment as a DB that big is difficult to recreate.
5.7.0.7-beta1.20161025153249_9376fbd