Why I have fetch actions so slow when the service action inside is fast?
Application Type
Mobile, Service

Hey guys,

I've created a support case for this, since its quite urgent to get an answer, but I though you might already experienced it before and can help me with it.

So,  we're having timeout issues in our mobile app, and because of that we've decided to refactor a little bit how we get the data (we don't use localstorage by choice).

Before we changed anything, we have a screen with a fetch that runs "At Start".

This fetch was requesting a service action that had everything to load.

Our decision was to split the specified service action into several service actions. And do the same thing in the app, that is, to create more fetch actions running "At start" so we could have requests in parallel. Each one would request one of those splitted service actions.

When testing, it was even slower, I went to service center's screen requests logs and saw this:

Those fetch actions are taking more than 3 seconds each. I remind you that each of these fetch, only requests one service action. If I go to Service Actions log to check the durations of each:

As you can see, each service action takes 5/7 ms to run, but the fetch is taking seconds to complete.

My question is, why is that? Is it some missed configuration in the platform? Is a setting that needs to change in the front-end servers? (those requests were in the same server)

This is the main question.

As an additional question, does our thinking of splitting the fetch "at start" into several fetch "at start" makes sense? I would say yes, since they run in parallel, but let me know your thoughts.

Thank you!

Nelson

Hi Nelson,

to start with your last question, I´ d say yes, split up in multiple fetches allows for better UX, is also promoted as best practice.

As to why the fetches take so long compared to the service action inside them, can you tell a bit more about them.  Do they retrieve (i.e. send back over the network) large amounts of data ?

Dorine

 

Hey Dorine,

Thank you for your reply.

those mentioned service actions return a structure with 2 attributes (text and boolean) and a boolean, and that's it.

I can tell you that if I join the service actions, the fetch data still takes those 3,4,5 seconds, and the service actions takes those tiny milliseconds.

Nelson


Euhm, oké, that´ s not much output.  

I think local variables in the screen can also influence the size of stuff sent over such a fetch call, but I would imagine that´ s optimized for only what is actually referred inside the fetch. 

And if you have them as server actions instead of service action, just as a test, does that give different results ?

Is it only seen in these few actions or everything on that server ?

Also, no lengthy manipulations of the service action results inside the fetch action? 

Also, as a test, what happens if you call same service actions directly in a client action instead of inside a fetch action ?

Just some things to look at, no answers, I´ m afraid.

Hey Dorine,

thank you for your help.

I did tried server action instead of service, same thing.

It is seen in that page only, since it was the one I've refactored.

Nope, no manipulations at wrap. Just a simple wrap up action.

Didn't try that one yet. But that won't get me the parallel requests as I want to.

Another test that I did was using a desktop connected in a LAN instead of wireless, and the fetch data duration was faster (still slower than service actions), instead of 2 seconds each, it was 300ms each. So, my guess is that on screen requests log, the duration is related with Network.


Well yes,

 all points to network, but in that case all your screens, and even non-OS requests would be slow.  I guess there are benchmarks or something available online to test this kind of stuff ???  That should be checked, because no amount of optimization in your screen and server can help with that.

So does this screen have exceptionally large amounts of local variables, or something like that, which might explain why this screen is slower than others ?  What about doing the same call from a virgin test screen ?

Dorine

(Almost) All screens are slow, and all have just a couple of fetch actions, we just started by this specific one since its one of the most used. Our approach would be to split the fetch actions. 

I'm still waiting for OS support on this, but now it indicates that it is a matter of network thing between the device and the front-end server.

Nelson

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.