Hi guys!
I am developing an iOS application which user Backendless
A few days ago the network connection began to be very slow, we are waiting for a response for a long amount of time, some of them fail with timeout error.
Are you able to help with this issue? A few days ago everything was fine, but now responses are slow, so I’d assume that something has changed on the Backendless side
Application ID - 268A4266-C654-502C-FF00-CDEEF32E7200
iOS API key - DE748ADB-54BB-1114-FF76-CB483A060E00
Hi, Egen.
I’ve connected to your app and tried to make simple requests to retrieve data from the tables.
Some requests perform fast, some do not. (It’s worth saying that now our servers are working without any problems).
For example you Order table is overloaded with columns – 60+ is really big amount as for object representation. In addition it has relations and you enabled “autoload” option for them, so the backend must get them too. Thus small wonder the request takes so long time (for me about 40-50 seconds!).
I’d would recommend to rewrite your code that works with persistence layer, so it gets only required fields and relations.
And secondly, change the schema table design in order to eliminate big amount of columns in it.
Oleg, I don’t believe that’s the issue.
Eugene’s comment is about the dev DB we’re using to make some changes to the app, that’s where we’re seeing major performance issues. The production version is much more responsive and has basically the same schema and relations:
Production App ID: 96E1B405-CEF7-CA0A-FF29-F33711007E00
We added just a couple of fields and one relation, so we increased the number of table columns by like 5% yet performance dropped like 500%, that doesn’t make sense.
Edit: table columns, not rows
Hi Chris,
To clarify the issue, are you saying API requests are slow or working with console is? If the former, could you please provide a curl request which demonstrates the problem?
Regards,
Mark
Mark, API requests are slow.
For example -
whereClause = “Market[orders].objectId = ‘(objectID)’ and (orderStatus = ‘(OrderStatus.new.rawValue)’ or orderStatus = ‘(OrderStatus.missingCar.rawValue)’ or orderStatus = ‘(OrderStatus.excessiveSnow.rawValue)’)”
sortBy = “created”
pageSize = 10
find in ‘Order’ table with DataQueryBuilder
Just confirmed this must be an issue on the backendless side with that specific app.
I created a new app just now, took an export of the problem app and imported it into the new app. Almost no delay when retrieving data from the order table, response takes just a second or two.
New app ID: D5D55A3C-DF42-AE77-FF24-03FA18995C00
If possible, we need to have a whereClause query with all the values so we can duplicate the problem from our side. Would you be able to share it? What you sent has a lot of “placeholders” and we cannot use it “as-is”.
This should do:
whereClause = “orderStatus = ‘New’”
The reason it works much faster in the cloned app is because the autoload configuration for the columns is not cloned. This is a perfect demonstration that without autoload enabled things are flying, but with they are very slow. This is exactly what @oleg-vyalyh wrote about earlier.
Regards,
Mark
The new app you created for tests (“Performance”:D5D55A3C-DF42-AE77-FF24-03FA18995C00) is differ from the original one.
As i mentioned above, the reason is in “autoload” function. In the source app you have it switched on almost on all tables. And in the new app they are absent.
I’m afraid not… I just updated to set all the Order relations to autoload and saw no performance hit. So in fact it shows quite the opposite, enabling autoload appeared to have essentially zero impact on performance, please recheck.
Edit: There may have been some minor performance degradation, but it went from 1-2 seconds, to 2-4 seconds. Nothing remotely close to the 30-45 seconds I’m seeing in first backendless app
You need to enable autload as in source app: for “Users” table and so on, because this operation is recursive.
Ok, so I identified the issue.
There is no problem with the number of columns in the order table and generally no problem with the autoloading of related objects, looks like we may have been caught in a bit of a loop. The issue seems to be having autoload of orders turned on for the market object. We had markets related to orders and orders related to markets both with autoload turned on creating a circular relationship, which I assume caused some issues. Turning off autoload of orders on the market object seems to have fixed the problem.