Okay everyone…
No more posts from pizza and pineapple pirates…
Let’s start a serious discussion on how to optimise your Wappler App for Performance.
I think the issues @UKRiggers posted about this week deserve the attention of everyone building a serious SaaS app with Wappler and from the team @George, @patrick, @Teodor.
Let’s use this thread to ask questions and share experience so it becomes a definitive place to come and learn all things performance related!
Here is some of my input from that previous thread…
The simple thing I am learning is to push as much work onto the server as possible. In particular with regard to the data you request to display.
For example, I have situations where I am displaying event attendees and messages they have been sent. So it seemed sensible to go and fetch the attendees from the database, go and fetch the messages, and then use a repeat and .where() to create the table. But the repeat and .where() use a lot of the client’s resources and end up really slowing things down. So I’m moving to one database call that gets everything in one go and no .where() in the display process. It took me time to learn about all the types of join in a database query, but now I understand that then I think I have the tools to move forwards.
I’m also re-designing some of my GUI to be less based on big tables showing lots of data, and making more of the information available via a modal if someone wants to see the details.
Variables inside repeats can get really slow.
Conditional regions rather than show/hide can speed things up as they release the local resources they are using when no longer displayed. The down side is each time you go back to that region it can be slower to re-draw the page.
Look carefully at what you read in as an array. When you get your complete list of contacts, just get the info you need to display and search through them, e.g. name, email, id. Leave address, notes and all that other detailed info for when you open one specific contact. I just checked my contacts server connect and it is about 250 bytes per contact, so plenty of room for a good few 1000 without overloading things I think.
Here are a load of questions in my mind:
What is the best way to see how much memory the browser is using to run our app?
How do we know that number is near the limit?
How much of a difference will it make if lots of other tabs are open and other apps running on the computer being used? Can we easily see what are the best things to close to give our app more room to breathe?
Are some browsers more memory/resource efficient for a typical large Wappler SaaS app and therefore better to recommend our clients to use?
When we read data from server connects, what kind of limits will we reach which will impair performance? Are there general guidelines for this…eg 100k is okay but 1000k will bring the house down?
How does data stored in a data store change this amount?
Is there some formula we can use regarding data sizes like data read from sc + data in datastore + pages in memory are best kept less than X?
@patrick, can you find the post you sent me about order of execution of variables, or repeat the details here? That seemed really important.
Turning off a conditional region makes a big difference… but how can we measure the resources a conditional region is using and see how much things have improved when it is off?
Don’t discount tablet and mobile users either Antony! Simple rule of thumb is don’t throw every bell and whistle in the mix. Every users system is different there is no definitive standard for memory, browser, CPU, etc. Be as efficient as you can. You know if you’re pushing the limits when you put your pages together, ie how many Server Actions are being called, how loaded the data store and cache is. If you feel you have too much going on you probably have too much going on. As for measuring performance try Lighthouse built in to Chrome or its big brother GTmetrix:
Some very difficult and hard to answer questions you are asking. But then there are a lot more knowledgeable users here than me who can probably help with some direction.
Looking forward to reading any responses!
For us we have some applications with thousands of users (all built in Wappler, or with DMX). We follow the rules above. We don’t overwhelm the pages. We don’t push any data that is not required specifically by the request. If we feel too much is going on in a page we break it down in to its components and refactor to achieve a good balance. Simple really. And it WORKS. Also if you are on shared hosting then no matter what you do could be stamped upon by the host. At least with your own server you can manage resources across your application. One of the best moves we ever did was go with our own dedicated servers. At least this way we know whats going on at all levels. Some hosts are far too restrictive. Whoever you host with speak with them about any limits or caps, loads, resources, etc. Might give you a good insight in to any potential bottlenecks…
New addition to Chrome Dev Tools @Antony
You can now override storage quota size in the Storage pane. This feature gives you the ability to simulate different devices and test the behavior of your apps in low disk availability scenarios.
I have used Chrome’s profiler in past to track the performance. Also Chrome’s task manager gives a quick overview of memory/cpu/network etc in use (Shift+Esc).
This would depend on a number of factors and not something that can be measured accurately.
This is more of a OS question rather than Wappler.
A user is free to do whatever they want on their system. If its a system you are developing to be used by internal users of a company, and the machines are under control, you just need to ensure to the browser can hog on as much RAM as possible.
Don’t have any experience in this. But usually, unless its some specific new protocol or tech, all browsers work well.
(will try to share my views on other questions later…)
I’ve just discovered a method that enables me to push a lot of work I was doing on the client side back to the database…
See the article below for details!
Glad to see you discovered this method and were able to implement it.
This has been discussed before in many posts from what I remember - do as much work as possible on the server action side, and very minimal stuff on client side - and we have stuck by with this to build very complex pages with little performance trade-off.
Working on server action side of things include using repeats for nested data, views (as you have done) for complex queries and custom modules/formatter/APIs/pages (in Wappler itself) to handle complexity which cannot be handled by default.
There is no definitive way of putting a limit here.
Your 100k row might have 30 columns each, bringing the “house down”. While your 1000k rows might have single column, which would just work fine.
Its dependent upon both the number of row in an array as well as total size of the data.
Not sure if I understand this question.
Point 5 answer is how you should look at this too. You will have to do a lot of hit-and-trial to see what works. Usually we haven’t seen any issues with the size of data. Its the client side formatters being applied in repeat bindings that cause performance drag.
Turing off seems like a wrong terminology here. CR is shown or hidden.
Like the VIEWS thing, CRs have also been discussed many times before to improve page performance.
I am not sure if you are familiar with this, so ignore if you already know the following: The logic behind this is when a CR is hidden, its HTML is removed from the browser UI itself. So, all the dynamic bindings and formatters no longer need to be updated by DMX - hence less work for it to do on the page.
As soon as the CR is shown, its HTML is added again and all its bindings and formatters are then processed by DMX.
It’s a bad habit that comes from Bubble. The backend was and is so horrendously slow that you tried to push as much as possible to the client.
Any experienced bubbler has gone exactly through the same. It’s one of the reasons people leave Bubble.
Oh. I did not know that. Interesting.
Thanks for all your great input @sid! I will check out the details you have shared.
Yes, I have been increasingly aware of this too, and it is only from experience that you can start to feel what the client side’s limits are with Wappler.
What I have never seen documented before is HOW to push it all to the database server.
Hence my discovery about views and case statements feels quite ground-breaking. It may be every day stuff for those who have used SQL for many years, but not for the rest of us!