Originally published at: Fleet load times and device statuses massively improved
We are excited to announce a major update to balenaCloud that delivers significant performance improvements for users managing large fleets.
Online|Offline is really clear and they’re opposites of each other. Operational|Disconnected doesn’t make as much sense, you could have a disconnected device that’s still technically operational (doing whatever it should be doing outside of the Balena functionality). Connected|Disconnected would make more sense, but Online|Offline is still a much more clear way of conveying the Balena connectivity status.
Not mentioned is the change to use Cloudlink as terminology for VPN. Cloudlink sounds like a 2010 marketing decision. VPN describes the service, cloudlink is vague.
Before the status could tell me if I was Online|Offline|VPNonly|HeartbeatOnly. Now it conveys less information, Operational|Disconnected|Reduced functionality. If I want to know what it means by reduced functionality, I have to include an additional column to show the Heartbeat or Cloudlink statuses.
Also not mentioned is the removal of tag column sorting. You can still add a column for a tag’s key, but you can no longer sort on that column.
Finally, while this update may improve performance for those with 10K+ fleet sizes, those of us running smaller fleets are experiencing slower load times for fleet tables and device summary pages are loading slower. Several seconds slower for both fleets and devices.
Thanks for reaching out @jchristensen and welcome to the forums! Let me try to explain some of our reasoning behind those changes.
The move to operational and disconnected statuses is to better reflect the connection to our services and their functionality. Over the years we have had a lot of users complaining about the ‘offline’ status being shown in the dashboard although the device services would be able to reach the internet. ‘Operational’ is less likely to be mistaken for the state of the device’s internet connection. ‘Disconnected’ follows the same reasoning: it is also an attempt to better communicate that the device can’t reach our servers, although as you rightfully pointed it could still be working outside of the balena services.
The shift to the ‘Cloudlink’ terminology started a while ago (although not in 2010 
) and wasn’t part of this change, it was just a continuation of our decision to distance ourselves with the idea of a VPN, since it describes an implementation detail rather than a functionality. We also want to convey that the feature is not a general purpose VPN, nor should it be used like one.
Splitting out the data into more columns and not having composite data fields that are computed on the client is part of a larger body of work to improve and learn more about which pieces of information people find useful and ultimately give better visibility and better reflect each individual service. We may re-introduce a composite status at some point in the future but we want to do it once we have gained confidence that we will provide the best user experience possible.
We are currently working on bringing the tag sorting functionality back.
As for the slower load times for smaller fleets, we are investigating the issue. Let me ask some questions about this:
- Can you give us a rough idea of your fleet size?
- How many services does your application run?
- Do you use a lot of tags by any chance?
- Are the slowdowns happening on page load, or when you use the device table pagination (or both)?
- Which browser are you using?
3 Likes
- ~24 fleets most with under 20 devices, 2 with ~300 devices.
- The application for our largest fleet uses 8 services.
- Each device has at least 4 tags. We use the tags to reference which devices are co-located (co-located devices may not be in the same fleet).
- The fleet’s summary page, devices page, and individual device summary pages all load slower since the change. Pagination performance differences aren’t noticeable.
- Chrome and Firefox browsers.
1 Like