In case of a lot of traces the UI hangs for a bit

[zstadler]

What is the problem this feature will solve?

It takes more than 10 second for the "My Recordings" list to be ready., i.e., the spinner stops.

What is the feature you are proposing to solve the problem?

Allow the client to cache the pictures it receives from the server

What alternatives have you considered or tried?

None

Additional information

[HarelM]

The browser should cache those, shouldn't it?

[zstadler]

It does not look like it uses the cache.

[HarelM]

Might be some missing cache control headers...

[zstadler]

Indeed. I'm reading about the Cache-Control header and the underlying mechanism.

Stay tuned...

[zstadler]

Now that caching is enabled, the opening still takes a long time.

There seem to be two consecutive "batches" of thumbnail requests delayed by about 9 seconds. Until the second batch is completed, the track list does not respond to the user. The images requested of the first and second batches are identical

[HarelM]

I'll add those in the backend API definition, it won't be configurable, but it shouldn't change much. I've set it to 10 hrs for cloud saves and 1 year for recordings. I also added angular tracking of the elements in the dialog to avoid multiple rendering of images and to cause more network calls.

If you think there should be other numbers let me know before I commit and close this issue.

[HarelM]

I've added cache control, but the problem is in the UI when syncing the traces.

[HarelM]

Testing this locally shows good improvement, but I think my machine runs faster. I'll deploy this once the docker is ready so you can test if the performance improvements are enough.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days