My app hit 1K users & 15K+ rows in a week, help with performance degradation

my app which connects wine tour goers to drivers recently got some coverage from one of the biggest online blogs here in my city and I have experienced a massive surge in user signups.

It is currently sitting at 15K+ rows & 1K+ users in a week and quickly climbing as the word keeps on spreading…I am concerned however that the performance is being impacted.

For example, A wine Tour (Google sheet) is created which lists linked Selected Cellars (Glide table) that a user would want to visit.

I’m displaying the selected cellars in an in-line list and using filters to list the selected items, but I am noticing that it takes way longer than usual to load the inline list.

A tour can have up to 4 cellars added, so the numbers of rows in the Selected Cellars glide table is at most 4X times that of the Tour sheet.

Whats the best approach to improve performance in this scenario?

2 Likes

Hi Rogelio,

Nice to see another Glide app working on Wine - congratulations! This is not to answer your post, but I would sure appreciate some traffic to my wine tasting app called Swirl. Any tips on how you are doing so well?

Swirl is featured here:
https://www.facebook.com/Swirl-105567458297632

1 Like

Congrats on your success!

A possibility on performance are the # of photos your app uses to load? Also have you looked into upping your host capacity?

1 Like

how about using columns instead?

You may want to consider a slight restructure where you place all of the cellar id’s/names into a delimited list in the user record. Then you can use a Split Text column to split that list into an array and use it to create a relation to the Cellars sheet. That way you aren’t writing a bunch of rows for each user. It would just be a user sheet and a cellar sheet.

Another thought is a user specific column in the Cellar sheet, such as a boolean column (or favorites). Then a user can filter the list based on that user specific column and you still avoid writing a bunch of rows for selected cellars. Rereading though, user specific columns may not work well if you are using it to connect to other users, but it could still be part of the logic to build the delimited list via a Joined List column.

2 Likes

@Rogelio Congratulations on your success with the wine app your created. Please keep us posted on how you overcome the growth challenges that you are experiencing and how Glide has supported that growth for you. I know database capacities have been a big concern for users for many months. So curious to see how this all pans out. Best of luck to you.

1 Like

Yes me too !

Congratulations @Rogelio on your new traffic. I’ll be following this thread as well and hope the Glide team and other helpful members can help you scale your success further.

@Jeff_Hager - Noob question but can your suggestions to Rogelio be utilized in apps based purely on Glide tables as well? I know many in the community like to have Google sheets in addition to Glide tables but I was told by support that building on top of tables helps ensure the speed of our apps are optimized by avoiding a bunch of data atomicity related headaches. Thanks

1 Like

To give you an idea (I did tests with my app)

  • if you think round trip
    — user enters something on their device, it gets updated on the server (GT/GS), data gets pushed to, say, another user

GS only = 20-45 seconds (assuming GS is not actively used)
GS-computed columns = 10-15 ish (I’m trying to remember, can be longer)
GS-usc columns = 2-5 seconds (but then you might need to wait for the impact of the usc to ripple through)
GT = 15-25 seconds round trip as above for my double-app using a shared GT)

On device changes - almost instantaneous if the elements you need are computed…. But with visibility things it might take 0.2-1 sec (which means screen flash)

  • some computed columns cause more issues with updating than others - especially time

Now I have designed a high volume call center app for telemedicine. This is not your typical Glide use case!!

1 Like

Photos is not the issue, users aren’t uploading pics, this is more a data structure issue.

Hey Jeff,

I still need to ensure that there’s a record of Cellars visited under the Tour item, does your first suggestion allow for that?

Here’s how it works:

  1. User creates a ‘Tour’ item which includes details such as date/time, no. of passengers, etc…
  2. User then browsers through all the Cellars and to add to Tour, they select the Tour from a drop-down and Submits
  3. On Submit a new item is created in ‘Selected Cellars’ which includes the TourId as well as the Cellar ID
  4. When a User (and Drivers) views the Tour cellars are listed within an inline list which is taking time to load (I’d really like to see at least a loading indicator)

I really need to have a permanent record of all cellars visited under each tour.

Hope that makes sense?

As I understand his problem and imagine the solution, my suggestion would use purely glide computed column functionality, so there would be no need to use any google formulas or scripting to accomplish any of it. Because of that it would make no difference if an app is Glide Table or Google Sheet based.

As for speed, I haven’t sat and timed anything real extensively. My primary app is over 2 years old and was built prior to Glide Tables existing. Some parts are slow, but I believe it’s self inflicted due to how many calculations I’m performing, but 95% of the functionality is now using glide computed columns. I would have to believe that Glide Tables have some speed advantages due to the lack of a need for glide to sync with a google sheet, but as I see it, google sheet based apps still have the database duplicated on glide servers as glide tables. Since an app communicates with the database on glide servers I wouldn’t imagine that there would be any major speed issues unless there is a need to resync large sets of data between google and glide, or if you have formulas or scripts exclusively within the google sheet, then there will definitely be lag waiting for data to sync to the google sheet, calculate, then make the return trip to glide before being pushed back out to the app.

Think of it this way…with a google sheet based app, there are up to 3 copies of the data (google sheet, glide db, and local app cache). With a google sheet based app, there is the additional path that data has to travel to sync, but I think it’s mostly only noticeable when the google sheet is doing additional work. The app synchronizes with the glide servers exclusively and the glide servers synchronize with the google sheet, so the app won’t know any different either way. Glide Tables and/or USC columns will only ever reside on Glide servers and the local app cache. The only potential problem I could maybe see with google sheets is if there is heavy data entry or changes that would cause large amounts of data to sync between glide and google often. I still think a sheet based app that primarily uses glide tables would give you the best scalable performance while allowing for the potential to switch to using the google sheet if some of your data needs to access some functionality that’s only available with a google sheet.

@Rogelio I’m imagining something along the lines of how the demo apps in this thread build a joined list, which could be saved to a single row and later split again for any relations. @Roldy has a good example where he actually saves and recalls the saved selections. I’m not sure if it would give you exactly what you need, but if it works, it would potentially eliminate the need for several additional rows. You may still need a separate table, but it would have only one row per user/tour. If possible, you could even place the joined list in the user profile row and eliminate the extra table altogether.

3 Likes