Performance of Entity Backed Record

Hi Mekail Ali as per my understanding, here the most important factor could be pagination. It doesn't matter whether you are dealing with 1000 rows or 100k but what matters is, you should not fetch and render huge data at a time instead of that, use the batch size of 25 or 50 hence Appian can make sure to retrieve only 25 or 50 rows from the last index and can avoid performance slowness.

Hi Aloks,

How to Fetch Data in the form of batches while fetching the data from Data Base for records.

Thanks

When you create a record and configure an entity, you can find an option about batch size under record view, which you can modify as per you need.

Also may I know are you building this record over a view or table, because while comparing table and view, table performs way faster than the views.

If your requirement is to join multiple tables then I recommend you to go for materialised view where you can prepare the rows as per your requirement similar like a view but performance wise a lot better.

You can even check MySQL documentation about performance comparison between view and materialised view.

Yes I agree with @philb service backed record can be one option here. Please correct me if I am wrong, when this is not an external entity, then I believe even we can write default filter which will act like where condition while fetching the data from db for this entity, similar to what an expression rule does while using service backed record. So will this really make an improvement in terms of performance if we switch to service backed record?

Yes, you can write a condition that acts like a where clause in the default filter, but as I understand it will be applied per row and so performs badly across larger datasets. A service backed record can use a query entity which applies the where clause "properly", and so performs much better.

Hi Aloks,

In Entity backed records When The record List style is grid I didn't find any option like batch size under record view details but when I click on "Edit Record List" Link then in that grid we have an option called "Rows to display per page" where we regulate the no of records per page.

Can you please confirm whether we have any other option like batch size or else you are also referring to the same "Rows to display per page"?

If we set the Rows to display per page as 10 "Is it going fetch only 10 records form database or else it going to fetch entire data and after that it perform filtering"?

Thanks in Advance

Hi Aloks,

In Entity backed records When The record List style is grid I didn't find any option like batch size under record view details but when I click on "Edit Record List" Link then in that grid we have an option called "Rows to display per page" where we regulate the no of records per page.

Can you please confirm whether we have any other option like batch size or else you are also referring to the same "Rows to display per page"?

If we set the Rows to display per page as 10 "Is it going fetch only 10 records form database or else it going to fetch entire data and after that it perform filtering"?

Thanks in Advance

The "Rows to display per page" we can call it as pagination. So initially those rows will be loaded on to the screen. When user navigates to the next page then the next set of data will be loaded.

Hello Chandu,

If this is the function of the pagination then the performance should not be affect by the number of rows if we are not using any default filter ad the record will pick only 50 batch of record at a time.
I am right or wrong? Can you please guide me?

Thanks
Sahil Batra

Yes.

Also make sure, you query only those columns which are needed to be available in record. Because I have seen many cases where one table has 70-80 columns, so it's always a good idea to query only those columns, in this case you can create a display cdt on top of the actual table and configure only those columns which are needed in entity backed record. Configure this cdt in data store entity and build the record on top of this entity. But this type of implementation is required only when you are dealing with a table which is having many columns, which you don't need in your record. This can also impact the performance