Team,
We are facing this issue many times a day. Any reason and solution asap?
It’s occurring many times in APIs also.
We are experiencing some technical difficulties. Our team is aware and is already working on resolving the issue.
Best Regards,
Maksym
Okay, Any idea of time to fix this?
Technical issues have been resolved on our side. If the problem still occurs for you, it is because the code runs longer than the time allowed by your pricing plan:
If this is the case, you could either refactor the logic so it runs faster or purchase the following function pack:
Regards,
Mark
Okay, Thanks for the fix. We’ll be testing.
I think we don’t need to purchase any package or upgrade it as of now we are on development mode. Let’s see after releasing our app.
Many issues are pending from support still.
Such as what? Please let me know the links of any pending support topics and I will be happy to take a look.
Regards,
Mark
Check this please.
It’s a month ago.
Thanks, I will check that. That’s one issue and you said there are “many issues”. is there anything else?
I am logging to each request but I am confused to see TimeOut
Can you please let me know is it in the same request or it is in a different request?
How can I know which code is executing here?
And also Mark,
We got the same issue from JS library we are using. We are using default login functions of JS SDK
@mark-piller
We have logged to check porcessing time of each request and I am sending here those requeste which are taking more than 300ms.
See the maximum time taken by LoginFunction
which is default function of backendless (GetCurrentUser in codeless User APIs)
What do you think? Which things need to be improved at our end?
Hi @Baljeet_Singh !
Login function does a lot of work under the hood that is why it takes so much time. We will try to optimize it but improvement will not have big impact on your case.
If to talk about execution timeouts. We have checked our logs and found next entries:
2021-03-22 09:26:04,274 | SERVER_CODE | INFO | [31471] [8AB4F779-74F4-4C03-899B-CECD5A5549A8] [INVOKE TIMER] updateChallengeStatusWithActive
2021-03-22 09:26:29,275 | SERVER_CODE | ERROR | [31471] Task execution is aborted due to timeout
2021-03-22 09:26:29,276 | SERVER_CODE | INFO | [31471] Processing finished in 25037.817ms
As you can see timeout occurs in your timer which, according to the name, updates challenges statuses. I suggest you to reduce amout of work which is performed during one timer call. You can increase frequency and reduce job amount which is perfromed during single timer execution. This can solve your situation.
As for responsivness of Backendless API - you can move your apps to EU cluster. It will reduce network dellay for users from Asia.
Regards, Andriy
I suggest you to reduce amout of work which is performed during one timer call
Are you talking about reducing the number of records to fetch? Which are now I am fetching for 100 records in each call over the loop?
I am reducing DB hits in the function as well. But, Do you think the table I am using has not more than 800 records and query should take time more than expected?
Login function does a lot of work under the hood that is why it takes so much time. We will try to optimize it but improvement will not have big impact on your case.
Is te mean we cannot solve timeout issue in login?
@Baljeet_Singh
One more moment to clarify - you experience timeouts not only in code which is running in debug mode but also in code which is deployed to Backendless, right?
Are you talking about reducing the number of records to fetch? Which are now I am fetching for 100 records in each call over the loop?
Yes, I talked about reducing the number of records which is fetched for timer for one time but 100 records is reasonamble size of the batch. I have several questions:
- How many fields do you change during timer execution?
- Do you use simple update for each object or you use bulkUpdate?
I am reducing DB hits in the function as well. But, Do you think the table I am using has not more than 800 records and query should take time more than expected?
That is not normal if logic is deployed to Backendless server but it completely normal if you running it in debug mode from your local computer.
Could you please provide your App ID so I could look on it.
Is te mean we cannot solve timeout issue in login?
I will create internal ticket for optimization of user login and we will try to reduce execution time of login logic but I can’t gurantee that execution time will be reduced a lot. Do you use simple login/password login or OAuth login?
Regards, Andriy
Thanks for the clarification @Andriy_Konoz
- How many fields do you change during timer execution?
The logic is Updating/Creating/Fetching records from DB.
One iteration is
- Getting user By its owner Id ( can we get user by owner Id directly without hitting DB )
- Sending push notification to the user.
- Saving push notification to DB.
- Sending/Saving push notifications to other relational users also(not more than 2 or 3 in one iteration)
- Updating the object of the table.
I’ve improved this code like
- I was fetching the user in the push notification function that is removed by passing a direct object.
- Fetching user in iteration and saving to cache and checking from the cache in the next iteration.
Don’t think so I can improve the logic than this.
- Do you use simple update for each object or you use bulkUpdate?
Simple Update
Could you please provide your App ID so I could look on it.
APP ID
5DA64846-E3FA-C63E-FF1B-E265995AA700
That is not normal if logic is deployed to Backendless server but it completely normal if you running it in debug mode from your local computer.
How can I change debug mode to release ?
@Andriy_Konoz
I’ve tried Caching as well, it’s taking same time of execution and sometimes more than to fetch a single record from DB
That is a lot of work for one timer for such batch of items.
- Getting user By its owner Id
You mean that you retrieve users one by one from DB?
can we get user by owner Id directly without hitting DB
Unfortunatelly no, you can’t since this information is stored in DB
- Saving push notification to DB.
You can use bulkCreate for push notifications at the end of the timer execution
- Sending/Saving push notifications to other relational users also(not more than 2 or 3 in one iteration)
Also I suggest you to reorganize your logic so you would retrieve all related users by one query, index them by objectId and then use this map further to retrieve related users. It will improve your code, of course if this optimization possible.
- Updating the object of the table.
If in timer you change the same fields with the same values for each user then you can use bulkUpdate which will reduce amount of DB hits.
How can I change debug mode to release ?
By debug mode I meant code which you run on your PC. When you deply it to Backendless it automatically runs in production mode.
I’ve tried Caching as well, it’s taking same time of execution and sometimes more than to fetch a single record from DB
Try to store information that is required for one timer execution in local variables in your code and reference it from them. It should improve performance of your code
Regards, Andriy
@Andriy_Konoz
I’ve improved and reduced a few hits of DB
Let me try the bulk operation for push notifications as well.
And Andriy, I am using codeless and not aware about the bulk operations.
Hello @Baljeet_Singh
About bulk update.
For bulk update in Codeless use Bulk Update bloc from Data API section.