Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

History tab very slow #625

Closed
johnarnold opened this issue Nov 22, 2018 · 5 comments
Closed

History tab very slow #625

johnarnold opened this issue Nov 22, 2018 · 5 comments
Assignees

Comments

@johnarnold
Copy link

The st2web History tab is very slow to interact with. For example, click to expand a workflow and see underlying actions can take 30+ seconds, sometimes much longer. Can't effectively use the search or filter fields as they are slow/unresponsive or we get unexpected behavior (click to search, panel reloads).

Stackstorm 2.9.0, Ubuntu 16.04, Chrome 60.0.3112.78

We have a scaled out deployment with (4) VMs, 1PPC docker containers, ~9 worker processes for gunicorn stuff (st2web/st2auth/st2api). Overall utilization on the VMs is very low <10%

Using chrome's Developer Tools, I observe that it spends the most time on loading things from /api/v1/executions

image

@Kami
Copy link
Member

Kami commented Nov 22, 2018

We included some of the improvements for that in v2.9.1 release - #605.

Can you please try with st2web v2.9.1 and report back?

@johnarnold
Copy link
Author

@Kami I upgraded to 2.9.1 over the weekend. Still slow.

root@45208c6fa393:/# st2 --version
st2 2.9.1, on Python 2.7.6

@Kami
Copy link
Member

Kami commented Dec 13, 2018

@johnarnold Can you please provide some screenshots of the Chrome network tab so we can see what is going on?

It would also help to know how big are the executions which take a long time to load - is the result large? How large?

Thanks

@Kami
Copy link
Member

Kami commented Feb 14, 2019

To add some context - improvements we did refer to the initial history page load. There we only retrieve fields we need and that should be much faster in StackStorm >= v2.9.0.

Another problematic view is execution "drill down" view aka when user clicks on an execution to expand it.

We should perform the same include attributes filtering there and only retrieve "result" field once user clicks on a specific execution and that execution is actually displayed in the right tab (and we should probably only do this for child executions and not massive Mistral workflow executions which contains all child data and could be massive).

/cc @VineeshJain

@Kami
Copy link
Member

Kami commented Jun 20, 2021

There are still some edge cases where we try to render large results which can freeze the browser window, but #868 and related changes should mostly fix this issue.

@Kami Kami closed this as completed Jun 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants