Forum: NGINX flush temp directory

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
ron ramos (Guest)
on 2013-08-14 13:20
(Received via mailing list)
Hi All,

I am trying to test accelerated upload on nginx/php-fpm/php-cgi setup
comparing different scenarios
e.g one where /temp is a tmpfs, one where it is a disk partition and you
will also notice where in i test using php-cgi. as i need to understand
which can handle file uploads faster.

        location ~ \.php$ {
                include  fastcgi_params;

                client_body_temp_path /temp;
                fastcgi_pass_request_body off;
                client_body_in_file_only on;
                fastcgi_param REQUEST_BODY_FILE $request_body_file;

                #use php-cgi

                #use php-fpm

                fastcgi_index $dir_index;
                fastcgi_param DOCUMENT_ROOT $doc_root;
                fastcgi_split_path_info ^(.+?\.php)(/.*)$;
                fastcgi_param SCRIPT_FILENAME

i encountered one issue where in the /temp is a tmpfs (size is just
after uploading a couple of files i encountered this: *58 pwrite()
"/temp/0000000053" failed (28: No space left on device)

shouldn't it be flushed once the upload is done? or do i need to add
config to flush it automatic?

Im using a php script that uses curl to do the uploading, here's the
that manages the upload (curlupload.php)

$uploadfile = "upload/" . basename($_FILES['file_contents']['name']);
        if (move_uploaded_file($_FILES['file_contents']['tmp_name'],
$uploadfile)) {
                echo "File is valid, and was successfully uploaded.\n";
        } else {
                echo "Possible file upload attack!\n";

i removed the file after it is uploaded so i can run this script in
the script that uploads the file: (testupload.php)

        $target_url = '';

        $file_name_with_full_path = realpath('./test.exe');

        $post = array('extra_info' =>

        $ch = curl_init();
        curl_setopt($ch, CURLOPT_URL,$target_url);
        curl_setopt($ch, CURLOPT_POST,1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
        $result=curl_exec ($ch);
        curl_close ($ch);
        echo $result;

Another thing i noticed is that when not using tmpfs, I/O is high the
server when this is set:

client_body_temp_path /temp;
fastcgi_pass_request_body off;
client_body_in_file_only on;
fastcgi_param REQUEST_BODY_FILE $request_body_file;

Thank You in advance, any help or idea would be appreciated.

ron ramos (Guest)
on 2013-08-15 06:12
(Received via mailing list)
oooppp sorry found the cause "client_body_in_file_only on" changed it to
clean and it's doing it's job.

but am i missing something on PHP side or config side as it seems i am
getting the same response time using php-fpm without the accelerated
support settings
and also using php-cgi, response time is the same for all scenarios.

with accelerated support using php-fpm: - - [15/Aug/2013:10:26:05 +0800] "POST /curlupload.php
HTTP/1.1" 200 359 "-" "-" "-" 33.404 1.342 . - - [15/Aug/2013:10:26:51 +0800] "POST /curlupload.php
HTTP/1.1" 200 359 "-" "-" "-" 32.168 1.216 .

without accelerated support using php-fpm: - - [15/Aug/2013:11:02:58 +0800] "POST /curlupload.php
HTTP/1.1" 200 359 "-" "-" "-" 32.182 1.229 . - - [15/Aug/2013:11:03:32 +0800] "POST /curlupload.php
HTTP/1.1" 200 359 "-" "-" "-" 33.218 1.208 .

using php-cgi - - [15/Aug/2013:11:48:57 +0800] "POST /curlupload.php
HTTP/1.1" 200 359 "-" "-" "-" 32.371 1.418 . - - [15/Aug/2013:11:49:30 +0800] "POST /curlupload.php
HTTP/1.1" 200 359 "-" "-" "-" 33.093 1.308 .


Igor Sverkos (Guest)
on 2013-08-15 11:45
(Received via mailing list)

I would really wonder if you would see a real difference between using a
tmpfs or not for the webserver's tmp body location. A tmpfs is only
but as long as your storage has enough free IO resources and is fast
to actual write the data, you shouldn't notice.
And keep in mind: You only use the tmpfs for the request body. But you
still need to write it to disk. If your disk is limited to 120MB/s and a
normal upload is about 5 MB you are only able to handle ~23 concurrent
uploads. Well, you could buffer millions of request per second in your
super fast RAM (if you have enough RAM :P), but your PHP worker, which
move the upload from RAM to the persistent storage will become the

I have a problem with the way it seems you test your setup:
Every system should be able to handle that kind of load. After some
everything should be in some kind of cache. The IOs from the uploaded
are not enough (disks also have write caches, the OS may buffer writes,
too...). These IOs can be handled by every disk, also, the IOs comes in
sequence, not parallel.

=> Add more load. Run tests parallel/concurrent. Increase file size to
up any write caches, which will trigger real writes, which will block
storage in some ways you will notice.
ron ramos (Guest)
on 2013-08-18 02:54
(Received via mailing list)
Thank you Igor. I was just basically looking into this: so im not
sure if i am missing something out as it has the same results enabled or
disabled. I will start testing it with multiple clients and see if any
difference. Thanks again.

On Thu, Aug 15, 2013 at 5:45 PM, Igor Sverkos
This topic is locked and can not be replied to.