Delayed Completion of Server Actions in 6.8.0 Version of My App

So when someone logs into my PHP based app, there are about 12 server actions which load user data.

In the Wappler v3.9.7 version of my app, these load in 1-2 elapsed seconds for my clients with a larger amount of data.

In the Wappler 6.8.0 version of my app, the server actions are all called, but half of them sit in a (pending) state for 30+ seconds.

They access the same AWS RDS database, and have the same size of EC2 server (vCPU/RAM)... but run different Linux/PHP and Wappler versions.

This could either be because of something in Wappler AC2, or some fine detail in my new server configuration.

Can anyone shine any light on why those server actions may be sitting around saying (Pending) for so long?

(They don't sit around when it is a new login which has little data to load.. and once you are logged in, the user interaction is quite normal and multiple server actions excute very rapidly).

Is there anything I can add to my code to see more of what is happening?

Thanks!
Antony.

The server actions saying "pending":

login_leela_pending

The server actions when fully loaded 30+ seconds later...

login_complete_leela

The timing screen for one of the server actions while it is pending:

login_timing_stalled

The timing screen for the same server action once it has completed 30+ seconds later:

My EC2 instance logs don't show anything wrong... they just show all the server actions being called within a second of the login button being pressed.

Click one of those slow requests and go to the Timing tab, post screenshot

And also what web server are you using? Did you follow a tutorial? If so, which one?

Basically I'm trying to figure if you're using Apache, nginx, php-fpm...

Added above.

The server is Amazon EC2 based. The logs talk about nginx, and the platform is described as "PHP 8.3 running on 64bit Amazon Linux 2023/4.3.3"

I set it up in the same general way as my previous server which has run okay for years... but AWS does have a gazillion options!

This timing diagram talks about it being stalled... and the explanation link says:

  • Stalled. The request could be stalled after connection start for any of the reasons described in Queueing.

  • Queueing. The browser queues requests before connection start and when:

    • There are higher priority requests.
    • There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
    • The browser is briefly allocating space in the disk cache.

Stalled for 0.63 ms, don't think that's the issue :slight_smile:

The initial connection refers to the time taken to perform the initial TCP handshake and negotiating SSL (where applicable)

Source

This points towards a server/nginx configuration rather than a Wappler issue (though I'm not 100% sure). Unfortunately, I don't have a clear answer why this is happening, and troubleshooting this would require some back and forth which I lack the availability.

Basically I would check the nginx configuration and see if it could be enhanced, like increasing options like worker_limit, increasing ulimit and stuff like that. ChatGPT could probably give you a hand :slight_smile:

That's assuming you haven't changed your Wappler steps to the point of potentially causing one of them to hang...

1 Like

Thanks so much for your responses @Apple !

Ah yes, it is the "initial connection" that has the delay... the docs say:

  • Initial connection. The browser is establishing a connection, including TCP handshakes or retries and negotiating an SSL.

I'll check out the things you have said and talk to AWS Support...

Try turning off CSRF as that often causes this issue. If so you can then drill down on the cause.

Also misbehaving redis can cause this

2 Likes

Thanks @Hyperbytes !

CSRF isn't on/fully implemented yet...

I'm not sure if my server uses Redis... how can I tell?

How many server actions you call at once on load? You do know that the browsers are limited to maximum 6 concurrent http connections to the same site?

Those server actions pending show crsf parameters

Hey @george, that is a very interesting point...

I call around 12 at login - well some are probably one after the other, and some concurrently... I've not worked that out.

The strange thing is that the calling of these 12 server actions finalises in 1-2 seconds in my Wappler 3.9.7 based app on an older AWS server config, but exhibits this " Initial connection" delay with the 6.8.0 based app and a new AWS server config.

Do you have an ideas why this could be?

It is something to do with the quantity of data being downloaded, as when I log in to an account that have little data, it all works okay...

Yes, but I don't use them in the server actions yet... so they are just an unused payload.

Try turning csrf conpletely in settings and retest.

I don't have CSRF turned on... I am implementing it all manually, but the server side code hasn't been added yet.

Then check your redis settings, not at a computer now but i seem to recall they are in two places, project settings and workflow settings.

Turn both off.
I have seen this pending issue before when helping users and it was caused by having redis on but no redis server running. The pending was actually the unresponsive redis server response. May not be the cause but worth a try.

1 Like

See for more...

1 Like

Thanks for this Brian!

I’ve checked Project Settings and it was off … can anyone tell me where to look for the second Redis Settings location?

This is in your Target settings @Antony .

Thanks @Cheese ... I found it there, but Brian thought it would be somewhere else too...

There is a second option for Redis within the configuration dialogue for the Project.

image

Remember that this setting is Target related based upon which Target is selected.