To homepage To homepage
Solved

TimeXtender UI is intermittently slow

  • 11 May 2023
  • 6 replies
  • 158 views
R
Rank

Hello there, we’ve been experiencing intermittent slowness in the TimeXtender UI within the past few weeks.  Even doing simple things like right clicking on a execution package to view the logs, trying to see the status of an ODX transfer job, etc. will sometimes cause the UI to feel like it’s just not responding (no lotus status UI) for 30 seconds to minutes.

This isn’t something that happens all the time and we haven't been able to nail down a root cause.  
Our VM where the UI is running is rarely over 30% CPU usage and we usually have over 80% memory free.  Same goes for the VM that the ODX is running on.  

How do you even begin to troubleshoot this when the UI is slow to respond?  

The TimeXtender UI is on version 20.10.38.64.  
The TimeXtender ODX server is on version 20.10.37

Thanks!

icon

Best answer by rory.smith 12 May 2023, 09:18

View original

6 replies

Christian Hauggaard
Rank
Userlevel 6
Badge +5

Hi @robert.kangas 

TimeXtender records details of every execution. These logs can result in growth of the TimeXtender repository database, especially if your projects have execution packages that run more than once per day. Removing older logs can help reduce the repository's size. Can you please try removing some older execution logs? For more information see this article

rory.smith
Rank
Userlevel 5
Badge +7

Hi @robert.kangas ,

in addition to Christian's suggestion: if your project has many versions stored in the repository database this can also contribute to slowness. That can be reduced by going to a new repository database. If you are running your repository database server on-prem / IaaS, you might also have a rather large log file if your database configuration is not optimal.

Christian Hauggaard
Rank
Userlevel 6
Badge +5

Hi @robert.kangas were you able to resolve the issue based on the answers above? If so, please help us by marking a best answer above. Please let us know if you have any follow up questions

peter.jensen
Rank
Badge +2

Hi @Christian Hauggaard , @rory.smith 
In the initial question, @robert.kangas  also speaks about performance issues when looking at ODX Server logs (e.g. ODX transfer job).  I thought these logs are not stored in the TimeXtender repository DB, but in the Online ODX Server repository (and synced into the local SQLLite DB on the ODX Server VM).
This would mean that not all mentioned GUI performance issues are related to the TX Repository DB. - Or am I wrong ?  What could then be the reason for these performance issues ?

Peter Jensen (element61)
rory.smith
Rank
Userlevel 5
Badge +7

Hi @peter.jensen ,

the ODX Server has a few points where UI response can be slow that I have noticed:

  • the first time you click a data source under Manage ODX  “something” happens and can take a few seconds (new release) before the UI responds
  • queries on the local SQLite DB can be slow if the database becomes large. I suspect this is a function of the number of sources, tasks, task schedule frequency, etc. Doing anything custom on this database is also tricky as it is not set up for concurrent work (but is the best source for detailed metrics). SQLite is typically not very performant either: it could be that users trying to request logs while something else is going on (a different user doing things, a task running) bogs down the SQLite DB
  • (transient) network performance between TX client machine and ODX Server machine and/or between ODX Server machine and the hosted cloud repository.

But very often there is not that much maintenance being done on the main repository DB which can then slow pretty much everything down. I assume the duration results of an ODX → DWH transfer are also stored in the main repository for the table being executed in the DWH for instance.

P
Rank
Userlevel 3
Badge +1

Hi @robert.kangas,

We are also experiencing TX (version 20) being intermittently slow. The storage for our dev and prod DW’s, as well as the storage for both repositories is an on-prem SQL Server.

We have noticed that slow response times from the UI coincide with heavy loads in the prod environment. Our suspicion is that simple “repository operations”, e.g. calculating differential steps for a table deploy, competes for resources with heavy executions in production. 

We are planning on moving the repository databases to their own SQL Server to test this theory. 

Reply


Terms and ConditionsCookie settings