mtierltd
Timer, speed when saving or changing
It takes a long time for a task to start in the timer. The same gild for changes. The data is provided faster in the report. Nextcloud runs in a Docker container with Maria database.
Can you give a little more information like, is NC installed on Docker, What OS you are using, which PHP version, how many projects you have to track. This would be helpful.
Thanks
Thank you for the willingness to help me with my problem. TimeTracker is a very good time tracking tool for us. We want to use it more. Enclosed the detailed information about the system and software environment. Thanks for your help!
NAS
Modellbezeichnung Qnap TS-677CPU AMD Ryzen 5 1600 Six-Core Processor (6 Kerne, 12 Threads) Gesamtspeicher 40 GB (39 GB nutzbar) Speichersteckplätze 4 (16 GB / 4 GB / 16 GB / 4 GB) Firmware-Version 4.4.1.1216 Build 20200214
Docker
ContainerStation Version 2.0.957
Container: Nextcloudweb_1 nextcloudletsencrypt-companion_1 nextcloudapp_1 nextcloudcron_1nextcloudproxy_1 nextcloudredis_1nextclouddb_1 nextcloudcollabora_1
Nextcloud
Nextcloud Version 18.0.1
PHP
Version: 7.3.14 Arbeitspeicher-Grenzwert: 512 MB Maximale Ausführungszeit: 3600 Maximale Größe zum Hochladen: 2 MB
Datenbank
Art: mysqlVersion: 10.4.8, Größe: 318,8 MB
TimeTracker
Projects = 18 Clients = 15 Tags = 13 Tasks = 73
@bwie starting and stopping a timer should happen instantly. I suspect there is a configuration issue (like maybe the nextcloud server tries to resolve the mariadb server by name and it takes a long time?). The starting (or stopping of the timer) is just a matter of posting a ajax query to the server which in turn does a simple insert (or update) in the database. This normally happens in a matter of milliseconds.
Do you have a lot of timed tasks showing up? I found that the more I had, the slower the response. It's much faster when I just make it retrieve the last 7 days only (manual edit)
i'm facing this issue as well. I've not that much entry but it needs unreasonable more time with every entry.
i'm currently working on #37 in a separate test-app i'll check if it is the same with changed rendering.
It still is the case. I believe it's an issue related to the ajax refresh whenever something is updated. If you start a work interval, it sends the message to the back-end, then does a full refresh of all the work intervals (slow). If you end a work interval, it sends the message to the back-end, then does a full refresh of all the work intervals. The same for any text or time update.
I circumvent this by setting it to only retrieve the last 7 days, but it's still a minor inconvenience. Does it really need to do that refresh every time? The UI should already reflect the changes based on the user's actions, so if it could be skipped, it will feel a lot more snappy.
I also find starting and stopping very slow, often several seconds. My setup is Nextcloud 20.0.4. PHP 7.3.19; mysql 10.3.27. @puthre: the (possible) fix is not in the app store yet, it seems?
This seems to get worse. It now often takes more than 15 seconds to respond when I start or stop a timer or delete an older entry. Also Firefox gives me a warning "the website is slowing down your browser" and resource usage goes up to 30 or 40%. So the problem must be somewhere in the browser code, not the server scripts or database access.
It wasn't so bad before, but I don't know if this was due to code changes or because I now have more entries or something else.
Is there anything I can do to help diagnose this?
This is related to the number of entries that are shown in the timer view. If I set the filter to "today" (8 entries), then starting/stopping takes about 1 second, if I set it to "last 5 years" (a few hundred entries I guess) then it takes 40 seconds.
@puthre I now tried it on different systems.
Firefox 84.0 64 bit on Windows 10, and also Microsoft Edge, in both it takes about 15 seconds to start the timer when entries for the the last month are shown. The computer is an Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, a few years old but generally decent and very snazzy even with large programs like the Adobe Creative Suite.
On a tablet (Samsung Galaxy Tab 10 2019) it takes 22 seconds on Chrome and 34 seconds on Firefox. So Chrome is perhaps somewhat faster but 22 seconds is still really far too long.
@smatthie How long does it take for your server to respond to the work-intervals ajax call in these circumstances?
@puthrie around 150 milliseconds, I think. However I'm not totally sure I'm looking for the right thing here; I'm checking this with the Firefox network analysis tool. The get request
https://[myserver]/apps/timetracker/ajax/work-intervals?days=1828 gives 153ms for waiting and 1ms for transmitting the response.
I can see the returned json data in the network tool almost immediately, but it takes then half a minute before it is rendered on the website.
as i wrote earlier: i'm pretty sure that the rendering with the actual Table-Framework needs most of the time. i've changed the most of the app to VUE.js for rendering and its much faster. I couldn't rewrite it complete in VUE.js because i didn't understand the meaning of some navigation-entrys in the left of the app but maybe someone else could do that or even explain me what Timeline (Admin) should stand for.
I also could provide you with the source-code of the changed app.
The issue seems to be a combination of a dated cpu with the instancing of hundreds (or maybe thousands) of select2 controls for tags and project editing. As a comparison it takes 3 seconds to render for edit the last 300 work items on a previous generation AMD Ryzen 5 3600 CPU on linux chrome. Now the obvious workaround when you work on older (and/or mobile?) cpus is to not start the timer when editing the full month/year of work items. I'll try to optimize the code that gets executed for each work item but my profiler suggests that most of the time is spent in controls initialization for each of the work items and there is not much I can do there.
Well, I bought the tablet only last year so it's not exactly "old", and my laptop is not so old either and is totally capable of running the huge Adobe Creative Suite with big layout-heavy files without any noticeable delays. I work every day on both machines with all sorts of fairly big programmes and they are all fast and responsive.
So I don't think it is acceptable that rendering a simple web table will take so long. You can't expect everybody to have always the latest, fastest and most expensive machines.
Even with the default filter of 30 days (that I get automatically when I switch to the view) it takes about 15 seconds to render, and often more (because the way I work I get easily 10 or more work items per day). 15 Seconds is just manageable, but really too long and very annoying when you're body working and use this many times per day while you're concentrating on important work.
So I don't think it is acceptable that rendering a simple web table will take so long.
The issue here is that what you get it's not a "simple web table", on the contrary it involves complex widgets that can automatically get and filter dynamic data from the server.
You can't expect everybody to have always the latest, fastest and most expensive machines.
I don't, and I'll try to optimize as much as I can what I can. However, faster machines DO work faster :) and newer components are written with the future in mind, not the past.
@puthre Sorry that my tone was a bit rude, I apologize for that. I don't want to discourage you and I know you're fixing a lot of issues.
How about: Instead of showing a lot of widgets for every entry, would it be better to have a plain list and only have an edit dialogue for an individual item when you click on it? I would actually prefer that you can change description, tags, times etc in a single dialogue for an item. But keep the "restart" button for each item.
I'm also affected by this problem. And of course, this is not a "simple web table", but it is not the most complex of all webapps either. I'm using way more complex web applications on my desktop machine. For me, the delay not only occurs when loading the page, but also a multisecond delay on each action, e.g. starting / stopping the timer, changing description or times, choosing a category or assigning tags.
Of course, this is an open source project, so I don't expect anyone to fix this problem right now :) But I want to point out that this is indeed an issue.
@digger-bw Can you make your re-written code available? I'd be interested in trying in, as this issue is really quite annoying.
@smatthie if you can access and build your code you can simply uncomment lines 420,473,474, 479, 519 and 520 in /js/src/timer.js. You will have to recompile your js files in js folder by running npm run build (when in /js folder)
This will initialize the select2 controls asynchronously so the page will be responsive immediately if your system is slow. However it will also introduce a flicker that some might consider annoying as the controls layout will change as you continue your browsing.
@puthre Super, thank you, I will try that in the next few days when I have a bit of time and see how it goes.
@puthre Thank you, I tried the workaround you suggested and these changes make it much more useable and responsive for me. I don't mind the flicker when the controls are changing, although I see this might be distracting to others, so it might not be a solution for everybody.
This seems to be much faster now and, at least for me, is resolved.
I just updated to standard 0.0.71 through the app store from an older self-compiled version (possibly 0.0.53 I think where I had applied the fix you suggested above), and now it only takes 1 or 2 seconds rather than the old 30-40 seconds for the page to build up.
As I skipped a lot of versions in between (due to holidays and not using the computer) I don't know which version fixed it, but I'm very happy now.