Application details and device details page are very slow

[dedeweb]

The page application page (/#/tenants/{tenantId}/applications/{applicationId}) and device page (/#/tenants/{tenantId}/applications/{applicationId}/devices/{deviceId) ) are really slow (more than 30 seconds to load).

For information, we have 700+ devices in one application.

I looked into the http requests of the page, I think the problem may be that the request POST /api.ApplicationService/Get is returning too much data at once. (It returns 8.55 MB in my browser)

[IoTThinks]

May be pagination issue.
To load partially instead of full list.

[dedeweb]

Yes, I think so.

[brocaar]

Thanks for reporting. I'll look into this today.

[brocaar]

I'm not able to reproduce this issue. I have created a single application with 1000 devices and I do not notice any slowdown. The /api.ApplicationService/Get response is also within the 2-3 KB range:

Requests from top to bottom:

• api.ApplicationService/List
• api.ApplicationService/Get
• api.MulticastGroupService/List
• api.DeviceService/List
• api.DeviceService/List

[lawrencedudley]

We've got an application with a similar number of devices in and have no performance issues with it.

I reckon this could be an issue with your setup - what hardware are you running this on?

[dedeweb]

Here are the HTTP requests on my chirpstack ?

What can I do to help you solve this bug ? Do you need some logs? For information, the devices are from a migration from chirpstack v3...

[lawrencedudley]

That 8.65 MB request sounds off doesn't it!

Mine with a similar number of devices is 400kb.

Has it got a huge payload in the application description/an absolute ton of tags or something?!

[dedeweb]

No, descriptions are at most a few word long, and we don't use any tags at all...
Something weird is happening, because even for a 9MB request, 50 seconds is veeeery long

[brocaar]

This is odd and is not a pagination issue. Note that your issue occurs on the get of the application. This is the response:
https://github.com/chirpstack/chirpstack/blob/master/api/proto/api/application.proto#L434

message GetApplicationResponse {
    // Application object.
    Application application = 1;

    // Created at timestamp.
    google.protobuf.Timestamp created_at = 2;

    // Last update timestamp.
    google.protobuf.Timestamp updated_at = 3;

    // Measurement keys.
    // This contains the measurement keys from all the device-profiles that
    // are used by the devices under this application.
    repeated string measurement_keys = 4;
}

Which contains the following Application message:

message Application {
    // Application ID (UUID).
    // Note: on create this will be automatically generated.
    string id = 1;

    // Application name.
    string name = 2;

    // Application description.
    string description = 3;

    // Tenant ID (UUID).
    string tenant_id = 4;
}

The only thing that could make the response very large is many measurement_keys. Note that this field contains the sum of all measurements configured under the device-profiles that are used by the devices under your application.

[dedeweb]

Ok, I think I know what happened here : we have a decoder wich returns an array of events (with an unique ID on each event). I think chirpstack tried to create a measurement for each event on every device we have :/

[brocaar]

Maybe the auto-detect of measurements should be turned into an option? By default it would be enabled (so nothing changes), but in your case you probably want to disable this feature.

[dedeweb]

Or maybe just putting a max limit on the number of measurements is enough ? (like a hundred or so ?)
In our case, I'm not sure we would have thought of disabling the feature before... Now we have hundred of thousands of measurements, we can't do anything on device profile edition : the web page is not responding anymore...

[brocaar]

@dedeweb the max. limit would be more of a workaround. As the payload keys are random, there isn't really a need to turn these into measurements in the first place. The above commit makes it possible to enable/disable the auto-detect. In your case I would recommend disabling this feature + updating the device_profile table by hand to empty the measurements column.

[dedeweb]

Thanks for the tip and for the fix ! :-)