Thank you Anvil for opportunity to become full-stack web developer with knowledge only Python!
It was great experience for me to build my own web application.
My application is almost ready and now I should make decision about how to increase the Speed of running of web-application - it is running too slow - users will not accept this.
Now I thinking about several alternatives to make right decision:
Buy my own server
Pro: no monthly charges
Cons: additional time to manage server and huge initial investment
Go to Amazon Light
Pro: good pricing
Cons: I don’t know what to chose - which configuration
Select Anvil’s Dedicated Plan
Pro: Anvil will manage server side Professionally
Cons: very high monthly charge
Maybe something else which I don’t know - please suggest me
And how you solved this speed issue with your application?
I know about code optimization - but it is helpful - even one server call function influence to application speed
answering such a question is very hard even - if you know the project structure and its bottle necks. Close to impossilbe to say without details.
Having said that, you should also be aware that it is (in my personal experience) highly possible that neither of your options will solve your speed issues.
I feel like issues happening at qa / testing stage are magnified time 100 in production. So if a testing environment without users has speed issues - simple hardware upgrades wont make it “scalable”.
My advice is: If its to slow without users, take a look at your TechStack/Architecture and try to make the foundation itself more scalable. Upgrading will likely at best just pospone the issue to a time where it will cost you more than now to fix it.
All in all - I have no Idea of your use case and code structure - so i might be miles off!!
And I’m definelty NOT taking this 5 minues of my time to promote negativity or disencourage your project. I just had some painfull experiences regarding scalability/performance in my own startup - so I feel like sharing a few personal lessons learned is the least I can do.
Listen maybe checking the forum about performance improvment solves your issue.
If I may ask, whats the end goal of the project?
Some internal tooling which is used by a couple dozen users or rather a product potentially used by a lot lets say a thousands of user?
I’m guessing users wouldn’t mind the last one where it creates the document for download.
The other ones can likely be improved by pre-loading information without the spinner (anvil.server.call_s). Or, for the initial load, only load what is strictly required for the initial/login page, and then silently load the other info from the server silently.
How to accomplish all that is not necessarily straightforward, but that’s what comes to mind as a potential strategy.
I just put on server code all back-end functions and on Forms I should anvil.call so that to use them.
I don’t know is this slow running because of hardware problem (No dedicated server) or this general Python problem
On the video I see the spinner when some forms are opened, but I don’t know what’s show.
Throwing hardware at an app with performance problems rarely helps, but it could help in certain geographical areas with slow connection with UK.
You can try installing the open source server on your own machine and see if there is any improvement. If there is no improvement, this will rule out your options 1, 2 and 3. Doing this test shouldn’t take too long (but I’ve never tried).
If you don’t see any improvement, you will need to go a little deeper and figure out what’s the bottle neck and address that.
Yes, I had spinner problems.
They all went away after making sure there was max one server call per user interaction, and by optimizing the database structure and searches.
In some cases, where I needed complex relational queries, I used SQL, available on my dedicated plan. If you don’t have a dedicated plan with SQL access, you could use an external database.
I have a dedicated plan, which helps because:
All the server load is mine (I don’t think this makes a big difference with my <100 users)
I have access to SQL (huge helps on the few apps that require complex queries, unused on most apps)
All my apps have the keep persistent server enabled (it helps especially with HTTP endpoints and in apps that have many slow imports)
It doesn’t help with:
The connection being near me (I’m in the US and the server, even if dedicated, is in the UK, so round trips are always 7000+7000 km)
I think the server load is not your problem, I don’t know how complex are your queries and how your tables are designed, I don’t know how long a server call takes.
You could calculate this by testing the time it takes for your computer to call an HTTP endpoint that immediately returns without touching the database. If pinging a quick HTTP endpoint is fast, then distance from the UK server is not a problem and moving the server closer wouldn’t help.
If it’s slow, try with an empty app and compare the time required for the new empty app to the real app. This will tell you if the delay is caused by the app being too large and importing too much.
I didn’t have any production experience before starting with the dedicated plan, but I would say that the only help the dedicated plan gave us was access to SQL (especially useful when the q query operators were not available), to larger database storage and to the “keep server running” option.
I don’t think it would have made any difference on a spinner like yours. Perhaps it would have gone down from 5 seconds to 3.5, only to go to 10 seconds when the load increases. Optimizing the server calls and the databases structure and queries instead could bring 5 seconds down to 0.5 seconds, regardless of the load.
@Ilqar Here are just some of my personal suggestions for “Where to start” looking for the slowdowns. (Aka what not to do)
Meaning there might be many, or there might just be one.
Lots of files or images (large assets in general) loaded directly into your app instead of being stored in a Data table and pulled when needed for each form. This is one I have not experienced but see it many times as a culprit.
Many import statements for large and slow loading python libraries in any of your server modules (they all import every single time you call the server under the free and lowest 2 tiered plans)
To see if #2 is affecting your performance, you may try experimenting with this lazy loading decorator I built. (You could use it for productions but its mainly for experimentation before you might go around changing all your code):
Doing absolutely every server call to gather data in the __init__ of the form.
If some of the components need data to be rendered on the screen and others do not, you may think about structuring your app differently to have the base form show, and have those components load empty, and have the show event of those components separately load their own data.
Doing this gives the user the experience of the form “loading” fast, even if what they need to see isn’t yet available. (It stops looking “broken”, and looks more like data loading in which makes people more patient)
Not reading absolutely everything@stefano.menci, @jshaffstall, and @p.colbert suggest frequently about loading as much possible data for each form within one single trip. Going back to #2, every single trip to the server with a server call loads an entirely new python instance, and every round trip to the server or data tables incurs +1 extra non-zero amount of times worth of network IO latency.
