Having script calls in WebDev as API endpoints for perspective projects - Need to know on the performance impact in the gateway server

Ignition
,
1

Hi ,

We are using Ignition v 8.1.10 (with WebDev module)

Implementation/Design:
Due to a requirement and to have the design in a modular approach, we have a separate project which takes care of all running of database queries (required CRUD operations), and the scripts to call these DB operations.
For interfacing this to our other project(s) running on the same gateway, we have APIs written using WebDev module (and we invoke them through the system.net http-get and post calls from the other perspective projects).
Validations:
We have validated the request-response turnaround for the API calls, and max response time is approx. - 180ms, and min response time for some API calls are 5-7ms. And we also have validated by running multiple iterations using postman for the API endpoints.

Questions:

  1. We would like to know what are the performance impacts on the gateway server, when we have multiple perspective sessions (50 to 100 open sessions) and calling the same WebDev endpoints for various operations in comparison with directly calling the scripts to perform the same operations?
  2. Will the scripts or API calls will be running in the individual user perspective sessions?, and if so, will there be any load on the performance of the gateway server (the WebDev API and scripts are in a separate ignition project, which doesnā€™t have any perspective views)
  3. If the scripts are client/session scoped, is there any way we can have the common generic scripts running as single instance and we call them from different sessions to get the results (aware of gateway events and using message handlers to process something similar, but will there be any performance difference between the two approaches?)
  4. Please let us know if there are any recommendations that we can use for the WebDev API design.

Thanks

2

All scripts are run on the gateway. No matter what scope.
Calling the scripts directly would be faster, but i dont think it will be a noticable difference.
If you expect a lot of users calling the same query which has ā€œrather staticā€ data, you could use a tag that gets the data every x seconds.

If you already have split up your database in a different project, a huge boost would be to place this project on a different server to split up your db.

2 Likes
3

If you are always calling from Perspective scripts, consider using system.util.sendRequest() to call the other projectā€™s scripts. No packing/unpacking to web-compatible formats.

2 Likes
4

Hi ,
thanks for sharing the details.
we are already handling the json data for our components data loading part, so we are ok there.
Would like to know if there are any performance related comparison in general - between on directly calling the script (returns plain data or python dictionary) or calling the API (webdev) which runs the same script and returns the result.

thanks

5

I would expect a significant performance advantage to sendRequest, as no socket is needed when called in gateway (Perspective) scope. No serialization/deserialization of payloads in both directions.

2 Likes
6

sendRequest or directly calling the script will be significantly faster than a Webdev call, absolutely no question. Thereā€™s a lot of extra work that has to happen for a webdev call.

1 Like
7

Itā€™s not clear to me why youā€™re jumping through all these extra hoops to essentially add an RPC layer in front of what turns out to be functions running on the same gateway. Inheriting a project that all your scripting functions/libraries are defined in achieves the same modularity goal.

8

Thanks for the replies.
The project with the functions and API endpoints (WebDev) is created for the purpose of exposing the endpoints for other external systems outside Ignition (project requirements) to access and consume the data.
We planned to use the same API endpoints to call for the Ignition hosted perspective application as well. Thatā€™s the reason for this implementation and approach we were looking.
Regarding the project inheritance, we wanted to avoid a multi-level parent project inheritance and didnā€™t want to expose the APIs from this project as well.
Based on the other responses/recommendations, we are thinking of having the gateway message handlers in the same API project and call them through the sendRequest from the (caller) same ignition gateway hosted project - if there are any considerations or change of approach we need to make, please let us know.
Thanks

9

I think itā€™s a reasonable approach. I would just make sure to organize things so that all your core business logic happens in project library scripts which take ā€˜pureā€™ parameters. Then the call site (webdev, message handler) can handle unpacking parameters and passing them in to your functions.

2 Likes