Timeout issue

Maksym_Khobotin2 · March 10, 2021, 11:07am

We are experiencing some technical difficulties. Our team is aware and is already working on resolving the issue.

Best Regards,
Maksym

Baljeet_Singh · March 10, 2021, 11:13am

Okay, Any idea of time to fix this?

mark-piller · March 10, 2021, 4:33pm

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

Baljeet_Singh · March 10, 2021, 4:54pm

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.

mark-piller · March 10, 2021, 4:56pm

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

Baljeet_Singh · March 10, 2021, 5:11pm

Check this please.
It’s a month ago.

mark-piller · March 10, 2021, 5:36pm

Thanks, I will check that. That’s one issue and you said there are “many issues”. is there anything else?

Baljeet_Singh · March 10, 2021, 6:58pm

others also fixed @mark-piller

Baljeet_Singh · March 22, 2021, 7:28am

@mark-piller

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

Baljeet_Singh · March 24, 2021, 6:06am

@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?

Andriy_Konoz · March 24, 2021, 1:28pm

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

Baljeet_Singh · March 25, 2021, 7:09am

@Andriy_Konoz

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?

Baljeet_Singh · March 25, 2021, 7:13am

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?

Andriy_Konoz · March 25, 2021, 7:58am

@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

Baljeet_Singh · March 25, 2021, 8:38am

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 ?

Baljeet_Singh · March 25, 2021, 9:02am

@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

Andriy_Konoz · March 25, 2021, 9:04am

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