Heavy load for UI with many results

[drublic]

Currently we are automatically running running a job once per day to measure data. This results in data which is obviously pretty big.
For a current project this means we build an index.html with the UI of about 7mb. And we run performance measurement for three projects. This is not practical.

At the moment we are throwing away data which is older than 90 days to handle this problem but still get large results.

A better solution would be to load data asynchronously: You can bootstrap data for lets say the last 20 runs and than load in more data if needed. This might result in more requests (maybe you can bundle than to 50 requests per file or so) but is far easier for people to have this data on a dashboard.

[stefanjudis]

I totally agree with this. 👍

But it wouldn't work well with the smooth zooming in and out.

What about rendering D3 on server side, so that we can drop the huge JSON included in the HTML?
And then request new data if needed?

[drublic]

What about rendering D3 on server side, so that we can drop the huge JSON included in the HTML?
And then request new data if needed?

Sounds like a better idea which might be x times faster than the current implementation.

I would suggest to implement an option for how many runs to render anyway.

[stefanjudis]

Jap makes sense - but also means, that zooming also works for subsets of data, right?

For me this means two options:

1. how many runs are included in the UI ( config option )
2. how many runs are displayed in the UI ( would stick to select box on top )

I'm really excited about this server side D3 stuff - so let's do it?

[stefanjudis]

Moving this away for know. PR for limit of included runs is already there. :)