In our application, the landing page displays 1,000 records from a view with 6 or 7 fields. The application performs well for a single user, but performance declines as the number of users increases[goes 12 x slower for 100 users ]. We have reviewed the database calls, and they are quite fast, yet Appian takes a long time to load the pages. Are we missing something here ?
Discussion posts and replies are publicly visible
1000 records on a single screen ?!? I have my doubts! And database views are known for generating performance issues.
I suggest to perform proper performance testing and analysis.
Yes , we pull almost 1000 records and store it in a local variable and using it in the ready only grid the view takes 800 ms to 1 second max , but when the user grows appian takes as long as 12-16 seconds to load the page
Yeah, well ... that's just no good idea! In general!
What is the reason for loading so many rows? Do you really show all 1000 rows to the user?
As you already found out, this will never scale. You will have to rethink your solution approach.
If you describe your specific use case in detail, we might be able to provide some hints on a better design.
Yes Stefan , I felt the same way thanks for your input
What's the max that we can go on batchsize in general any suggestions?
The loan officer will login to appian and see all the cases that flowed in the application through API's , the requirement is to show the 1000 cases for the LO as he can pick up any of the case from the list
You will have to discuss this with your UX expert and the client. Showing a list of 1000 items on a screen is a bad user experience and bad for the overall platform performance.
Sure Stefan , Thanks for your support and guidance
Hello! If you could display the items in a grid format with dynamic paging support, it would help improve the interface performance significantly.
I agree with what Stefan says here. I will take a guess and say they currently use a spreadsheet and then filter to the data they need.
If you could watch what they currently do and understand their activity maybe there is a way to pre-filter the data, or present it in a far more specific way.
Also, if your data resides in Records, always check to see what you can do with a Record Data Model and support of the Query Record expression before using a view. I have found that a lot of database views can become redundant with the full use of Records.