websocket reconnect / page reload jitter

[xaptronic]

Hello,

I have an issue with a nicegui application where, if there are many people who have the application window open (perhaps lost in a sea of tabs) whenever I deploy code updates and restart the server, it appears that the more people have the app open, the more connections come in at once and seem to block the app from booting quickly and serving requests.

I am going to experiment with adding a jitter around where window.location.reload() is called for reconnects - also wondering if anyone else has this problem, or if there are other workarounds / patterns for handling many reconnects on boot.

[rodja]

Maybe your page does to much cpu-bound or io-bound work on the main thread? See https://github.com/zauberzeug/nicegui/wiki/FAQs#why-is-my-long-running-function-blocking-ui-updates for more infos.

[xaptronic]

My app is dealing with a small-medium amount of data (about 70MB) which it transmits to the client to show in aggrid.

However, the initial data load is done using an on_startup hook, and then in the page where I create all the components, I do the data transmission using client on_connect and use await'd run_grid_method apply transaction and actually batch out the data.

I have done various levels of instrumentation around all these operations and the highest timing is about 0.5s which occurs in the application start up when I the data on start up. Sending each batch out to clients on startup runs in about 0.13s.

Once the application has booted up successfully, there do not appear to be any particular performance issues, it is only on initial boot up where it seems that the influx of reconnecting clients all at once is causing sockets to timeout, page reloads, and a new connection attempt is made, and it goes in a bit of a loop until it finally makes it through everything.

My assumption is that the startup is fine (in my logs, that startup routine is called with normal looking timings prior to client connection logs being made). It also seems that, in so far as a client connection is made and served, that is also fine (I don't see increased timings in sending data to the client when there are more connections, but rather that the clients experience socket time outs..

Perhaps I can try to measure a delta between page invocation and client connection to attempt to discern where the delay is occurring.

I will try to put together a slimmed down example of the use case and how I am structuring things to help the discussion - but if you have any thoughts / ideas on the above in the meantime, I would be glad to hear them!

[xaptronic]

Added more telemetry and it turns out the problem was basically what is described here. Was rendering a large-ish amount of data in a UI (using a dialog) that is only ever viewed via a user action click, so changed that to do an empty state on initial page load then actually render when needed.

Thanks for the hint!

[xaptronic]

Do you think there is any merit to adding an option that allows you to jitter the reconnects?

socket.io itself has options for that around reconnects and avoiding a pile up of connections..

[rodja]

Do you mean https://socket.io/docs/v4/client-options/#randomizationfactor? By default it is 0.5 s. Where would you specify this? In ui.run?

[xaptronic]

Well yes, an option like that, except i am under the impression that server restarts do not result in socket io doing a reconnect as NiceGUI reloads the page when the server reboots.

So I'm referring to something that would add a random interval around the reload so it would help stagger client reconnection via reload.

My thought was to pass something into ui.run similar as socket_io_query_params.

[rodja]

Does the jitter really solve your problem? Or would such an option steered you away from investigating the performance of your page? We would rather like to make people optimize their code than use another parameter which hides the underlying problem.

[xaptronic]

Fair push - a round of optimization certainly did a great deal to fix the problem I was having as outlined above.

I'll try to isolate what I think maybe something that could be solved with some options around how page refreshes occur when the server is restarted with a minimal example and see if there's a worthwhile problem to solve there.

I'll come back with a concrete example if I find something here.

Thanks!