Why are we having so many overages and workload use over a single search?

Hello. We’re facing some immense overages for what seems to be a simple search in our social network, and it makes the app nearly useless/unscalable. I have no idea how to make a “Do a search for” any simpler.

In just 2-5 days of use, we have used up 31% of our workload units on the personal plan and have been facing constant overages the last months as we wrap up development. How are we supposed to handle thousands of users like this if this sort of use is coming from under 20 users?

I looked into it and it comes from a simple search, which I have no clue how to simplify as it’s just a simple search:

Captura de pantalla 2024-08-04 082822

The largest portion comes from that one single search, and the other big portion in the lighter blue is just another group retrieving the list of businesses from that same search (I thought this would be more efficient than re-doing the search altogether).

This really baffles me because searching for posts isn’t even 5% of the workload units, even though there’s close to 2,000 posts and it’s also merged with another search for posts compared to the search for businesses that has 150 entries tops.

If it matters, all businesses (aside the normal basic information field), have a data field that holds a list of “plates”, which can range between 2 - 50 plates per business. Separately, each plate has about 3 - 10 data fields of text or image type.

I don’t know if searching for businesses is heavy because it holds lists of data fields that hold other data fields… or how else to simplify this. Is there any way to simplify a search even more? Someone please help, we’ve worked so hard on this :frowning: is it just truly unscalable?

Edit: Apologize for the lack of context. The Search seen is for a repeating group that searches for all existing Businesses in the database (which again, are under 200 entries). Searching for posts is set up the same (Search for Posts) but nowhere near as heavy.

Yes, that would make it heavy. Also, if you’re storing images in a text field using a badly written rich text editor plugin.

Share your data type’s structure and you’ll be able to get more helpful advice :slight_smile:

*Edit for clarity: The list on the business data type would be problematic if long, but not the contents of the data type of that list

2 Likes

From what little info your screenshots show, it looks like your each cell in your RG is doing a Search for Businesses?

Which drilldown of the WU log are you showing? What is the image of the expression from? The RG? A nested RG? You’re going to have to share more details in your screenshots.

Anyway, if you’re using the same search results in multiple elements then store it in a state list and refer to that state list from wherever.

Your Bubble app is smart enough to cache searches but every search expression has an initial cost and a realtime cost.

1 Like

Thanks for your answer. What you say makes sense… There are indeed many data fields (like list of Chats for example) which are lists of their own thing. A chat can hold a list of Messages for example… a single Message holds basic information like text, recipient, and sent date. So on… Could the issue be nailed around this then mainly?

This is how it’s generally set up for a Business (there’s a handful more similar Lists of things in the data fields below that didn’t fit in the screenshot):

This all sounds quite awful to re-do frankly but I think I see now what you’re saying and now seems kind of silly as I think of it. As an alternative then, should I try as much a possible to store all information as a “list of texts” rather than a list of custom things to reference everything by unique IDs?

So instead of this, for example:

Do this, basically:

Although, this means I’ll have to do more searches as I try to reference things throughout the app by unique ID, like with chats, rather than just reaching into “this Business’ List of Chats” for example I’d have to do "Search for chats whose ID is in current business’s list of chats (a list of texts with unique ids). Is that really more efficient? I’m scared of searches in general, but perhaps because I haven’t known to use them properly. Thanks a lot by the way, this makes sense.

I should’ve clarified more I apologize. The search seen is done in a single repeating group whose content type is Business, and its source is the simple Search for Businesses that you see. And the breakdown of Workload Use is just from the general workload by activity inside the “Fetching Data” part:

So most of it comes from fetching data… Someone above mentioned it could just be the data structure. On another note, is it truly better to reference a list of things already searched for rather than doing new searches or is there ever a scenario where it’s better to just run a new search?

Our app is so large I’m slightly bummed about having to re-structure everything… but if it has to be done, it shall be done…

NO

When Bubble fetches a data type that has a list of things as a field, the list of things are returned as text (the unique IDs) and does not return all the data related to the list of things…however, the moment you reference a data field from a related thing, then all the data is returned.

So, for example, you search for business on a page and display the address, and the business name, none of the data from list of orders or list of calendars or list of chats are returned in any form, other than a text representation of the unique IDs.

If, you search on another page for business and in the repeating group you have a text that shows the name of each Contact from the contacts field, then all the data for each User in the list of Users that is your contacts field will be returned.

What you should do is have on the Order data type is a field that is related to the business, then when you want to show the Orders for that Business, you search for orders and constrain by Business. On the Chat data type, have a field for business and when you want to show all the Chats the business is a part of, search for chats and constrain by the business field.

These are differences between 1 to many and many to 1 relationships.

2 Likes

Oh my!! You were right, in a sense! In our feed where all posts show up (it’s a social platform) we wanted to also recommend businesses here and there. So, since we already had a repeating group doing the search for businesses (which is actually the lighter blue - I was reading it wrong) we were sourcing random items per each cell from the other search, assuming it would cancel the effect of doing an actual search in each cell.

Captura de pantalla 2024-08-05 122602

I’m gonna try to figure out a different way to mix businesses into our feed where posts show up. Although, the search for businesses remains quite heavy in the light blue… which again is this one:

Captura de pantalla 2024-08-04 082822

This did clear up a big chunk of it though! Thank you for helping me understand, it means a world… we spent a lot of overages and I didn’t realize this was a large part of it :frowning: do you think you might know why the search above might be so heavy also?

1 Like

Thank you, that makes sense. I’m glad there’s more knowledgeable people on here to save us newbies from awful decisions!

I will keep in mind as well the constraining aspect too :slight_smile:

1 Like

Hmm…referring to another RG’s list of things itself should not incur additional Search costs, since the data has already been loaded in one way or another. So the additional cost is coming from fetching data from fields of connected datatypes.

I’m still a bit vague of your setup but looking at the fields of the datatype, I concur with both @georgecollier and @boston85719 points.

You have a lot of list fields in your datatype. That in and of itself is fine if properly managed. Costs rise when your app fetches data for those lists. Whenever your page needs to fetch a single item from that list, it will fetch ALL items (that follow your privacy rules) instead.

Highly recommend you do some restructuring if you wanna keep WU costs down. It sucks when you’re already deep in dev but trust me, every bit counts. Especially if you have any form of social feed.

1 Like

Interesting… although it’s coming from just that one seemingly simple “Search for Business” from the reading (it’s a discover section, hence I search for all businesses). It’s quite crazy though… I’m spending nearly 2k workflows every hour or so … per 1-2 users… :frowning: and again, it all comes from fetching data on this Search.

I don’t know why the search would be so heavy since I’m not retrieving anything complex from the businesses itself other than a few simple fields like its name, description, profile picture and such… which based on what you guys said above, it shouldn’t mean any other lists are pulled up correct? It’s a very simple layout to show just the very basic info of businesses:

If the issue is the mere existence of so many data fields with lists inside the business though, would the solution be, in general, to delete all/most lists of things from the Business data type itself? So it’s just the fact the lists exist at all within the business data type even if not used at all within the repeating group fully?

For example, which would be more efficient?

A) A repeating group searching for 1 data type that has 40 data field lists but only uses 2 of them in the information displayed…

or

B) A repeating group searching for 1 data type that has 10 data field lists and uses information from all 10 data field lists?

yes, as described, you should create the many to 1 relationships, so every chat has a business field, so that you can delete the list of chats from the business data type

BTW, make a simple test page, add that same set of cards and search to it, to see if that is really the issue or if you are searching somewhere else as well that you have not yet spotted.

2 Likes

This topic was automatically closed after 70 days. New replies are no longer allowed.