3

In my app, I have nginx proxy to my app server (unicorn).

I'm trying to improve my file upload performance. I've read that through various techniques you can prevent your app processes from being blocked while the file is uploading. Current information on the best way to approach this topic seems hard to come by (see this question).

I'm trying to do this using client_body_in_file_only on; which as I understand it tells nginx to buffer the entire request to disk.

What I'm confused about is that even without this directive I see this in my nginx logs:

2014/10/10 17:41:43 [warn] 50331#0: *798 a client request body is buffered to a temporary file /usr/local/var/run/nginx/client_body_temp/0040665399, client: 127.0.0.1, server: my_site.dev, request: "POST /upload HTTP/1.1", host: "my_site.dev", referrer: "https://my_site.dev/upload"

It looks to me like nginx is buffering the file upload to disk anyway. Is nginx just smart out of the box here? Should I still use client_body_in_file_only? Am I misunderstanding what's happening here?

Jared Moody
  • 296
  • 1
  • 4
  • 10
  • This is not a duplicate. The question you linked to deals with `client_body_buffer_size` but does not answer my question of the effect of `client_body_in_file_only on;` on uploads. – Jared Moody Oct 13 '14 at 18:36
  • Did you _read_ the post? How does it not answer your question? – Michael Hampton Oct 15 '14 at 23:25
  • Yes, I did. The answer explains the message written to the log, but not explain the effect `client_body_in_file_only on;` on uploads - or even mention that directive. – Jared Moody Oct 16 '14 at 21:54

1 Answers1

3

How could you improve upload performance by making nginx buffering to the disk? Every time bytes are received (limited by the MTU of the transmission is the best case, or in the worst case with 1b-payload network packets), those will be written to the disk. Usually one tries to avoid requesting accessing loads of times to the disk, since it is a slow device...

client_body_in_file_only, as stated in its documentation, is mainly used for debugging, when you wish to keep a copy of clients requests body for further analysis. Be warned that setting it to on makes nginx keeping all the request files by not deleting them once the request has been processed. The value clean does it.

That directive does not, as you may have wrongly understood (de)activate the use of disk buffering per se. You see nginx using the disk for buffering of request bodies because its RAM buffers cannot contain them. It warns you because it most probably has a very bad impact on your server performance.

You may wish to enlarge your client_body_buffer_size so file uploads will stay as much as possible in RAM, before being written with the minimum amount of writing calls to the disk afterwards.

Bernard Rosset
  • 1,373
  • 12
  • 25
  • I believe the idea is to no not tie up application processes by having nginx buffer the entire request to disk and then passing the request to the application process. I was confused that in either case disk buffering was happening, but your answer is helpful in explaining that the files are not deleted when you set it to `on`, which enables this approach. I should also add that in an nginx/unicorn or similar environment, this approach is moot because application processes are not actually blocked. http://www.therailsway.com/2009/4/23/uploading-files/ – Jared Moody Sep 29 '15 at 18:06