Plesk Nginx Request abort after 30sec

[SpAcEDeViL]

Hy,

why the max_execution time that i set in plesk dont work when nginx is on?
The Timeout is 30 sec.

i set it up to 160 in file /etc/httpd/conf.d/fcgid.conf, but no effect.

 

[IgorG]

max_execution time that i set in plesk

Do you mean Subscriptions > test.com > Websites & Domains > test.com > PHP Settings ?

 

[Lloyd_mcse]

Hi SpAcEDeViL,
have a look at this kb article...

https://kb.plesk.com/en/120210

And as Igor says, when you set max_execution under PHP Settings it will add...

proxy_read_timeout <value_added_in_PHP_max_execution>;

In the Nginx conf file for the domain, so you can add the other three per domain under Additional Nginx directives.
As an example...

# Timeouts
proxy_connect_timeout  120;
proxy_send_timeout  120;
send_timeout  120;

I hope that helps.
Regards

Lloyd

 

[SpAcEDeViL]

Hy, Thx for replay.

But this not help.
I add under Domains -> text.de -> PHP-Settings

max_execution_time = 200
max_input_time = 200

and add under Domains -> text.de -> Settings für Apache & nginx -> Additional nginx statements

# Timeouts
proxy_connect_timeout  120;
proxy_send_timeout  120;
send_timeout  120;

But the abort comes around 29 - 30sec

So i use the linked site from Lloyd_mcse

cat /etc/nginx/conf.d/timeout.conf

proxy_connect_timeout       200;
proxy_send_timeout          200;
proxy_read_timeout          200;
send_timeout                200;

I think this helps, the scripts now answer in 13.7sec. (Before over 30 sec and abort)

ThX for help.

 

[Lloyd_mcse]

Oh sorry, I forgot to edit my example, should be 200 not 120
You can obviously set whatever PHP Max Execution and proxy timouts you want under the domain settings (they're then in scope of Plesk backups).
Regards

Lloyd

 

[trialotto]

@SpAcEDeViL (and @Lloyd_mcse),

Ehm, this would really be a bad idea, tuning Nginx configuration like this.

First of all, the proper format is 200s, note that the nominator of the unit of time is required. Sure, you might get away without the "s" appended, but I would not recommend it.

Second, the proposed usage of

- proxy_connect_timeout
- proxy_send_timeout
- proxy_read_timeout
- send_timeout

is inherently "wrong" in three dimensions:

a) it is a work-around for an underlying root cause of the problem, which problem is not resolved itself,

b) it is not recommended at all to insert delays in the whole proxying process, for many reasons,

c) it is not recommended at all to use a huge delay in communications with clients, certainly not if this delay coexists with delays in the proxying process.

Let me explain a bit, to make the before mentioned "dimensions" clear, with the help of this particular custom Nginx configuration.

I will use sections to keep a distinction between the "dimensions".

A - Work-arounds

Nginx is just the "messenger", a mailman that acts as a intermediair between the client and the web server (Apache).

If some hickup exists in the whole request/response process, then it will not often be Nginx: in most cases, something happens on the Apache side or the client side.

If you have a request not leading to a response in appropriate time, one can rule out a problem on the client side.

However, a problem on the Apache side does not mean that Apache itself is the root cause of the problem: often the file requested is the root cause of the problem.

You can enter delays as much as you like, but it must be clear by now that

- delays, related to the client side, are completely irrelevant,
- delays, related to the proxy side, are mostly irrelevant,
- delays, related to the Apache side, should not be introduced at the proxy side,
- problems on the PHP side should be resolved: coding errors should be fixed,
- problems on the PHP side should be resolved: issues with execution should be fixed by optimizing the PHP file for speed of execution,
- problems on the PHP side should be resolved: if code fixing and execution time optimization does not work, PHP config should be altered,

and if everything is done properly, you should not even encounter the necessity to touch Nginx directives involving timeouts of any kind.

At this moment, there still is an underlying root cause of the problem and that is bad: the custom Nginx configuration is very likely not to be of any help, if Apache is under heavy load.

B - Proxy delays

In this particular custom Nginx configuration, there are three directives:

1 - proxy_connect_timeout: "Defines a timeout for establishing a connection with a proxied server. It should be noted that this timeout cannot usually exceed 75 seconds."

In short, the directive is barely relevant, certainly with a value of 200s. However, actually applying this directive is very relevant: it has severe consequences.

In fact, given the unresolved root cause of the problem with a problematic delay at the Apache side due to execution problems, Nginx delays in communications with the proxied server.

This applies to ALL requests, as long as the Apache side keeps busy with an unresolved root cause of the problem.

2 - proxy_send_timeout: "Sets a timeout for transmitting a request to the proxied server. The timeout is set only between two successive write operations, not for the transmission of the whole request. If the proxied server does not receive anything within this time, the connection is closed."

In short, the directive is intended to cut down on time spend to transmit requests to the proxied server, i.e. Apache.

It must be clear that setting a value of 200s (a whopping 3 minutes and then some) is not really in line with the intention of this particular Nginx directive.

Moreover, given the explanation in point B.1, it is probably the case that a connection with the proxied server often does not exist, making this directive rather obsolete.

And even when a connection can be made in 0s to 200s, one can still wait a 0s to 200s, if the proxied server is rather busy.

In fact, given the unresolved root cause of the problem with a delay at the Apache side, Nginx can at maximum add a delay of a whopping 400s, before closing connections.

Again, this applies to ALL requests.

Anyway, it is not good to add additional delays, certainly when these additional delays are not necessary. It is not nice to wait a whopping 400s and still see the connection closed.

3 - proxy_read_timeout: "Defines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed."

Well, I can be short about this one: it is good to wait a while for a response, if some unresolve root cause of the problem is present at the Apache side, i.e. the proxied server.

However, given the explanations in point B.1 and B.2, it is very likely that connections are closed and that no response will follow, so why wait?

In fact, why wait a whopping 200s, if we first have to wait for a maximum of 400s before knowing that the connection has been closed previously?!?

Or, as another fact, if the connection with the proxied server has been made, why wait for a whopping 200s PLUS some 0s tot 400s (i.e. time to establish a connection), before closing down the connection, if no transmission by the proxied server will follow?!?

A shorter delay by means of the proxy_read_timeout directive is surely more appropriate.


Given the three points above, it must be clear by now that the interaction between the settings of the three proxy related Nginx directives can be very troublesome.

In essence, one is adding unnecessary delays on the proxy side, even though Nginx is just the messenger.

In conclusion of this section, delays should not be entered at the proxy side and certainly not the above mentioned three Nginx directives with a staggering value of 200s.

It is recommended to, at best, only keep the proxy_read_timeout and set the value equal to the PHP max_execution_time or much lower than that.

C - Client communications

Consider the send_timeout directive: "Sets a timeout for transmitting a response to the client. The timeout is set only between two successive write operations, not for the transmission of the whole response. If the client does not receive anything within this time, the connection is closed."

Well, to be short: this directive is not required at all AND one really should not want to set it at a whopping 200s, for the sake of security.

Most clients connect to the proxy (not the other way around) and wait some time for a response, defined by a "Keep Alive" (timeout) setting.

Nginx has the keepalive_timeout directive for this purpose: by default 75s in Nginx, by default 65s in Plesk, since a value of 60s (or slightly more) is sufficient.

One really does not have a need for the send_timeout directive.

Moreover, one really should not want to introduce the send_timeout directive to handle timeouts for clients that are not respecting the keepalive_timeout settings.

In fact, a send_timeout directive with value of 200s will create a "gap" for malformed and even malicious clients to do what they want during a whopping 200s.

After all, if Nginx does not close the connection within an interval of 200s, a malformed or malicious client can keep the connection open and bombard Nginx with "muck".

Not nice! Not nice at all, since Nginx is a proxy and WILL pass "muck" to Apache, eventually leading to the creation of a much bigger problem, that coexists with the unresolved and underlying (current) root cause of the problem. A final result can be a complete shutdown of the proxied server, Apache.



In final conclusion, having said a lot, the essence of this post is that you should

- solve the underlying root cause of the problem, instead of working around this problem by creating delays at the proxy side
- skip some directives at the proxy side
- reduce the values for the used directives, since the whopping value of 200s is or can become very problematic

Hope the above helps and explains a little bit.

If you have questions, just ask.

Regards......