Community Tip - Stay updated on what is happening on the PTC Community by subscribing to PTC Community Announcements. X
Hi All,
developing a Mashup, it is a best pratice to reduce the amount of services called to get the data. Is it also right for an application that will be used only by one person?
Solved! Go to Solution.
In this case it doesn't make sense to optimize HTTP, and you should rather focus on optimizing your KPI calculations, and most importantly test it with realistic amount of generated data (e.g. with 1 year worth of historical readings in your DB).
/ Constantine
You can think of it this way:
Every service call is a return trip to the Server which can impact time to load.
So you want to carefully think about how you do your calls, can you get more information up front in one call without it going stale and use selected row.
Also in your services you want to reduce 'redundant information retrieval' as much as possible.
For example, if one query asks for a detailed set of records but then you also have a service asking for aggregates can you somehow do that in one service?
If you want to dive a little deeper you can read this: https://community.ptc.com/t5/IoT-Tech-Tips/Designing-for-Scale-Events-and-Data-Handling/m-p/598761#M1278
Hello @gch,
Here's my personal opinion, I'm not writing those best practices, but this is how I interpret them.
It really depends on what those services do. Consider an example:
Example 1: A mashup displays a history of voltage readings + the average value for the last 24 hours.
Situation 1.1: You have two services -- GetHistoricData (feeds the grid) and GetAverageVoltage (for the value display). Both of those services have to do a database query for voltage readings.
Situation 1.2: You have a single service -- GetHistoricDataWithAverage, which returns an infotable with the embedded infotable and an average value, which you then bind to different widgets in your mashup. This service does only one query in the database.
Example 2: A mashup displays a history of voltage readings + the current state of the voltmeter (online / offline). In this case it doesn't make sense to merge two services in one, because you would have to do two queries anyway (the types of data are unrelated).
So the reason why reducing the number of service calls is a best practice is not because it saves time on HTTP processing -- those figures are often negligible compared to delays on the server AND within the mashup, as it renders in client's browser. Instead, the rationale is to avoid repeating the same (or similar) queries multiple times for loading one mashup -- that's the main performance killer in this context.
Now, back to your original question of whether it makes sense to optimize it for one single user... I guess it would be hard to justify even paying for ThingWorx license + your development effort for the 1-user app (or this user must be a pretty important person). I'm just trying to say that even if today you have an app like this, tomorrow most probably somebody will either add more users to it, or host some additional app there, and so the performance will suddenly become a major concern. So it's better to think about it ahead of time.
Regards,
Constantine
Thanks for the answers!
in this particular case we are talking about a dashboard visible in a production room and displaying for instance OEM values. That's why we will never have a second user logged on the system.
Currently the solution is not very fast, but the bottleneck is also the data source. But we want to optimize our code.
In one mashup I have 5 services that will be called, getting unrelated data from different sources, incl. data table. I could make a common service for that but the data are not related to each others and I'm not sure if it is not wasted time to do that. We are more in the example 2.
In this case it doesn't make sense to optimize HTTP, and you should rather focus on optimizing your KPI calculations, and most importantly test it with realistic amount of generated data (e.g. with 1 year worth of historical readings in your DB).
/ Constantine