Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
UI update performance
-
Some users have asked about the how responsive the user interface is to changing data. The UI, in its current form, is Ajax based, and uses a polling mechanism to request data from the Mango server application. The polling rate is current set at a delay of 5 seconds. By "delay", we mean that there is 5 seconds between the end of a UI refresh and the start of the next (as opposed to, say, the start of the last and the start of the next). (This delay period can easily be made configurable.)
This was a very deliberate design decision, because it takes into account the performance of the many other factors that come into play, including the speed of the user's computer, the performance of the Mango server, and the internet latency between the two. The overall performance that you will experience, then, will be a combination of all of these factors. It will appear better on a local network than from a dial-up connection in another country.
Please note that the performance of the UI and the performance of the data sources are entirely different things. Data sources run as independent processes. Mango maintains a cache of the most recent values from all of its data sources. The UI gets its data from this cache, not by, for example, running a poll of a Modbus network.
Among other things, functionality planned for Mango includes non-browser-based interfaces that can use persistent sockets to deliver near real-time interface updating.
-
Among other things, functionality planned for Mango includes non-browser-based interfaces that can use persistent sockets to deliver near real-time interface updating.
Is this still something that is planned?
Also note that using the [url=http://www.obviously.com/tech_tips/slow_load_technique]slow load technique you can achieve real-time updating in a browser without polling. Although that example uses frames they aren't required.
The client immediately asks for an update after the page has loaded. The server sleeps on the connection until it has some new data to send the client. Once the client receives the data it immediately asks for another update.
The downside is that you constantly have an open connection for every client.
-C
-
The application landscape is constantly changing. We may, in fact, forego such development and just build integration with a product such as Lightstreamer instead.
-
What are your thoughts, inclinations a nd priorities on a non-browser based client these days?
Would you consider the eclipse Rich Client platform as a base?
-
My personal thoughts are to provide more robust ways of creating interfaces, but current projects don't provide much time. Currently it's just "night science", as Eric Kandel puts it.
-
@mlohbihler said:
The application landscape is constantly changing. We may, in fact, forego such development and just build integration with a product such as Lightstreamer instead.
Maybe you should look into the upcoming HTML 5 WebSockets and software that already offers implementations that can emulate it if not yet supported.
Some pointers are:
http://www.kaazing.org/confluence/display/KAAZING/Home
and
http://www.orbited.org/