Flush temp directory

Server NGINX
1

Hi All,

I am trying to test accelerated upload on nginx/php-fpm/php-cgi setup
and
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
            #fastcgi_pass 127.0.0.1:10005;

            #use php-fpm
            fastcgi_pass 127.0.0.1:9000;

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

$document_root$fastcgi_script_name;
}

i encountered one issue where in the /temp is a tmpfs (size is just
1GB),
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
some
config to flush it automatic?

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

<?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"; unlink($uploadfile); } else { echo "Possible file upload attack!\n"; } print_r($_FILES); print_r($_POST); ?>

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

<?php $target_url = 'http://10.254.12.160/curlupload.php'; $file_name_with_full_path = realpath('./test.exe'); $post = array('extra_info' => '123456','file_contents'=>'@'.$file_name_with_full_path); $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.

Regards,
Ron

2

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:
10.254.12.84 - - [15/Aug/2013:10:26:05 +0800] “POST /curlupload.php
HTTP/1.1” 200 359 “-” “-” “-” 33.404 1.342 .
10.254.12.84 - - [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:
10.254.12.84 - - [15/Aug/2013:11:02:58 +0800] “POST /curlupload.php
HTTP/1.1” 200 359 “-” “-” “-” 32.182 1.229 .
10.254.12.84 - - [15/Aug/2013:11:03:32 +0800] “POST /curlupload.php
HTTP/1.1” 200 359 “-” “-” “-” 33.218 1.208 .

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

TIA

Regards,
Ron

3

H
i,

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
faster,
but as long as your storage has enough free IO resources and is fast
enough
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
will
move the upload from RAM to the persistent storage will become the
bottleneck.

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
runs,
everything should be in some kind of cache. The IOs from the uploaded
files
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
fill
up any write caches, which will trigger real writes, which will block
the
storage in some ways you will notice.

4

Thank you Igor. I was just basically looking into this:
http://php-fpm.org/wiki/Features#Accelerated_upload_support so im not
quite
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