Thx for sharing more details Alberto.

'Connecting' includes more or less three parts:
1. Authentication
2. Requesting initial data
3. Initializing the UI (processing the initial data, initializing model layer, generating the UI, …)

We are aware that the Authentication part includes a 'protobuf initialization' which takes a significant part and that can be prevented via a setting. That results in slower communication on some types of messages (mainly SRM related). We can experiment with that on your staging to see how much you like that.
The Initial data upon connecting can be quite extensive. It includes all your view info, your element info, service info, user settings, … The time includes serialization (server) and deserialization (client) of all the objects so it's definitely more than sending over the wire. We've done some small improvements in recent Cube version wrt interface data, so a recent Cube version can show some improvements here. What Cube version are you using?
The last part, the UI initialization, can depend on your initial open cards, alarm console tab pages, etc In your user settings you can for example configure to save your open cards, so that they are loaded again upon new connections. But you can also choose to start from a clean workspace. Same for alarm console tabpages, the ones based on active alarms are reopened in new connections.

Finally, a connection time from 15 to 35 seconds is rather common I believe (not claiming it's good and that we should not aim for better 😉 ). Better, faster, cheaper is what we all want to achieve, right?
I read that you are surprised to see this delay, which make me believe it used to be faster on your side… is that the case? Do you believe the connection was faster in a past version maybe?

Hi Alberto,
In that sense the Monitoring app is indeed much more lightweight (and also limited in capabilities) and there are indeed opportunities in Cube to improve in that sense.

I have two suggestions for you that can impact the connection time at your system.
1. Use a more recent Cube version (preferably the latest, but 10.4.12 or higher should already have some impact, depending on the type of elements you have) – (When having internet access on your clients, by default, you should be updated automatically to the latest Cube version)
2. Experiment with disabling protobuf. Warning, this will give a faster authentication step, but can result in some slower data loading at some point (mainly SRM related data).
The easiest experiment you can do here is connecting via slnetclienttest.exe. Not sure if you are familiar with that test client? You can run it on every agent via the DataMiner systray icon context menu > Launch > Tools > Client test.
In the connect window (I'll add a screenshot in my main reply), you find a list of attributes on the right hand side. One of the attributes is 'NoProBufSerialization'. If you connect with or without that option, you should be able to see the difference. Be aware that you'll have to restart the test tool to see an effect, because it's only the first time that you'll notice the delay with protobufSerialization. If you want to disable the protobufserialization for all connections (so also Cube), you can use this softlaunchoption: <ProtoBufSerialization>false</ProtoBufSerialization> (https://docs.dataminer.services/user-guide/Reference/Soft-launch_options/SoftLaunchOptions.html). If you can try this on your staging system and share the results, we can discuss the next steps.