Question

Performance of readonly grid using a!recorddata for 'data' parameter

Forum|Forum|1 year ago
July 23, 2025
12 replies
0 views

Hi Community,

I am using a!recorddata for my readonly grid. record is API backed which has 3.5 million rows of meta data (just 4 columns). I am using pagesize as 50. I have provided filters in UI for users to narrow down their search. Since currently I am only using sample size data , Should I expect any performance issues once 3.5 million data is synced into records?

I didn't find any recipes for a!recorddata with pagesize. So also would like to understand how readonly grid interprets and handles pagination just by using pagesize without any limitation on amount of records?

stefanhelzle0001

If you only load 50 items from any number of larger set, I would not expect any kind of performance degradation.

As soon as you introduce filtering and search, a larger dataset will lead to a degradation in performance. How much, depends on the design of the system. When using synced records, you will have to calculate the expected data growth and add enough resources to keep the required performance level. Contact Appian in case you want to discuss this deeper.

anveshs420634Author

Thanks [mention:a11f77a729fb4db2af76b09948583328:e9ed411860ed4f2ba0265705b8793d05] .

Just to add few more details, I will be sync once in a month and and there is no expected data growth. Total count would remain around 3.5 million itself.

If we ignore the filters for now, above config would handle pagination for whole record set right , i mean pagination works for 3.5 million data just by passing the pagesize parameter (I know, user won't do this on a real time time scenario). Wanted to make sure this would pass performance testing for my case .

shubhama926776

AFAIK, Yes, expect performance issues. Syncing 3.5M rows will be slow and may timeout during initial and daily syncs. While pageSize: 50 creates automatic pagination, it won't solve the core problem - Appian queries all 3.5M synced rows in its database, making even paginated requests slower.
To pass performance testing, use real-time API mode (no sync) where your API returns only 50 rows per request.
If you must sync, performance will likely fail without optimizations like filters or the "Keep data available at high volumes" option.

anveshs420634Author

What If I don't configure 'Scheduled full syncs', It will sync only once initially when deployed and triggered- and caches all 3.5 million rows. Now the readonly grid will only load 50 items per page as per 'pagesize' parameter on initial load of interface right?. I believed 'pagesize' will do the magic when a!recorddata is used for read only grid. When user clicks on next page subsequent batch of 50 is queried and loaded to interface, which should not get affected by number of rows lying behind in records unless I use any filters to narrow down.

shubhama926776

Yes. After the initial sync caches all 3.5M rows, a!recordData() with pageSize: 50 will efficiently query only 50 rows per page click. This works because appian uses proper database queries. The risks are: initial sync timeout and stale data without updates. But for static reference data, this approach is valid - sync once, disable scheduled syncs, and pagination will perform well.

Just ensure the initial deployment sync completes successfully.

Sign up

Login with SSO

Login to the community

Login with SSO