Frontend slow - working with DPU configurations

[tomas-knap]

PROBLEM je, ze ODCS GUI je stale silene pomaly. Mam na ODCS pipeline - [CZSO] Public DB - Demography. Je tam vlozeny i to novy DPU. V jeho config dialogu, kdyz se snazim pridat radek do nektere z tech tabulek tam (tlacitka Add mapping), tak po kliku na to tlacitko trva klidne i minutu ci dve (napsal jsem za tu dobu tenhle mail), nez GUI zareaguje a prida novy radek. Takhle to bohuzel pouzitelny neni, protoze netrpelivej clovek jako ja se muze taky zblaznit :-(.

1) I pri kliknuti na tlacitko uvnitr DPU config dialogu se porad toci kolecko vpravo nahore - v situaci, kdy by podle me vubec nemela probihat komunikace se serverem. Kolecko se toci, nic se nedeje. Co to znamena? 2) Kdyz neco trva moc dlouho a opakovane to tak trva, tak jdu proste v novym okne na homepage a vse zas chvilku bezi docela rychle. Divny ne?

@bogo777 Any suggestion what might be the cause?

[tomas-knap]

@martinnec When the gui was slow, were there other pipelines running at that moment?

[martinnec]

Sometimes, GUI responses quickly. However, few minutes later, I have to wait up to one minute or two until something happens. GUI _HAS TO BE_ independent of the backend!

[bogo777]

In almost all views is periodic automatic check for changes, followed by refresh when needed. If even the simple query there takes long, it can result in slow response, as those checks can stack up. We could propably add test, if previous check is finished and if not, don't start another.

This could increase responsiveness of GUI, but it only hides the fact, that the database is flodded/slow.

[ghost]

@martinnec It is not happening after DPU jar replace, is it? See this issue: https://github.com/UnifiedViews/Core/issues/3

[tomas-knap]

@bogo777 How often is the database contacted to get information whether the canvas was not updated by another user? Futher, how is it done? Gui is actively waiting for the result of the check? It should be checked in background and when the response is ready and the response says that somebody has changed the canvas user is editting, then gui/user is notified.

[skodapetr]

WARN: I assume there was only one user online! But the queries was against one pipeline and I expect that Martin would tell us if there were more users on his pipeline.

Well I try to examine the log and from what I see .. the refresh (Open pipeline checks) is was quite was .. but sometimes more of them goes one after another .. like one checks ends and one second later start another (I also got only rough times as the logs does not contains information about start and end of a request .. so it's possible that from user point of view it was one log "check" ) .. on the other hand sometimes the there was about 10 seconds gap between the checks.

So basically it does not seems to me like a problem with slow query, on the other hand we may always try in-memory storage for this kind of information.

PS: Sometime during debugging .. I pause the application for a quite a long time .. and then I have to wait until all the "updates" are proceed .. so prevent updates from stacking up is imho a definitely right event when it does not solve this issue.

PPS: I ask Martin about the color of the update "icon" and he said "white". I thing that this point to stacked up updates. As it a single update takes too long it has a red color.

[tomas-knap]

Ok, so the solution is to introduce proper timing of check requests? So that every new check starts not earlier than after X seconds after the previous.

[skodapetr]

I think it might help .. but I have no detail knowledge how does the "update" component works ..

[tomas-knap]

@bogo777 Can you please look on that? If you find out it is too complicated, please send us the detailed set of changes needed.

[bogo777]

I added minimal interval between refreshes, i.e. new refresh is not started, if there is not enough time between the last refresh finished and now. This should solve the stacking of check requests...

[tomas-knap]

It is better, but still sometimes gui is slow. But this is probably caused by slow db queries. Examine the queries being executed for getting pipeline detail, pipeline list..