I have a web app that is basically one page, but I create and destroy container controls as needed as the user navigates the site. There is an input container control with a WebCombobox that contains about 3000 items that takes about 4 or 5 seconds to load via a thread. I guess that’s not bad, but it’s also the first control most users would try to use. I’d like to cut down the load time as much as I can since the user has to sit through the loading delay every time the container control is instantiated.
Would loading all the items into a session property have any downsides? Would that even speed up the loading of the combobox compared to loading directly from the DB?
Do you have access for testing the 2025r3 beta to see if it loads faster? It comes with improved performance for WebComboBox:
If you can share a sample project to see how you’re populating that control, we might find a faster way to do it.
1 Like
I looked at it a little closer and pretty much all the delay is in the call to the DB to get the info to populate the combobox with. So it’s really nothing to do with the combobox, but I still want to shorten that delay from the user’s perspective.
In the container control’s Shown event I make the call to the DB and then populate the combobox, so the user has to sit through the delay every time they navigate to this control. Are there any downsides to making the DB call as soon as the user logs in and then storing the data in a Session property? I imagine that populating the combobox from a session property would be pretty quick…
Only the memory you design this cache to take. It will be used until 3 minutes after the user closes the tab. DON’T store the control or the Session will never end. If your app can sustain the memory pressure for all users, I think this is a very good idea (load unchanging list at login).
I think the memory will ok. I’ll give it a go and see what happens. Thanks!
I made the change and the UX is MUCH better. I put the DB call in a thread so it’s not even noticeable when logging in, and there is basically no delay when loading the combobox.
I was thinking about memory needed to store the data in each Session. I think I could achieve the same result by storing the data as an App property. It’s the same data for all users, so i really only need to make one copy.
This sounds like an easy way to create a race condition. Have you tried it on the server yet? It may very well be working, but hear me out…
I think an acceptable and fair alternative would just be a “Logging in…” progress wheel. Let the process take the time it needs to ensure everything is loaded to be safe. I don’t think any user would consider this experience abnormal. (Have you played an online game? That’s very much the experience I imagine.)
Oh what an interesting piece of information! So if the data never changes throughout the course of the runtime, then you very much could load it in App.Opening. Personally, I would, and even cause the web app to quit if there are any errors (printing messages to the log, of course!)
Keep in mind a Xojo Web app is always running, even when there are no users, so if you need it to update from time to time you’ll need a way to do that – or relaunch the app.
1 Like
I’ll move all this over the App since I think that will be better overall. The data will need updating occasionally but that can be handled.
Thanks @Tim_Parnell
1 Like