25
Views
6
Comments
Solved
Multiple block render faster
Question
Application Type
Reactive
Service Studio Version
11.54.21 (Build 62708)

Hi,

I have created a screen that lists staff (up to 50) with second column that contains 31 containers (to represent a month of data) that are used to display a daily assignment code. Each container contains the same block.

The screen has over 1500 blocks which can take 15 to 20 seconds to finish updating all.

I hope that makes since.

The block receives Date and EmployeeID to return the assignment code for that block.

I am hoping you guys can suggest a better way to accomplish this type of display.

If not, is there a way to stop/interrupt the update of the blocks?

Thanks,

Glenn

Solution

Hi Glenn,

It sounds like your blocks are fetching the code from the server / database.

That means 1500 server calls / trips tp the database.

Dependent on your datamodel, it is likely better to have one big join in the parent screen also retrieving the assignment code, and passing it as input into each block.

You might have to do it in a DataAction instead of a screen aggregate, to massage the data a bit before passing it into the blocks.

Dorine

Hi Dorine,

Thanks for the advice and insight. I started playing with a DataAction to organize the data by date in a structure with a ListAppend and display a row of daily assignments in a single block using a list. It required a lot of rework and getting the containers just the right size to fit properly. But it works so much faster.

I went from 1500 blocks down to 50 blocks. Much better.

Thanks,

Glad to help, are you doing 50 separate DataActions ? That still kind of sounds like a lot to me.  

If you share your datamodel, and screen design, I'd be happy to see how you can optimize performance and maintainability.

In general, it is always an interesting exercise to try and 

  • push things closer to the database level
  • reduce number of client-server calls (weighed against already showing part of screen)
  • reduce number of server-database calls (weighed against actual sql performance)

Dorine


Hi Dorine,

Thanks for the follow up. It is one DataAction within a block that is in a cell of a table list of staff. I think it is working pretty well for now.

Thank you for your time,

Glenn

Hi @Glenn Southward  ,Can you share the screen, I did not get your Idea

Thanks

Hi Mohamed,

I thought I had attached a screenshot. Here it is. Thanks,

Solution

Hi Glenn,

It sounds like your blocks are fetching the code from the server / database.

That means 1500 server calls / trips tp the database.

Dependent on your datamodel, it is likely better to have one big join in the parent screen also retrieving the assignment code, and passing it as input into each block.

You might have to do it in a DataAction instead of a screen aggregate, to massage the data a bit before passing it into the blocks.

Dorine

Hi Dorine,

Thanks for the advice and insight. I started playing with a DataAction to organize the data by date in a structure with a ListAppend and display a row of daily assignments in a single block using a list. It required a lot of rework and getting the containers just the right size to fit properly. But it works so much faster.

I went from 1500 blocks down to 50 blocks. Much better.

Thanks,

Glad to help, are you doing 50 separate DataActions ? That still kind of sounds like a lot to me.  

If you share your datamodel, and screen design, I'd be happy to see how you can optimize performance and maintainability.

In general, it is always an interesting exercise to try and 

  • push things closer to the database level
  • reduce number of client-server calls (weighed against already showing part of screen)
  • reduce number of server-database calls (weighed against actual sql performance)

Dorine


Hi Dorine,

Thanks for the follow up. It is one DataAction within a block that is in a cell of a table list of staff. I think it is working pretty well for now.

Thank you for your time,

Glenn

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.