State Grid Web Migration Council Chamber Event
The event at the SOLARIS State Grid Web Migration Council Chamber featured discussions on State Grid, United States applications, new version concepts, TangoGQL interface tests, frontend implementation, future features, and more. The concept of architecture involving the web client, backend, database, and Tango GQL API was elaborated upon. Tests of TangoGQL performance and response times were also conducted, showing average results for different hardware setups.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
SOLARIS State Grid Web Migration Council Chamber (SKAO), 28.06.2023 Joanna Wajda SOLARIS National Synchrotron Radiation Centre 2
Agenda Introduction of State Grid and United States applications New version concept Results of TangoGQL Interface tests Initial Implementation of Frontend Future Features 3
State Grid Displays grouped states of the accelerator devices Displayed state value is the most important state of the group States are retrieved from the United States device 5
United States Device which aggregates states of defined devices Device has one string attribute ChildData, which contains JSON encoded States of monitored devices ChildData sends event at every device state change 6
Concept of architecture Web Client: Request data about device states from Backend Backend: Constantly request states data from Tango GQL API Generate configuration of grids and send them to Web Client Read configuration from database (optional) Database: Store saved configs and another information for future features 8
Performance tests single subscription 80 One device subscription, one application instance 70 Testing setup: Intel(R) Xeon(R) Gold 6126 CPU 2.60GHz Memory DDR4 2933MHZ Response time = elapsed time after request till reaching the first response 60 Response time [ms] 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 10 Vertical scaling makes no big difference, all results in average differ from 2 to 3 ms 1 Core, 1Gb mem 75.739 52.011 57.99 54.996 49.233 54.266 56.597 52.932 55.033 51.064 AVG 1 Core, 1Gb mem 55.9861 55.9861 55.9861 55.9861 55.9861 55.9861 55.9861 55.9861 55.9861 55.9861 1,5 Core, 1,5Gb mem 53.117 52.5 46.855 52.568 54.329 54.315 52.117 54.184 49.959 50.704 AVG 1,5 Core, 1,5Gb mem 52.0648 52.0648 52.0648 52.0648 52.0648 52.0648 52.0648 52.0648 52.0648 52.0648 2 Core, 2Gb mem 52.397 52.321 49.957 53.682 52.347 52.177 53.013 49.539 54.512 52.985 AVG 2 Core, 2Gb mem 52.293 52.293 52.293 52.293 52.293 52.293 52.293 52.293 52.293 52.293 Request number 1 Core, 1Gb mem AVG 1 Core, 1Gb mem 1,5 Core, 1,5Gb mem AVG 1,5 Core, 1,5Gb mem 2 Core, 2Gb mem AVG 2 Core, 2Gb mem 10
Performance tests bulk subscription Bulk subscription, one application instance Still no benefits from vertical scaling in a given setup 70000 60000 Response time = elapsed time after request till reaching first response for all devices 50000 Response time [ms] 40000 Quite linear trend, which might suggest no parallel subscriptions within one bulk request reasons?: o Tango? o TangoGQL implementation? 1 Core, 1Gb mem 1,5 Core, 1,5 Gb mem 30000 2 Core 2Gb mem 20000 10000 0 0 100 200 300 400 500 600 700 800 900 1000 Number of devices subscribed 11
Performance tests chunk subscription No performance gain while dividing subscription into parallel chunks. 300 device subscription paralel chunks, one application instance (2Cores, 2Gb mem) 12 It suggest, that there is no parallel processing between consecutive requests, at least until first result is obtained. 11.91389 11.9 11.8 11.65572 11.7 Avg Response time [s] 11.6 11.5 11.4 11.3 11.2 11.14423 11.12256 11.1 11 0 2 4 6 8 10 12 Number of chunks 12
Performance tests chunk subscription Horizontal scaling seems to has satisfactory results 1000 Bulk device subscription 10 paralel chunks, multiple instances (1Core, 1Gb mem) 50 We can get less than 3.5s or even less total response time for 1000 devices with reasonable number of instances 43.9829586 45 40 35 Avg Response time [s] 30 25 20.8485627 20 14.6605725 15 10 6.49501 3.2224637 5 0 0 2 4 6 8 10 12 Number of instances 13
Future Features Configurable Dashboards User Login Device management from frontend app 16
Summary Conclusions from tests two option to load data faster: 1. Scale TangoGQL horizontally and divide subscription request into separate chunks 2. Additional backend service, which also offers additional functionalities Web application provides the advantage of checking device status on any device, including mobile phones. 17
Thank you for attention Joanna Wajda SOLARIS National Synchrotron Radiation Centre joanna1.wajda@uj.edu.pl 18
