Dear Maxim Dounin, Team & Community,
Thank you for your suggestions.
Would be helpful if you could suggest the following,
> In general, $request_time minus $upstream_response_time is the slowness
> introduced by the client.
1. It's true most of the time. But clients are not willing to accept unless
they see a log from server side. (Say the client server itself is running in
another hosing services like amazon EC2 instance)
> Further, $request_time can be saved at various request processing stages,
>such as after reading request headers via the "set"
directive, or via a map when sending the response headers. This provides mostly
arbitrary time measurements if you need it.
2. How do we get control in nginx configuration when the last byte of request
body is received from the client
> For detailed investigation on what happens with the particular client,
> debugging log is the most efficient instrument, notably the
> "debug_connection" directive which makes it possible to
activate debug logging only for a particular client
This debug log would definitely help to check the last byte of the request body
!
3. But is it recommended to used nginx built with --with-debug in production
environments
4. We receive such slow requests infrequently. Enabling debug log is producing
a huge amount of logs/per request (2MB of log file per 10 MB request body
upload) and it becomes hard to identify the slow request in that. Thats why it
is mentioned as no straightforward way to measure the time taken by client to
send the request body completely.
> Is there a timeout for the whole request?
5. How to prevent attacks like slow-loris DDos from exhausting the client
connections when using the open-source version. Timeouts such as
client_body_timeout are not much helpful for such attacks.
Thanks & Regards,
Devarajan D.
---- On Mon, 02 Oct 2023 03:46:40 +0530 Maxim Dounin <mdou...@mdounin.ru> wrote
---
Hello!
On Sun, Oct 01, 2023 at 08:20:23PM +0530, Devarajan D via nginx wrote:
> Currently, there is no straightforward way to measure the time
> taken by client to upload the request body.
>
> 1. A variable similar to request_time, upstream_response_time
> can be helpful to easily log this time taken by client.
> So it will be easy to prove to the client where the slowness
> is.
In general, $request_time minus $upstream_response_time is the
slowness introduced by the client. (In some cases,
$upstream_response_time might also depend on the client behaviour,
such as with "proxy_request_buffering off;" or with
"proxy_buffering off;" and/or due to proxy_max_temp_file_size
reached.)
Further, $request_time can be saved at various request processing
stages, such as after reading request headers via the "set"
directive, or via a map when sending the response headers. This
provides mostly arbitrary time measurements if you need it.
For detailed investigation on what happens with the particular
client, debugging log is the most efficient instrument, notably
the "debug_connection" directive which makes it possible to
activate debug logging only for a particular client
(http://nginx.org/r/debug_connection).
> 2. Also, is there a timeout for the whole request?
>
> (say request should be timed out if it is more than 15
> minutes)
No.
--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
mailto:nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
