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

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.

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

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 ?

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.

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.