Faster UI for large datamodels
I have a data model with lots of tables (more than 30). That makes the UI painfully slow, e.g. when editing relationships. I think the reason is that it’s calculating where to place them on the screen.
I’d like to request an alternative, crude interface that doesn’t slow down for lots of tables. Or make it work for lots of tables – e.g. do the positioning calculations when first opening, but not each time I resize or click on something.
Tim von Ahsen
Posted 2 years ago·Last reply 1 year ago
11 comments
Tim von Ahsen
OP1 year agoDRay I'd like this improved in Sisense, so it works "out of the box".
Hamza's solutions help, but they're a bit of effort. The workflow will be: a client builds a big model, their UI goes slow, they get frustrated and blame me or Sisense, then either give up or ask me to fix it. Or we add a policy to manually allocate more memory to the model-graphql pod with each deployment, but with the different clients and versions of Sisense I'm involved with, I'd rather not customise more than necessary.
The problem won't happen often, so it doesn't need to be a high priority, but I'd prefer it sorted in a future version sometime.
Tim von Ahsen
OP1 year agoDRay I'm still keen for Sisense to implement dougnewton's suggestion.
I haven't worked on a data model like that for a while, so I haven't had the problem. If I do, I might try HamzaJ's methods to allocate more resources to the display pod. But it feels a bit silly that I need to allocate more memory for drawing a few circles in a tool that efficiently indexes and pivots billions of rows of data.
DRay
·1 year agoHi Tim,
Is this still something that you need help with, or did the solutions provided get you where you needed to go?
HamzaJ
·2 years agoHey Tim ,
Here is a Sisense post with instructions to change the memory limit of a pod:
https://community.sisense.com/t5/knowledge/build-stability-improvements-on-heavy-loaded-systems/ta-p/4233
Hamza
Tim von Ahsen
OP2 years agoHow do I do "Solution 2: Increase memory limit in model-graphql deployment"? Are there downsides? We might consider making this part of all our Sisense deployments.
I'll try "Solution 1" if I or others get frustrated again. I'm a bit reluctant to make that our "standard" solution for big models, as we'd need to do it across multiple clients, possibly multiple models, and it's more clutter/customisation/documentation/maintenance.
Ideally, I like Doug's idea: a "don't auto-arrange" toggle to simply leave it up to the user to arrange the diagram would take little dev time for you to implement and solves the problem perfectly for me.
Thanks Hamza.
DRay
·2 years agoHi Tim.
Did the steps provided by HamzaJ resolve the issue for you?
HamzaJ
·2 years agoHello Tim ,
Login to Sisense server
Run the command
In case you see 1 replica you need to adjust it to 2. If you already have more than 1, add 1 to that number
Run the command
Find "spec: replicas" (see the screenshot) and update replicas number (press “i” on the keyboard to enter edit mode → edit value → ESC to exit edit mode → use “:wq!” to exit and save changes)
Solution 2: Increase memory limit in model-graphql deployment
Be sure that you know what you are doing (also make a backup). Otherwise reach out to sisense support to assist you.
Tim von Ahsen
OP2 years agoHamzaJ How do you do that? I might try that.
HamzaJ
·2 years agoWe ran into this issue aswell. With the help of support we fixed this by replicating the model-graphql pod (from 1 to 2) and increasing its memory.
Tim von Ahsen
OP2 years agoI see Windows Sisense had an "ElastiCube Manager". Does that handle lots of tables? Maybe something similar for Web, or as a downloadable program that can link to the Sisense server.
dougnewton
·2 years agoMaybe a setting at the model level for "auto-rearrange", which is checked by default. (The current behavior) It would let you un-check it to turn off that feature and maintain the arrangement manually.