[ACE-4371] BM-0013: Soak: V420b243_031: Regression detected in document details render time Created: 27-Aug-13  Updated: 06-May-20

Status: Open
Project: Alfresco One Platform
Component/s: Benchmarking, Document Library
Affects Version/s: 4.2, 5.1
Fix Version/s: 5.N

Type: Bug Priority: Critical
Reporter: Derek Hulley [X] (Inactive) Assignee: PM Unassigned (Inactive)
Resolution: Unresolved Votes: 0
Labels: triaged
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 30 minutes
Original Estimate: 0 minutes
Environment:

BM Lab


Attachments: Microsoft Word 1.4.bm0013.v420b1453_04.results.csv     PNG File ALF-19836-long-wait.png     JPEG File Render-times-off-the-wall.jpg     PNG File SpinningDocumentPreview-2014-01-20.png     PNG File v420b1453_04_result_1000_50.png    
Issue Links:
Dependency
Depends on ALF-19700 BM-0013: Soak: V420b227_03: Transform... Closed
Duplicate
Related
is related to by ACE-4067 CLONE - BM-0013: Soak: V420b227_03: T... Open
Regression:
Regression

 Description   

Displaying document details is taking a long time.
The automation code is including the time it takes the previewer to resolve to something.
It is quite likely that recent transformer upgrades and changes have caused the delays to increase on the page.



 Comments   
Comment by Derek Hulley [X] (Inactive) [ 04-Sep-13 ]

"I've had a conversation with Brian and given that this appears to be a limitation of the test tool rather than a problem with Share itself..."
Old data: WEBDRONE-146 only added a fraction of a second to the overall issue. Naturally we checked the tool first.

1) The tool has the limitation in that it includes the time it takes to do something in the preview pane. But my opinion is that this is correct i.e. a spinning icon on a page means the page is not finished loading. The rest of the links are usable but ignoring slow bits on a page is pointless if we're actually doing load testing. This is a regression over 4.1.5 and not really a Share problem.

2) Yes. The data is genuine. 20+ seconds and it's regressed since we installed the new transformers. I can demonstrate it and we can watch the spinning icon together.

3) Yes. It's dependent on the type of file being previewed. Plain text files and word docs present particular problems.

Please have a conversation with me. I merely want to find out what options there are should someone decide that 30s spinning icons are acceptable on the UI for plain text previews - they're not, of course!

Comment by Derek Hulley [X] (Inactive) [ 04-Sep-13 ]

Mike Farman, Will Taylor [X] and Brian Remmington
Hi, All
The overall rendering time of the document details page is increased by the document preview taking a long time. This is a regression in the product. In my view, it does impact users - what is the preview there for if not for the users to view? Others may have different opinions, which is why I'm handing it to you to get some action.

The most likely cause is that the transformations to thumbnails are slower (see related issues). We are having quite a few transformation issues with this release and also with 4.2.

Comment by Derek Hulley [X] (Inactive) [ 04-Sep-13 ]

The performance of the underlying document transformation is not a UI issue per se.

This is a regression over 4.1.5 and not really a Share problem.

There is no Share issue as far as the user is concerned. For automation code, we have some technical problems if we choose to ignore the preview pane, which is why I was asking for some technical advice there. No bug in Share - just some help needed. Bug is in transformations. UI team can leave it and we'll chat when we see each other.

Comment by Derek Hulley [X] (Inactive) [ 04-Sep-13 ]

share.doclib.selectFile ~ 30s.
Look at spreadsheet: https://ts.alfresco.com/share/page/site/bm/document-details?nodeRef=workspace://SpacesStore/326bb246-1f46-474b-b9d8-8d5c0c7f5c32
The "data" tab, then the averages for "share.search.selectEntry" for the different releases.

The transformation server has been upgraded for 4.1.6 and 4.2.0.

Comment by Derek Hulley [X] (Inactive) [ 04-Sep-13 ]

Currently awaiting further investigation on ALF-19700.

Comment by Mike Farman [ 04-Sep-13 ]

Talking to Derek, there is a theory that the Transformation Server is being used for many more transforms (like image stuff) than previously and therefore could be being overwhelmed with requests. I guess this could be expected, there must be a point where it can't keep up. This means everything is getting backed up and that's where the time is going. It's a theory right now, hence the need for investigation, it could be wrong!

If it is simply being caused by the extra load being put on it, then we're not really comparing like-with-like. We shouldn't really expect it to perform the same way if it's being asked to do more and is hitting a limit. I thinking it may be acceptable to configure in additional Transformation Servers and load-balance across them, this is how it's designed to be used. On the other hand, maybe the transformation server itself could handle the requests more efficiently, again, something we should probably investigate.

Comment by Derek Hulley [X] (Inactive) [ 04-Sep-13 ]

Extra load on the TS is not necessarily a good thing. The changes were unanticipated and the fallout was excessive (see related BM-0013 issues about errors in the logs, etc). We'll go for an investigation into how to get back to where we were i.e. everything worked nicely without timeouts, errors in the logs and spinning UIs.

Then we'll get the TS options baked in so that customers don't have to double the TS machines just to get back to normal operation.

Comment by Mike Farman [ 04-Sep-13 ]

I think the changes were made to the TS because, for other use cases, the overhead of those transformations still taking place on the repo server were causing a problem. Seems to me that if we can control which transforms run local or remote (I think that's the case), we can use configuration to have like-for-like numbers for 4.1.5 and 4.2. Does that make sense? There's also a question on what the defaults should be if the theory is correct, sounds like pushing everything remote may not be the best default.

I'm now also wondering what type of testing is being done before the TS gets handed over to us. We need to do our own benchmarking, but it should also go through scalability testing before it gets to us. I'm not sure what tests are being done right now.

Comment by Derek Hulley [X] (Inactive) [ 11-Sep-13 ]

Correct. See comment.

Comment by Derek Hulley [X] (Inactive) [ 12-Sep-13 ]

Thank you.
I am glad that the properties make a difference. That is a start.
Please rerun and generate profiles. Upload those and let us know. Then see if you can isolate the transformation code paths. We need to see where the time is disappearing ... locally or remotely?
And give the transformation machines a bounce, and clean up.

Comment by Derek Hulley [X] (Inactive) [ 02-Oct-13 ]

See Alan's comment, which puts context to the decision to move this to 4.2.N.
Investigation of why some (pre-existing) documents get sent to the TS after 4.1.5 will be required. That being said, the transformation times should not have a bearing on our overall transformation throughput.

I don't believe we'll solve this one with the two transformation servers we have.

Comment by Derek Hulley [X] (Inactive) [ 20-Jan-14 ]

Soak testing on V4.2.1 show consistently slow Document Details render time due to the document preview taking a long time. Naturally, this is dependent of whether the document preview has been hit before, etc. I'm attaching a file .

Generated at Mon Jul 13 10:11:05 BST 2020 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.