Activity

1. sonu-tz commented on Feb 12, 2026

   

   sonu-tz

   on Feb 12, 2026

   Author

   More actions

   Just following it if anything on it?
2. parfeon commented on Feb 12, 2026

   

   parfeon

   on Feb 12, 2026

   Last edited by parfeon

   Contributor

   More actions

   @sonu-tz thank you for reaching out.

   From the video, which I can see is not heartbeat, but subscribe requests, and the fact that tt changes with each request means that there is data circulating really fast, and with the message received with the previous request,  SDK receives tt for the next one. So it is expected behavior if there is data flow on subscribed channels.
3. sonu-tz commented on Mar 3, 2026

   

   sonu-tz

   on Mar 3, 2026

   Author

   More actions

   Hi @parfeon,

   Thanks for the explanation regarding the subscribe requests and the tt value changing with each request when messages are flowing quickly.

   In our case, the backend is publishing events very aggressively, which results in a very high frequency of subscribe responses and subsequent subscribe requests from the browser. Within a short period (less than a minute), we can see a very large number of subscribe requests in the network tab.

   Since the PubNub JavaScript SDK immediately issues the next subscribe request after receiving messages, this creates a continuous loop of requests when the message rate is high.

   The challenge for us is that the frontend cannot control the publishing frequency because these events are generated by our backend system. Due to this high event rate, the browser sometimes becomes unresponsive and network activity spikes significantly.

   We would like to understand if there are any recommended approaches to mitigate this on the PubNub side or via SDK configuration, such as:

   • Batching or buffering messages before delivering them to the client
   • Limiting or throttling the subscribe request frequency
   • Adjusting SDK configuration (timeouts, request pacing, etc.)
   • Any architectural best practices for handling very high message throughput in web clients

   Since reducing the publish rate on the backend is currently not feasible for us, we would appreciate any guidance on how we can reduce the impact of this behavior on the frontend.

   Thanks for your help.
4. sonu-tz commented on Mar 3, 2026

   

   sonu-tz

   on Mar 3, 2026

   Author

   More actions

   One additional point from our side: previously we were using Socket.IO for real-time events and we never experienced these performance issues. After switching to PubNub, we started seeing a very high number of subscribe requests during periods of heavy event publishing.

   Our assumption is that because PubNub relies on HTTP subscribe cycles (long polling) rather than a single persistent socket connection, the aggressive publishing rate from our backend results in a rapid subscribe–response loop. This seems to create additional overhead in the browser compared to Socket.IO, where all events were delivered over a single WebSocket connection.

   Could this transport difference be contributing to the behavior we are observing?
5. sonu-tz commented on Mar 5, 2026

   

   sonu-tz

   on Mar 5, 2026

   Author

   More actions

   One thing to note: during our analysis we observed that after disabling subscriptionWorkerUrl on 27th Jan, the UI started experiencing slowness. At times the UI freezes or becomes very slow to respond. We suspect that disabling it might be contributing to this performance degradation.

   The reason we disabled it was due to an issue where users frequently opened multiple tabs. After around 10–20 minutes, those tabs began throwing errors, which caused the real-time events to stop working.

   Could you provide more insight into why connections across multiple tabs get interrupted after a certain period of time?